Example Threat Modeling Approach
Threat modeling has changed in recent times (around 2004) to take on a more defensive perspective rather than an adversarial perspective. The problem with an adversarial perspective is that it is reactive.
When you adopt an adversarial perspective, you examine software applications, or any system, by trying to find holes in it and ways they might be exploited. Techniques that are often used in an adversarial approach are penetration testing (white box and black box), and code review. While these are valuable techniques to discover potential problems, the flaw is that you can only use them once the software has been written.
This means that if you discover any security related problems, you have to rework and re-write your code. This is very expensive in terms of both time and money.
According to Dan Griffin of JW Secure, security bugs have a much larger impact than functionality bugs. Since code around security usually touches every portion of the application, the 'ripple effect' makes the cost exponentially more expensive than functionality bugs.
Current threat modeling takes on a defender's perspective. This means that threats are examined and countermeasures, or security services, are identified at the design state of the application before any code is written. This way the defensive mechanisms are built into the code as it is written rather than patched in later. This is much more cost effective and has the added benefit of increasing security awareness in the development team. However, the disadvantage is that all threats can not be identified unless the code is trivially simple and often threat modeling on a defender's perspective will cause the development team to falsely believe that the code is secure.
A general high level overview of common steps in the defensive perspective threat modeling are:
- Define the application requirements:
- Identify business objectives
- Identify user roles that will interact with the application
- Identify the data the application will manipulate
- Identify the use cases for operating on that data that the application will facilitate
- Model the application architecture
- Model the components of the application
- Model the service roles that the components will act under
- Model any external dependencies
- Model the calls from roles, to components and eventually to the data store for each use case as identified above
- Identify any threats to the confidentiality, availability and integrity of the data and the application based on the data access control matrix that your application should be enforcing
- Assign risk values and determine the risk responses
- Determine the countermeasures to implement based on your chosen risk responses
- Continually update the threat model based on the emerging security landscape.
Read more about this topic: Threat Model
Famous quotes containing the words threat, modeling and/or approach:
“Where do whites fit in the New Africa? Nowhere, I’m inclined to say ... and I do believe that it is true that even the gentlest and most westernised Africans would like the emotional idea of the continent entirely without the complication of the presence of the white man for a generation or two. But nowhere, as an answer for us whites, is in the same category as remarks like What’s the use of living? in the face of the threat of atomic radiation. We are living; we are in Africa.”
—Nadine Gordimer (b. 1923)
“The computer takes up where psychoanalysis left off. It takes the ideas of a decentered self and makes it more concrete by modeling mind as a multiprocessing machine.”
—Sherry Turkle (b. 1948)
“Let me approach at least, and touch thy hand.
[Samson:] Not for thy life, lest fierce remembrance wake
My sudden rage to tear thee joint by joint.
At distance I forgive thee, go with that;
Bewail thy falsehood, and the pious works
It hath brought forth to make thee memorable
Among illustrious women, faithful wives:
Cherish thy hast’n’d widowhood with the gold
Of Matrimonial treason: so farewel.”
—John Milton (1608–1674)