Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Do you think you need a well renowned security expert to do threat modeling? I don’t think so. Sure it would be fun to do a Threat Modeling workshop with a guy like Bruce Schneier, but the sad truth is that he likely is not available or affordable once you think you need him.

Sure, you need security know how to do a good Threat Modeling workshop. But as an engineer, I also follow the idea that I do not need to know everything, only the place where I can find the answer. It is sufficient to start with a decent security know how and a very good knowledge base.

That is one of the reasons why we have centered Threat Modeling@SAP on our product standard security. It is a huge knowledge base that has many requirements and threats in it. As such, I do not need to know everything, to a great extent, I can rely on this list.

The product standard security has quite a bit of history at SAP. Introduced around the year 2000, it evolved from a questionnaire with roughly 20 security questions into a collection of around 50 security requirements. As per requirement etiquette they typically start with “SAP Software shall / shall not…”.

Our internal standard maps easily to the Open Web Application Security Project (OWASP) top ten and Application Security Verification Standard (ASVS) or Common Vulnerabilities and Exposures (CVE), two other potential sources you could use as a knowledge base. For the time being we stick to our internal representation as most of our security processes in development are centered on this, including threat modeling. And of course our product standard is a living thing and gets updates twice a year with information from external and internal sources (including OWASP, CVE et al…).

But you might wonder, a requirement is not a threat. Well, you are right. A requirement is not a threat.

On the other hand if you change your viewpoint slightly, you can easily find a threat behind a requirement. E.g. “SAP software shall be free of data query and manipulation language injection vulnerabilities” turns into “Can I manipulate a query by injecting manipulated language snippets”.

Is our product standard complete? Hmm – a difficult question. I would rather answer it is up to date (at least after an update) to counter the well-known security issues.

Is there a chance that an ingenious hacker finds a new way to do harm? Maybe, but that should not stop us from striving for coverage of the known. Threat modeling is not safe against black swans, as any risk oriented methodology. That should not stop you from hindering all the white swans to bite you.

To summarize you might be able to do a pretty good job with a decent security expertise and well established security knowledge base. Let’s spare hiring Bruce for a subsequent run, once we discussed all known threats…



Author: Oliver Kling