Castles in the air

SESSION 4
Threat Modelling

Security expert Micheal Howard took to the stage once again to discuss the concept of Threat Modelling.

The speaker used the Castle project as an illustration of a Microsoft feature which never made it to release due to the security threat it posed. Castle allows synchronization of passwords and files within a home network topology. In the home, you may have several computers but no domain. If you have 5 computers and no domain controller, how do you synchronize? The castle service needed to run as System user in order to manipulate the SAM. Config data in the registry is accessed by the Castle service but there's no trust boundary. Problems.


The foundations of Threat Modelling are firmly rooted in the Data Flow Diagram (DFD). Firstly, develop a comprehensive DFD of your system. Next, identify the trust boundaries in existance. Where a trust boundary exists, you need to ensure that the appropriate safeguards and validation are in place. Each element of the DFD (i.e. external entities, processes, data stores and data flows) are subject to different threats. These threats are described in the

STRIDE model:

• Spoofing


• Tampering


• Repudiation


• Information Disclosure


• Denial of Service (DoS)


• Elevation of Privilege

It is worth noting with Repudiation, that computers and software do not repudiate - people do!

The following table describes the DFD entities along with the threats that they are susceptible to:

We then moved onto the topic of Threat Trees which are graphical representations of security-relevant pre-conditions in the system. Basically, they are a refinement of the fault tree with the root node equalling the prime threat whilst the chid nodes equate to the questions that need to be asked. The leaf nodes are secondary threats that need to be evaluated.

"How do we calculate risk" I hear you ask. The speaker examined a number of methods.

Calculating risk with numbers...

The problem with using mathematics in calculating risk is that numbers are highly subjective. The DREAD method is particularly bad in that it allows the developer the luxury of moving potentially serious riks further down the list of severity.

Calculating risk with heuristics...

Simple 'rules of thumb' which are derived from the MSRC bulletin rankings. MSRC is good as it removes the temptation from the developer of picking and choosing the problems to fix. From this point of view it is truly objective.

Of course, there are 4 ways to mitigate software threats:

Leave things as they are.
Remove from product.
Remedy with technology countermeasure.
Warn the user.

Point 4 is shifts responsibility onto the user which is not good practice.

The speaker next turns our attention to the mitigation techniques which can be applied to the threat categories:

Threat..........................Technique
Spoofing................................Authentication
Tampering............................Integrity
Repudiation..........................Non-repudiation
Information Disclosure.......Confidentiality
Denial of Service..................Availability
Elevation of Privilege..........Authorisation

The speaker finally left us with an example scenario and 10 mins in order to

• Identify all DFD assets.
• Identify all threat types to each asset.
• Identify 3 threats (one for a data flow, one for a data store and one for a process).
• Identify first order mitigation for each threat.

Useful session.