Threat Modeling

Unfortunately there is no algorithm that gives all the right answers, but there are some tips. The first one is to start from the external entities, iterating over all the components to identify all the six kinds of threats; the motivation behind this tips is represented by the fact that when we start from the outside we can easily identify domino effect caused by a threat. Of course this approach can be applied during design or when assessing an existing system. When using STRIDE can happen to identify a threat for accident, never ignore it, but put it inside of the threat set at the moment in which you feel that the threat exists; at the same time focus on feasible threats and do not try to image very catastrophic scenario that could happen with very low probability. Start from the threats that appears to be more feasible, then iteratively add less probable threats because the resources (cost and time) are not infinite.

We need first to identify the relevant assets, and then we should start to identify all the possible threats that could be generated over the considered asset. We repeat the these steps asset by asset.

The difficult part of this approach is to identify what the target of the attack may be, most of the time the target is not something important for the company but it may generate a cascade effect that at the end will impact an important asset, also the asset may be intangible (reliability, good reputation, stock price, etc). This approach is used when the company has very clear the relation between intangible assets and tangible assets.

An asset centered approach can be implemented by following a list of steps:

1. Make a list of assets, and then consider how an attacker could threaten each one.
2. Starting from an abstract description of the asset, and then link it to a particular set of computer systems.
3. Draw the system and think about how the attacker could interact with it.

STRIDE can be used after the identification of the High level objective and their connection with the Low level objectives.

In this approach We try first to identify the attacker and all the possible attacks that can be performed by him, at the end we try to link the considered attacks to the assets. The MITRE CAPEC repository can be used in this approach together with a proper brainstorm phase to link threats to the impact on the CIA properties. This approach can also bring up possibilities that are human-centered.

In the ideal world we have that the a software components implements exactly the requirements specified by the user.

In the real world, however, the implementation does not cover exactly what the user requires, also there are some bugs (functionalities not implemented or not well implemented) and there is a set of functionalities that are implemented but that are not part of the requirements.

On the left side there are functionalities that introduce misbehavior inside the system, on the other side, functionalities that are not required most of the time are not documented and can be used by an attacker to leverage a possible execution path that generates a dangerous situation.

Currently ENISA is working on three certification schema for software: a general one, a 5G one, and a Cloud one. Given the fact that most of the services will run over 5G networks and will be offered as Cloud service, so on one side ENISA tries to give a base security level for software, and on the other side it will certify part of the infrastructure over which the application will run.

When we talk about software centric approach, we have to consider that there are several kinds of threats that can originate at different levels, not only at the application level:

During design phase is easy to fix all the possible problems that may be identified, the problem is that this process is commonly performed after the development is already started, or in the worst scenario, after that the product is complete. The idea is that if security principles are considered over all the software lifecycle the security of the software is guaranteed with a certain degree of security. On the other hand, later the security aspects are considered, higher will be the cost of securing the product.

We can use two approaches: AND Trees or OR Trees. In the first the existence of a node depends on all of the nodes belong it being true, it represent different steps in achieving a goal; the latter the existence of a node is true if any of its sub nodes are true, representing the same way to achieve the same goal.

Of course the two representation could be combined, but when implementing one or the other approach the way of reasoning change.

To define the root we need to define what is the target, so the purpose for defining the specific tree. The root can be represented by a component (i.e. a software component that represent the asset), the goal of the attacker (i.e. the action that the attacker will perform), or a general harmful condition of the system.

When creating the root it’s important to keep in mind the scope of the analysis, the suggestion is to use OR trees, and draw them into a grid that the eye can track linearly.

STRIDE keywords, or specific security requirements of the context can be used as root node.

At some point, nodes of the tree can be labeled, the labels can help during the mitigation and risk identification. Boolean value can be used to asses when that specific attacks are possible or not.

Other boolean values can be used, to classify an attack as easy/complex, expensive or cheap, intrusive, and non intrusive, if special equipment is requirement, and so on.

All of this information can be used to perform a better analysis when considering different threat sources, and attacks. For example via supporting the cost benefit analysis.

Continuous values could also be used, for example the cost of the attack, cost of defense, time to achieve the attack and more.

The countermeasures can also be contextualized in the tree to perform a what if analysis simulating what does it happens when a countermeasure is applied.

Being a visual representation of a problem, the information represented must be drawn in such a way to be easily studied by an analyst. In general an attack tree should be compact, also the graphical representation must be information rich and communicative.

Another problem is due to the fact that diagrams may include a huge number of leaf. A compact representation is useful to make the tree fit in one page. So the position of the elements must be consistent.

It starts from information related to the communication network, translating them into a structure that can be used in order to attach the vulnerabilities, analyzing only the real possible ways of interaction between hosts.

Particular edges can be label to the condition of reachability and paths. This step can be represented via reachability matrix or reachability graph. For the sake of space the matrix is used:

• The matrix measures NxN, where N is the number of hosts on the network
• In the interception there is the reachability condition
• Of course given that in most of practical communication networks the condition is not symmetric, a reachability condition for each end point is needed.

Different information can be put inside the matrix. Simply flag with a boolean the communication is possible, or more useful information can be used like which port, which protocol, or specific connection / application. All the vulnerabilities not affecting the specific port and protocol will be filtered.

The practical problem is represented by the fact that the information can be easily collected, but it is difficult to interpret them automatically: there may be problem given by NAT, private and public hosts, differences between firewall configurations and more. Of course more information you are able to include, more refined the analysis will be.

Defining the attack template, we have to specify which are the conditions required by the attacker to exploit the vulnerability. So it represents the pre-condition and post-conditions of the exploits, most of the common attack graph representation represent both kinds of condition as privileges that the attacker needs/acquire. A manual approach is easy but time consuming, an automatic approach on the other hand is much more difficult: a lot of the information are written in natural language.

The analyst can reason in terms of access on the machine (guest, user, root), rarely it can be useful to reason in term of privileges on a single application/file.

This point deals with the semantic of nodes and edges, most of the approaches uses the semantic of:

• Privilege node
• Edges associated to the vulnerabilities

But there are few exceptions.

In this case ideally the analyst would have a complete attack graph generation (Multi Source, Multi Path attack graph), the implementation of this algorithm is of course NP-Hard. For this reason alternatives are needed: optimization and heuristics algorithms that will compute the most complete view for a given analysis.

The reachability analysis phase mainly investigates the network reachability conditions within the target network. There exists two main criteria:

• Reachability Scope. In deals with in the scope of the hosts among the reachability conditions.
• Reachability Content. Express what you are considering in the intersection of the host.

There exists three main approaches, they deal with the definition of the semantic and the content of the blocks. The first one manually define the content of every node, so the basic types of pre/post-condition are extracted and are used to define the model (bottom up approach).

A second approach is based on Historical data. Defining pre/post-conditions is done by looking at what happened in the past and at the type of correlation. This kind of approach could be interesting, but it requires a good quantity of available data, and it can’t be represented just by few reports, but by statistically relevant data. It is interesting if the model can leverage from information sharing communities, in order to extract conditions of specific types of attacks and exploits.

The third approach is using text mining and processing to define pre/post-conditions from the text provided by the NVD Database; and even if the level of privileges is not told explicitly, the unchanged field may give useful information. There are different approaches that implements this technique, one example is a keyword based approach, more complex implementations can be represented by NPL implementations. Most of the time the post-conditions are difficult to retrieve, so most of the time people use the scope field of the NVD Database.

When considering the semantic of nodes and edges there are four main categories.

1. State based attack graph, in which every node represent a given state of the system. Modeling it as the configuration needed for the exploit or the privilege needed for it, or the capabilities. It was the first introduced, proposed more than 20 years ago; today this approach is not feasible anymore, given the number of hosts, and the number of vulnerabilities.
2. Vulnerability based attack graph, puts in the center of the analysis the vulnerabilities, highlighting them linking the hosts that could be impacted.
3. Host based attack graphs. The two perspective are merged, trying to understand how to move inside the network from host to host. The link between hosts is the vulnerability, and the attacker is an agent that explore the graphs, that is constructed starting from the information available.
4. Attack scenario based. In this case the attack graph is the combination of all the possible attack paths given a starting point, reachability condition and a set of vulnerabilities.

We need to consider how to compute the graph, and how to prune it. In the first case there are two families of algorithms:

1. Logic based. They encode the correlation rules as logical rules, the most famous one encodes relation rules in data log, the graph is computed by giving the knowledge base to a reason that will infer the state.
2. Graph based approach we are leveraging on algorithms that are based on graph theory, for example spanning trees, constructing the graph by visiting all the nodes, until we get to a termination condition.

Most of the time even if from the topological point of view they are different the information stored is equivalent, so the purpose of the application lead the decision. Graph based method are better suited for analysis purposes.

Concerning the pruning methods we have three alternatives, that can be applied together, the first one is a depth limited attack path prune (explore up to certain depth), of course this approach can lead to incomplete results, good for monitoring purposes but not for risk analysis.

The second method uses probabilities, so the path extended are only those with an high likelihood. It works by applying a local optimization function over the nodes.

The third method is a goal based approach, so it extend the graph using an optimization function over a goal (if the goal is the likelihood it is the same of the second), but the goal value can be anything.

The usage of an attack graph can impact different aspects, for example can be used to compute network security metrics, or to support decision over network hardening, to prioritize which are the vulnerabilities to patch, and also to perform near real-time security analysis. It can be done via mapping the hosts that are part of a specific attack path to monitor the execution of specific actions.