Threat Profile and "Composite Threat"

Threat profile is a very interesting concept that identifies the complete set of threats in a given application context. The Threat Analysis and Modeling (TAM) tool generates a threat profile using an inclusive methodology; in other words, it uses the set of allowable actions to identify possible threats.

The TAM tool uses the Subject-Object Matrix (SOM) to identify the allowable actions between subjects (Roles) and objects (Components) based on the calls defined in the use cases. Threats are generated by systematic corruption of actions out of the Subject-Object Matrix (SOM).

TAM creates three threats for each call: a confidentiality threat, an integrity threat, and an availability threat. This can result in an awful lot of threats.  Most enterprise applications contain a large set of use cases, which usually results in a large SOM. With three threats for each call in the SOM, the application would have an overwhelming threat profile.  We developed the composite threat concept to bring the number of threats down to a manageable level and help focus people on the risk and risk responses.  The composite threat combines all the potential threats to actions involving the same caller and the same component.

TAM essentially generates threats based on the business perspective (i.e., from the use case/call perspective) without looking at the individual composition of the calls. For example, let’s look at the following use cases and its corresponding threats.

Use Case #1: Browse Product Catalog, where users look at product information in the catalog.

Use Case #2: User Login, where users login into the website to buy products.

Both use cases serve different business purposes: one to promote products, and the other to increase revenue by sales. If we only consider confidentiality threats, TAM would generate 6 threats for 6 calls—3 for each use case. Although these threats would appear similar due to their technical composition, each call is still part of specific business use case that contains different data: one is product information (Medium Impact Data), and the other is customer credential information (High Impact data).

Since the application passes High Impact data, you would have to secure the communication, even when it contained Medium Impact data. For example, if you were to implement SSL between website and web service, it will protect the channel at all times—regardless of the information sensitivity.  Thus, at the end, you would use the technical composition to evaluate the countermeasures that you implement. If you had just one threat to represent both calls, it would be easier to evaluate and identify the appropriate risk response.  In this case you would “Reduce” the risk.

It is important to note here that each threat generated by the TAM tool is valid according its specific business case, but the countermeasures that will reduce the risk can be the same. Countermeasures are defined using the technical attributes (Relevancies) of the components in the call; once these countermeasures are implemented in those components, all threats associated with those components would be reduced.

Combining the threats in our example reduces the threat profile from 6 to 3 threats, a 50% reduction. This allows us to view the threat profile from a technical perspective but still maintain the business perspective for the business owner to evaluate and prioritize the risks.  It simplifies the threat profile and makes it easier to decide on countermeasures. 

The enterprise version of the TAM tool has an option to generate composite threats automatically.

Anil Revuru
Security Technologist
ACE Team