Explanation of the securiCAD Attack Simulations
In this module, we present an explanation of the securiCAD attack simulations. In other words, how securiCAD calculates time to compromise (TTC). This is not necessary to digest in order to use and make use of securiCAD but is included for those who are interested in how securiCAD is running simulations on models to present its results.
This part of the user manual is to a large extent an extract of the SecuriLang Technical Documentation. Please contact firstname.lastname@example.org for further information.
Samples and Related Concepts
When securiCAD is performing simulations it is setting up a sequence of attack steps. Attack steps are certain operations that an attacker can accomplish to a particular object in the model. Which attack steps are possible to accomplish depends on what attack steps have previously been accomplished.
Every time the attacker, exploring the attack step structure, it facing an attack step to accomplish, the attacker’s success is determined by a certain probability. This probability is later on translated into the expected time the attacker will need to accomplish each attack step. Since the attacker’s success at each attack step attempt in the sequence is determined by a given probability, repeated attempts will give slightly different (accomplishment) outcomes. Sometimes the attacker will succeed, sometimes not.
A non-formal way of looking at this is that the attacker is making several “test rounds” of “attack step attempts”. Every such test round will include a series of attempts to accomplish different attack steps in the model.
This approach makes sense since it will reflect that different attackers have different amount of experience, skills, available time, available funds and luck. In securiCAD and in securiLang, such a “test round” is called a “sample”.
Since each sample will report slightly different figures of the difficulty accomplishing each attack step, securiCAD will present an average of all samples that have been run. This is the result that securiCAD will present to us.
Attack graphs are used to model the composition of vulnerabilities found in a network and aggregate them as possible intrusion paths, calculate their likelihood of success or the loss value. In the example below, each node is a possible attack step the attacker can/need take to be able to e.g. deploy a malicious exploit on a host.
All statistics and data employed in securiLang are derived from scientific studies, experiments, surveys and expert judgment. All sources are publicly available or available through journals or scientific publications.
A complete list of the sources utilized can be found in the securiLang Technical Documentation. The articles are not proprietary information, but in many cases, they need to be paid for in order to be accessed. Therefore, we cannot append them to this document.
If you would like to find and read an article on these topics, a good starting point is to search for the title using http://scholar.google.com which in many cases gives a link to a location with either a preview or a publishing house where you need to become a paying customer in order to access the full article.
Time-to-compromise is a measure of the effort expended by an attacker for a successful attack assuming effort is expended uniformly. In the attack graph, this can be seen as the time it takes for the attacker to “travel” between the nodes or actually the attack steps. The attacker will then take the shortest path, in other words, the least time consuming way to the end node. This can be seen in the figure below (where the probability of succeeding with the attack steps are shown in the nodes, and the time to compromise are shown between them).
As the TTC increases, the likelihood of a successful attack, and thereby risk, decreases. In securiLang, we calculate TTC by repeated random sampling using the Monte Carlo method.
Each sample is based on the outcomes of the probabilities in a cumulative distribution function (CDF) and the results of the sampling is then aggregated to an empirical mean (sample mean).
For instance, the TTC of finding a public patchable vulnerability on a Host’s operating system by an attacker is given by Gamma(0.0146, 3630) as seen below.
The simulation engine builds on an implementation of the shortest path problem which is a classical network optimization problem which arises in many practical situations.
The algorithm exists in many variations and the most common variant, Dijkstra’s Single-Source Shortest Path Algorithm, marks a node as source and finds the shortest path from the source node to all other nodes.
The implementation of Dijkstra’s Single-Source Shortest Path Algorithm used in securiLang is called Dial’s Approximate Buckets. A description of the algorithm is available in Cherkassky et al., “Shortest Paths Algorithms: theory and Experimental Evaluation”, 1993. Another description is available in Ahuja, et al., “Network Flows: Theory, Algorithms, and Applications”, 1993.
AND & OR Step Contributors
To make the simulations as effective as possible two conservative simplifications are performed (see detailed descriptions below):
– For an OR step, several attack steps are possible to use for accomplishing the attack step we are looking at, but it is enough to use only one of them. Therefore, securiCAD will choose the one with the smallest TTC value.
– For an AND step, several attack steps must be accomplished for the next attack step to happen. When deciding how much time it would take to accomplish all required (previous) attack steps, the correct way would be to sum all their TTC values (which in turn are sums of the attack steps previous to them). However, the simplification is that instead of calculating that sum, securiCAD will select the largest TTC value of the required attack steps and use that value.
The OR step is the most common attack step (AS). Each AS, e.g. host.compromise, will include statistics created by taking the average of every sample’s fastest TTC, which might include TTC values accumulated along different attack paths (however, the fastest sample specific TTC always comes from only one attack path). This means that the average TTC for the attack step will be smaller (or equal) to each of the incoming attack paths if analyzed by themselves.
|Parent Attack Step 1|
|Parent Attack Step 2|
|Parent Attack Step 3|
|Smallest TTC in sample|
In this example, the calculated TTC equals the average of [1, 1, 1] which is 1. Please observe that the possibility for the attacker to always choose the quickest TTC, results in an overall average TTC which is lower (or equal) to the average of each parent taken by themselves.
Each Attack Step, e.g. host.physicalAccess, will include statistics created by taking the average of every sample’s slowest TTC, which might include TTC values accumulated along different attack paths (however, the slowest sample specific TTC always comes from only one attack path). This means that the average TTC for the attack step will be smaller (or equal) to the “true” TTC (calculated by adding together all sample specific parent TTCs), in essence, all incoming attack paths are modeled as if happening in parallel.
|Parent Attack Step 1|
|Parent Attack Step 2|
|Parent Attack Step 3|
|Largest TTC in sample|
In this example, the calculated TTC equals the average of [3, 2, 3] which is 2.7. Please observe that this TTC will be lower than adding together the sample specific TTCs from each individual attack path. In this case, this would have resulted in taking the average of [6, 5, 6] which is 5.7.
Understanding counter intuitive results
Sometimes it can be hard to understand (and explain) the calculated (and accumulated) TTC values.
One reason for this might be that it is possible to attack the asset via many different associations at once, e.g., an Internet firewall can be attacked from the Internet, and from all the internal networks which can be reached by the attacker, by attacking internal dataflow endpoints that the attacker can reach from the Internet.
To make such an analysis easier to understand, it is recommended to adjust the simulated scenario, e.g., by analyzing the individual threats by themselves, in this case one scenario is divided in two:
Scenario 1; Model the attacks from the Internet towards the firewall only, in other words, do not let the attacker reach the dataflow endpoints which can be attacked from the Internet.
Scenario 2; Model the attacks from the dataflow endpoints which can be attacked from the Internet (and set known ruleset on the Internet firewall to true).
These scenarios by themselves will give valuable insights. When looking at them in a combined scenario/model, then the model will show their aggregated statistics (given that the attacker now has several attack paths to try in parallel).