, , , , , , , , , , ,

In the last post I discussed the TAME methodology and mentioned a connection with something known as ‘vulnerability trees’. Primarily, these are for visualising relationships between identified vulnerabilities and threats, and therefore predicting with reasonable certainty how a given network would be attacked. In turn, this makes it possible to implement security measures strategically. But vulnerability trees have additional uses: they reveal something about the size of the organisation’s attack surface, they could be a mind-mapping tool, and could even enhance the capabilities of Intrusion Detection Systems. On the other hand, trees can also be developed by anyone forrmulating a strategy for attacking a network during the reconnaissance stage.
Incidentally, mind-mapping software is ideal for this sort of thing, since this is partly about brainstorming, and most software of that kind can export the data in XML format which other systems could use for generating reports.

Constructing a Basic Tree
To illustrate this, I’ve posted a very generic tree, where the objective is to gain root access to a system. The root account is placed at the top, but this could be anything considered an important asset. Three methods immediately come to mind for reaching this objective: we could get the password, locate and edit the password file, or exploit a vulnerability in software running as a root process. Next we brainstorm the possible methods for getting there, breaking those methods down into individual stages.

The end result should give a good idea of the steps an attacker would take for reaching whatever objective. If it’s possible to skip the initial steps and exploit something at a top level directly, we have what’s called a ‘critical vulnerability’. For example, to gain root access to a system, the attacker would normally search for a program running as a root process, search a database for known vulnerabilities associated with that program, find a corresponding exploit, then run that exploit against the program. However, it might also be possible to exploit that program during normal operation to reach the objective directly – a critical vulnerability.

Probabilities and Metrics
A vulnerability tree constructed for a specific system would be far more complex than above, constructed after an exhaustive study of what could be a huge enterprise network with multiple assets. There’s something else missing from my example: it says little about the probabilities of each path being followed by various attackers, but it’s possible to make informed guesses from the complexity of each attack path, the level of skill required, and also from whatever threat assessments were made beforehand. Trees might include metrics for this, depending on who’s performing the analysis and whether it’s being presented to others. Basically it’s about deciding which possible threats have the motivation and capability to follow whatever paths in the tree.

Each node can be assigned several attributes:
* Vulnerability ID
* Name
* Category (Physical, Hardware, Software, Human, Media)
* Complexity Value
* Required Skill Level (associated with capability)
* Time to Exploit (associated with motivation)