Threat Profiling

Having worked with threat modeling for quite a while now, I was recently given the task by one of my customers to develop a concept for threat modeling. This is perhaps nothing new, but the interesting aspect here was to integrate a kind of simplified approach ("threat modeling light" if you will) that could be executed by internal staff less experienced in doing threat modeling.

I started by evaluating different kinds of threat modeling methodologies that are out there: Microsofts of course, Trike, P.A.S.T.A and the one that could be found as Application Threat Modeling methodology on the OWASP web site. I discovered that no one of them really provide a set of clear tasks that could be executed by staff with little security know-how. Except, maybe doing an application overview, but thats quite all.

The reason for this lies in the fact that threat modeling is mostly an experience driven activity. Such as identifying trust relationships and boundaries, possible misuse cases and so on. And this experience is the result of years of practice work in this industry.

So how can we map this experience? The solution has already given years ago by people like Gary McGraw with his Attack Patterns. Those were also integrated as Attack Models as one of nine practices into Cigital's Build Software Assurance into Maturity Model (BSIMM). The problem I've got with attack patterns was though, that they do not really provide a clear procedure to use them practically. For instance for deriving a threat within an threat modeling activity.

A call this missing step between application decomposition and threat analysis threat profiling.

A threat profile starts with someone selecting a bunch of technical and/or business properties for the system to evaluate. This could be done as part of the application overview/decomposition phase.

Here are a couple of examples how those properties could actually look like:

Property	Type	Desription
TA.TYPE.WEB	Technical	Is a Webapplication
TA.TYPE.WINDOWS	Technical	Is a Windows Application
TA.TYPE.EXTERNAL	Technical	External
TA.FUNC.UPLOAD	Technical	Has an upload functionality
TA.LANG.C-CPP	Technical	Code written in C/C++
TA.LANG.PHP	Technical	Code written in PHP
TA.SRC.SP2010	Technical	Based on SharePoint 2010
TA.ATN.KERBEROS	Technical	Using Kerberos authentication
BA.DATA.TYPE2	Business	Consisting classified data
BA.USERS.ANONYMOUS	Business	Anonymous users
BA.DEV.EXT	Business	Developed externally

Now, these properties ca be matched against a custom threat library, which is managed by experienced security stuff. This threat library is where the knowledge is based. It maps properties to actual but still only possible threats - and just a few not all of course. For instance XSS for a general web-based application (tech prop), buffer overflows for C (technical propperty) or the risk of untrusted developers to include backdoors in our code (thats a business property).

Here is another example for that:

Threat ID	Threat Description Description	Properties
T.XSS1	General Cross-site Scripting	+TA.TYPE.WEB
T.BFO	Generic buffer overflow	+TA.LANG.C-CPP
T.MALWARE	Malicious files could be uploaded	+TA.TYPE.WEB, +TA.FUNC.UPLOAD
T.BACKDOORS	Developers could include backdoors	+BA.DEV.EXT

The basis for these threat library could be CAPEC or WASC. But more importantly are those threats here that are organization- or application specific. Think of a specific platform like Share Point 2010 that you are using. Wouldn't it be nice to have all of those possible Share Point threat pop up, when someone starts to work on a new application for that?

So, now we have the input (technical and business properties) and we have the knowledge (properties matched to specific threats). What we now need is a tool that matches those two sources against each other. I used a simple Excel sheet for a start. I doubt though that this would be the best choice for professional project though. However, at this point project managers only need to select a couple application properties and a simple macro automatically generates a list of possible threats for that system.

For each threat in the above list we link a more detailed threat description outlining specific attacks, countermeasures, criticality rating and link to external resources such as CAPEC.

This could be, for instance, a couple of SharePoint threats like activated web services that you have to consider when starting a SharePoint project. The result is a threat profile - not a threat model!.

Threat profiles can now give an impression of threats for a system which could be the basis for further threat analys steps to get a threat model. Alternatively, they could build the basis of an later penetration test of that specific system.