Threat Modeling
For most of us, the concept of Threat Modeling takes on different meanings based upon our experiences, areas of expertise, areas of interest and comprehension of what constitutes and is defined as a threat by industry and by ourselves. For man, Threat Modeling is the realm of the developer. It is an area of expertise, which specifically addresses security, concerns of interest to them while for others, Threat Modeling is used during assessment work. It is during these assessments, most of which are specific to code analysis and review, which we see many use these techniques to formulate and define more robust Threat Models vis-a-vis the definition of potential attacks and exploits. Regardless of the definition you subscribe to, we can assume that Threat Modeling accounts for much, but does it account for everything we need it to?
Threat Modeling Attributes
It’s important to note that Threat Modeling has undergone much change over the last decade. It has experienced evolution and likely will need to going forward as both the application of the act of Threat Modeling as well as the philosophy behind it, continues to evolve and grow. This is non-negotiable when one looks at the current state of technological advancement we are in today and where we dare to take ourselves. As a result, we can assume the following of Threat Modeling:
- There are traditionally three commonly held views of Threat Models
- Attacker Centric
- Application / Software Centric
- Asset Centric
- Threat modeling can be related to any asset deemed to posses worth and be considered of value to an individual or organization
- Personnel
- Facilities
- Applications
- Systems
- Networks
Identification and declaration of exactly what defines an asset is crucial to the process of Threat Modeling, failure to perform due diligence here will be noted and likely lamented in post mortem investigations.
- It is the desire of the owner or the party(s) tasked with stewardship of the asset in question to protect and ensure the safety of the asset (and any associated / related assets)
If there is any doubt as to whether or not it is the intent of those tasked with responsibility and stewardship for all defined assets, Threat Modeling, though still important should not be the first order of business!
- All assets have points of vulnerability
- All points of vulnerability can be exploited if left unaddressed or if addressed in appropriately
- Vulnerabilities can be exploited via internal or external means
We live in an imperfect world and as a result, all things; even the most cleverly engineered -- organic or inorganic -- have flaws. Assuming otherwise is a failure of logic and will almost always lead to a fall. Accepting that all things have vulnerabilities and are susceptible to exploitation knowing that these vulnerabilities can be remediated and the risk mitigated is of paramount importance to the success or failure of Threat Modeling exercises or any associated activities.
- Useful in developing in countermeasures
This is of course quite elementary and obvious yet it is something that needs re-enforcement for several reasons not the least of which is that many despite this obvious benefit or by product depending on your point of view, still will not endeavor to engage in formalized Threat Modeling.
- Can be focused on defense or offense
This, I believe is self-explanatory. One might take into consideration their working definition of Threat Modeling as a defensive activity or as a mechanism useful, if not paramount, in offensively compromising an asset.
Where to Begin With Threat Modeling?
At a very base level, one needs to ask oneself some key questions prior to engaging in the activity of Threat Modeling in order to avoid any oversights or mistakes. These questions are rather elementary, yet their value cannot be emphasized enough. They provide the looking glass, if you will, which is necessary to successful model threats and gain the most value from the activity. Some of common questions which one should endeavor to ask and answer:
- What are the assets you need to protect?
- Where do they reside?
- Who are your customers? User community?
- Who are your adversaries?
- What are your strengths?
- What are your weaknesses?
- What can be done to minimize the attack surface and mitigate risk?
- How often should you engage in this process?
In going through this exercise, trivial though it may seem, a great deal of valuable information and data points may be collected and assessed for their use and application during Threat Modeling activities.
Models At Our Disposal
There are many models currently in use today. Some are more focused or directed towards developers, while others focus more on the needs of assessors and auditors. Regardless, there is no one single way to go about conducting Threat Modeling. Below are a few wonderful examples of current Threat Modeling methodologies & resources:
- Microsoft Threat Model
- OWASP Model
- OCTAVE
A View To A Kill: Executing a Threat Model and Processing The Results
- Picking Your Poison: Deciding on Threat Model
- Executing a Threat Model after exhaustive data gathering & analysis
- Post Mortem: Examining the Remains
- Lessons Learned: Planning for the Future
- It’s a Cycle: Wash, Rinse, Repeat
Conclusion:
The value presented by the activity associated with Threat Modeling is difficult to argue against. Threat Modeling provides a vast amount of data and can aid both individuals and organizations in quantitative and qualitative terms. Not the least of which is providing clarity into the vulnerability of an asset or potential for exploitation of an asset. Failure to undertake these activities is akin to dereliction of duty for developers and assessors alike, as those with nefarious intent not fail to exhaust every measure at their disposal to accomplish their mission.
July 27, 2010