Attack Vector Concept
When modeling an IT architecture for security analysis, you will also need to connect an attacker object somewhere in the model. The attacker can be connected to any object that has an attack step and when connecting the attacker, you will also choose what connection type to use. The spot where the attacker is connected is the attacker’s starting point. This means that securiCAD does not take into account how the attacker managed to reach this starting point. For instance, when connecting the attacker to a network zone with the connection type Compromise, you can think of this as “Suppose that the attacker has managed to intrude this network zone, what impact will that have on the rest of my model?”.
Depending on where the attacker is connected, you will model different “attack scenarios” and since they can also be seen as the “direction” or “course” from where the attacker is coming, we often talk about this as the “attack vector”.
One more thing that also defines the attack vector is the amount of resources we estimate our attacker to have when it comes to skills/time/money. securiCAD is considering the attacker to be a very capable attacker, such as a state actor, with large but not unlimited resources. If we want to attenuate this, then we can consider disabling for instance the DevelopZeroDay attack step since we might not consider our attacker to have the resources to develop (or acquire) a zero day exploit, or we consider our architecture/business not being interesting enough for the attacker to spend a zero day exploit on it.
This module will discuss and give examples of different common attack vectors and what attacker connection they correspond to.
Attack Vector Attenuation
From the introduction above, we see that the attacker’s starting point is an attack step which we consider has already happened with 100\% probability and then we analyze what impact that situation has on our model.
Sometimes, it is more interesting/relevant to also introduce a probability to this initial attack step being successful. We can do that by first defining the starting point of the attack and then tuning objects around it to reflect our estimated probability of the attack to be present at all.
This is easier to explain while looking at the examples below, where we will introduce two ways of attenuating the attack vector presence, or actually it’s possibilities to enter our main model.
Please remember that if you do not introduce attack vector attenuation in the model, the results will show the situation when the modeled attack has already happened and the impact such an attack will have on the modeled architecture. Attack vector attenuation is in that way an extra modeling feature that you can add at a later stage in the analysis.