Threat Modeling is one those ‘sciences’ that is just now starting to gel into something that can be implemented in a semi-automated fashion. With TAM/e, we have a good approach to threat modeling that is both easy on the development team, and fairly comprehensive (perhaps too much so). However there are still two very different camps on the subject within Microsoft, and a few more outside.
There have been a lot of advances in groups such as PTA (Practical Threat Analysis http://www.ptatechnologies.com/ ) as well as a push to formalize Attack Patterns (yours truly http://en.wikipedia.org/wiki/Attack_patterns and http://www.attackpatterns.org/ , Mitre / Homeland Security http://capec.mitre.org/ , and some commissioned work by Cigital https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/attack.html ) into something that can be used to assist not only Threat Modeling, but attack activity classification as well.
In any case, a thorough, and comprehensive threat modeling methodology must begin to consider these things. There aren’t any established standards yet, but I feel there will be in the near future. For my money, there are a few key things that a TM methodology must have:
- It must consider and be adaptable to the known usage pattern (TAMe/SDL-IT {Microsoft ACE Team})and unknown usage pattern (Snyder/Swiderski, SDL {Howard/Lipner}) approaches
- It must be expandable to adapt to proposed standards for classification of threats, attack patterns, and mitigations
- It must be able to model any system from software to physical devices. The standard way to break down the blocks into Threat, Attack, Mitigation will fit almost anything.
- There must be a clear and concise way to explain the threat, the associated attacks, and the mitigation
- There must be a way to loop the TM process back into the development lifecycle, as well as provide visibility up the chain to management
- Tooling support is critical to the success of a process like this. There are way way too many manual processes and methodologies involved in writing software. We need to remove the process burden from the team, and build it into workflow of the toolset.
- The tool must be intuitive to use and not require a degree to figure it out
- It must provide the information most important to the particular viewer in context, and in a clear uncluttered manner
- It must provide a comprehensive view of the security profile of the application portfolio across the organization.
- It must provide information relevant to auditing and regulatory compliance
- It must provide trend analysis across the application portfolio to identify areas where training, and process improvements need to be made.
- It must integrate closely with common development platforms (Visual Studio, Rational Rose/Clearcase) to reduce the need for re-entering data of the modeled system
- It must provide usable output to the development, test, deployment, and operations teams in the form of actionable tasks.
When considering existing tools and processes, I tend to go with TAM/e as it is the one our team developed and the most applicable to typical in-house software development. But when I talk about it the thing I get asked the most about TAM/e is; can it integrate with modeling tools like Rational Rose/ClearCase and to a lesser extent the modeling tools in Visual Studio. The biggest hurdle we have to overcome is the duplication of effort around re-entering data. Teams really get turned off when they find out that not only do they have to model their solution in Simply Objects/Rational but then they have to do it all over again for TAM/e.
I wouldn’t’ say that tooling has to necessarily be ‘built into Visual Studio’ but it certainly has to integrate with it through inputs/outputs. I suppose we should also pay homage to the fact that TAM/e in this case originated from application threat modeling.
Since that is our baseline, that is where we tend to start. With the capabilities of the current TAM/e system, it is quite possible to model anything through an independent client, but the ability to interoperate with existing application, and system modeling tools is critical in my opinion.
Our base ACE Threat Modeling methodology, where threats are essentially broken down into three parts, the Threat, the Attacks, and the associated mitigations, can be used in a physical world. I did just such a thing with TAM. I modeled physical attacks on an ATM for a bank as a demonstration exercise.
Here’s the reader’s digest version:
Vandalism
Threat – Denial of Service due to damage of the machine
Attack – Damage through blunt weapon attacks
Vulnerability - Machines made of mostly plastic parts
Mitigation - Use Cast Iron parts
Vulnerability - Exposed telephone style button
Mitigation – Use recessed buttons
Attack - Damage through vehicle intrusions
Vulnerability - ATM exposed in outdoor settings
Mitigation –
Recess ATM behind wall with only interop panel exposed
Install Secura-Posts in front of ATMs
Skimming
Threat – exposure of ATM card/account data due to the presence of skimming devices on machines
Attack-Skimming device placed over card reader slot
Vulnerability – User cannot tell when a skimming device is present
Mitigation – place an LCD screen along edge of card slot. When user inserts card, ask user to enter code displayed on LCD. If the user cannot see the LCD, skimming device present, notify bank personnel
etc
Obviously you wouldn’t feed this into Team Foundation Server. But you may need to feed it into the bank’s risk management system. So having the ability to define exports/imports to other systems is critical. As any good ‘customer’ I’ll leave the implementation to our development team, but if I had to speculate, I would envision this to be something like BizTalk’s schema transform mapping system. You have the TM schema on the left, the target schema on the right, you drag fields from on to the other and the tool creates the XSLT to make the magic happen during output. (hint hint)
With this simple process in place, you can model any threat/vulnerability/mitigation from a software system, to defending a radio comms truck on a battlefield. There is a tendency, especially in academia, to over complicate things for the sake of appearing to be doing new research. KISS is the key.
Comparing Risk Analysis to Threat Modeling
During some discussions on this topic one of the guys on our team said:
"All security people know about Risk Assessment. If the end goal is to measure (loose definition) Risk, then why still call in Threat Modelling? Modelling the threats is a part of the goal (if you think about what ACE does its find the threats and vulns) but it’s not the end goal and it’s the end goal that customers care about, managing risk."
I’m not sure I’d generalize that much. Security people also care about Risk Management, not just assessment. If you can identify and assess a risk, you are only ½ way there. Doing something about it needs to be part of the process. So if Threat Modeling is the first ½, would Threat Management be a more appropriate term for the full process?
Hmm...the more I think about it the more I like that term. It’s akin to the paring of Risk assessment and Risk Management. Risk Assessment is what those rent-an-auditors do. But Risk Management completes the circle. Threat Modeling, provides the context and identifies the areas to be covered, but Threat Management completes the process. Threat Management should be a part of any good Risk Management strategy.
Another person on the team said:
As I understand it, threat modeling is the combination of risk analysis and risk management.
TAM for example provides the functionality to assign a risk to each threat, decide risk management strategy for each threat (reduce/accept/transfer/avoid) and choose appropriate countermeasures.
Risk analysis has these steps:-
1. Asset and data valuation
2. Identification of threats and vulnerabilities to the assets
3. Calculation of risk for each threat
Risk management has the following steps:-
1. Choose what to do with the risk based on the risk appetite (reduce/accept/transfer/avoid the risk)
2. If you choose to reduce the risk, choose a countermeasure commensurate with the level of risk.
Threat modeling does all the above 5 steps and hence covers both risk assessment and management.
I believe that Threat Modeling is a subset of an RA process. There is more to RA/RM than threat modeling. There are many areas of RM that do not include any sort of ‘attack’ portion. There are many instances where RA/RM is performed on things that are not systems in any stretch of the term. While TM is a Risk Management process, it is not completely transferable as Risk Management.
Think of it this way, Risk Management is a base class, while Threat Management inherits from Risk Management.
Risk Management ideas/principals can be used on almost anything, but Threat Management is generally restricted to implementations of things.
You can have internal risks, and their mitigations, but there may not be any ‘attacks’ associated with it. TM comes into play where you may have nefarious entities actively or accidentally damaging your stuff.
For Example, investment firms and financial organizations do a lot of RA against stock and share prices. Yet there is nothing they can do to prevent them from actually crashing, and there is no attack or attacker involved. This is not something you can threat model based on commonly understood or applied principals of TM. You can’t identify a vulnerability that you can provide an actionable mitigation for. So the best you can do is plan for failure based on probability and likelihood and shore up your decisions on those plans.
Threat Management is differentiated by the fact that there is an identifiable vulnerability that could be attacked intentionally or accidentally where an actionable mitigation can be executed to remove or reduce the identified vulnerability. (look, a new definition just appeared. )
So while I agree that TM is PART of an RM strategy, I believe they are distinct and different things with one being a subset of the other. Ask yourself, isn’t it important to be able to clearly identify the holes you can, and be able to do something about the hole itself? In standardized RM strategies, you can't do anything about the stock crashing, you can only decide if you are willing to take the chance that the value will hold or not. You will either buy the stock, or you won't.
So, Threat Management is a part of any good Risk Management strategy. It includes identifying the threats, and providing actionable items that can address a vulnerability in the system/thing being modeled. This process is essential in the larger picture of Risk Management which not only takes into account system/thing based risks, but postures, and approaches to risk in general at a higher level.
