-Cybersecurity is a complex and dynamic area where multiple actors act against each other through computer networks largely without any commonly accepted rules of engagement. Well-managed cybersecurity operations need a clear terminology to describe threats, attacks and their origins. In addition, cybersecurity tools and technologies need semantic models to be able to automatically identify threats and to predict and detect attacks. This paper reviews terminology and models of cybersecurity operations, and proposes approaches for semantic modelling of cybersecurity threats and attacks.
When security incidents occur there is typically limited understanding of who the threat agent is, why they attack and how they operate, which makes it difficult to make well informed decisions about countermeasures. Threat agents who are not identified and made responsible for their actions will continue their criminal behaviour. When we do not understand the attacker we can only see - if even that- the results of the attacker’s actions. Improved cybersecurity requires digital threat intelligence - structured and semi-automated analysis and sharing of information. In order to make sense out of increasingly large and complex datasets related to cybersecurity we see the potential in developing models and tools for automated or semi-automated classification and discovery of cyberthreats based on ontologies.
Semantic technologies and ontologies are a relatively new logic-based landscape of technologies and tools aimed at giving better meaning to large and unstructured corpuses of data. Interesting research challenges are for example to investigate semantic representations of relevant concepts in the domain of cybersecurity big data, in order to facilitate advanced machine learning, search and discovery.
The potential benefit of this approach is that the developed tools and related technologies will provide a flexible framework for representing and structuring the large variety of data with which security analysts are confronted. The framework can further be used for the implementation of cybersecurity analytics tools.
II. CYBERSECURITY THREAT AND RISK MODELS Cybersecurity is the body of technologies, processes and practices designed to protect networks, computers, programs
This research was supported by the research projects TOCSA, ACT and Oslo Analytics funded by the Research Council of Norway. and data from attack, damage or unauthorized access. Cybersecurity thus assumes that some actors, typically called threat agents, have the intent and capacity to produce attacks, gain unauthorized access and cause damage. The magnitude of the perceived potential damage caused by cyber attacks is typically interpreted as security risk.
Cybersecurity risks are caused by threats. However, the concept of a threat can be ambiguous in the sense that it can mean the threat agent itself, or it can mean the thing that a threat agent (potentially) produces, typically called a threat scenario. Figure 1 illustrates a specific risk model which integrates the concepts of threat agent and threat scenario.
motivation
of (threat scenario to cause) incident
Specific Risk
The specific risk model of Figure 1 emphasizes the risk dimension of threats, i.e. how threats lead to risk.
It can be seen that the threat agent and the threat scenario have very different attributes, but in combination they both contribute to risk. A threat agent can be modeled as a real agent with a motivation or goal as well as with a capacity to execute a specific threat scenario. Together, the motivation and capacity produce the strength of the threat agent. The threat agent strength can be modelled according to the weakest
Attacker identity DML-9 Attacker goals
and strategy link, i.e. the attacker is only as strong as the weakest of its motivation and capacity.
A threat scenario can be modelled as a sequence of attack steps which can be stopped by defence and security mechanisms. However, when the defence mechanisms fail to stop a specific threat scenario, we say that there are vulnerabilities.
The more severe the vulnerabilities and the greater the
strength of the threat agent, the greater the likelihood that
the threat scenario will cause a security incident and lead
to damage, as illustrated in Figure 1. The actual risk of a
specific threat scenario emerges by including the amplitude
of the expected damage in case the security incident actually
occurs. Risk assessment models such as in [
There can of course be many different threat scenarios leading to the same goal when seen from the attacker’s perspective. Each scenario represents the dynamic execution of a tactic. The attacker might consider multiple tactics, and then decide to use the one which is assumed to produce the greatest expected result with the least effort.
The threat scenario is an abstract set of steps executed in sequence, which from the victim/defender’s perspective can cause damage to its assets. A threat scenario becomes a cyber attack when the scenario is actually executed. Behind every attack there is thus a specific threat scenario executed by an attacker or a group of attackers. However, a threat scenario by itself is abstract, and does not become an attack unless it is actually executed.
A threat scenario can therefore be interpreted as the blueprint for attacks. For cyber defenders there is thus a fundamental difference between detecting real attacks and identifying threat scenarios which only represent potential attacks.
A model for the maturity of cyberthreat detection has
been proposed by Ryan Stillions in several blogpostings [
The levels of the DML model are briefly explained below.
The focus is on what the IR team (incident response team) is
P
r
e
c
ii
s
o
n
s
s
e
n
t
s
u
b
o
R
capable of doing at each level. Our description is a summary
and interpretation of Stillions’ description [
• DML-0 None or Unknown. There is no IR team, or they are totally clueless. • DML-1 Atomic indicators of compromise (IOCs).
These are elementary pieces of host & network artifacts,
which might have been received from other parties. The
value of atomic IOCs is limited due to the short ‘shelf
life’ of this type of information.
• DML-2 Host & Network Artifacts. This is the type
of information which can be collected by network and
endpoint sensors. With high capacity links the amount of
information collected can be overwhelming and requires
good analytical tools to analyse and understand the attack
at higher levels of abstraction.
• DML-3 Tools. Attackers install and use tools within the
victim’s network. The tools often change, so that a tool
detected and analysed in a previous security incident
might be similar but not exactly the same in new attacks.
DML-3 means that the defender can reliably detect the
attacker’s tools, regardless of minor functionality changes
to the tool, or differences in the artifacts and atomic
indicators left behind by the tool.
• DML-4 Procedures. Detecting a procedure means
detecting a sequence of two or more of the individual
steps employed by the attacker. The goal here is to
isolate activities that the attacker appears to perform
methodically, two or more times during an incident. In
the military jargon, procedures mean “Standard, detailed
steps that prescribe how to perform specific tasks” [
The challenge is to leverage observed attack features detected at low levels to determine derivative causes at higher levels.
Assume that a given company B has as goal to beat company A in the open market. This goal might cause company B to use unethical means, with a strategy to steal secret information from company A in order to improve their own products and market position. Company B’s tactics may be to gain access to company A’s internal servers based on an attack plan with techniques, procedures and tools. Finally, the execution of the plan causes traces of the attack to be left in the network of victim A.
The cyber incident response team will first detect the traces, and from there must try to figure out what has happened and then decide the appropriate response. The traces are indicators, and the task of determining what really happened is a form of abductive reasoning which consists of using the indicators as classifiers to determine the nature and origin of the attack.
Most incident response teams of today are working on DML-1 and DML-2. Some are working on DML-3 and partly DML-6. However, the further up the stack you get the more seldom you find machine readable results from the analysis and work that is done. Defining semantic models for the type of information gathered in the higher levels of the DML model and the relations between them will enable more teams to increase their maturity level. Information sharing will also be facilitated by this development.
III. ELEMENTS OF SEMANTIC THREAT MODELLING Discovering the real nature of a threat given a set of data or information requires a semantic model to represent all aspects of the threats with no room for ambiguous input. The further down the DML model you get, the more precise an identification can be done. The further up, the more costly a change is for the attacker and the more robust your conclusion of identity may become. Both aspects are useful for different roles and situations throughout a security incident. SIEM (Security Incident and Event Management) tools typically use semantic representation of host & network artifacts at the lower levels of the DML model, but rarely provide semantic representations of high level aspects. It is thus necessary to standardise the semantic representations of high level aspects in the DML model. This will allow automated reasoning to leverage the potential of machine learning and classifiers to do advanced cybersecurity analytical reasoning.
The primary focus of the DML model is to indicate levels of maturity in cyberthreat detection. However, the same model can be used as a basis for the design of cyberthreat classifiers, and we call this new model the semantic threat classification model (STCM).
Figure 3 shows the STCM which consists of a compact representation of the DML model combined with classifiers representing the analytical relationships from low level features to high level features.
Classifiers
External intelligence
Attacker goals, strategy and identity Causality
Attack execution plan and methods Causality
Note that there are causal relationships from high level features to low level features. Hence, classifiers are used to reason in the opposite direction to that of causal relationships.
In machine learning and statistics, classifiers are used to determine categories to which some observation belongs, on the basis of a training set of data containing observations (or instances) whose category membership is known. For cybersecurity analytics, a classifier can e.g. be used to determine which type of attack a set of network artifacts belong to (i.e. are caused by), the goal of the attacker or even the identity of the attacker.
Note that contextual information can also be used as input indicators for classifiers. Contextual intelligence can e.g. be political events covered by the media. A political conflict between nation states can make it more likely that states launch specific types of cyberattacks against each other.
The challenge for developing reliable classifiers is to identify appropriate semantic features and their variables at each level of abstraction, and to have available sufficient amount and type of data in order to give the classifiers sufficient training for reliable detection and classification.
The design of classifiers for machine learning is heavily
dependent on statistical methods, and several authors have
pointed out the importance of mathematics for cybersecurity
[
Stillions’ DML model [
Stillions mentions the following goal as an example:
Replicate Acme Company’s Super Awesome
Product Foo in 2 years or less [
If we ignore the time dimension of this goal, then we can derive the 2-tuple (“Replicate”, “Product”) from the informal description.
From Mandiant’s APT1 report [
Another goal can be derived from Symantec’s blog post
on the “Cadelle” and “Chafer” APT groups [
By generalising the examples above, we get the following definition of a goal: (Action, Object). When we observe the 2-tuples from the examples, we identify two challenges. The first challenge is that we use strings to describe each element of the tuple. If we use 2-tuples of strings in a system where a multitude of analysts and classifiers identify and record new goals, then the result will be duplicated by synonyms resulting in an explosion of features. In order to avoid this, our goal is to define a formal taxonomy of goals, where each tuple contains references to the taxonomy.
The second challenge is that the second element of the 2tuple is too general. To alleviate this, we must define subelements that are more specific, e.g. that the “Product” in the first example is manufactured by “Acme company”, and that the specific product is “Super Awesome Product Foo”. In the last example, “Individuals” could have a sub-element “Iranian Citizens”. Note that in some cases we will not be able to determine these sub-elements due to insufficient data.
Applying this approach to all the layers of abstraction in
the extended DML model requires a monumental amount of
effort. We believe that in order to achieve this, a community
effort is needed. Thus, one of our primary goals is to lay the
foundations for such an effort. Furthermore, re-using existing
standards and taxonomies where applicable can significantly
reduce the amount of work needed. A good example of such
re-use can be observed for the abstraction level “Techniques”.
The MITRE ATT&CK taxonomy [
There are several initiatives currently being used for
representation and sharing of data on the different levels of the
DML model. The following initiatives are seen as useful and
may be used when selecting features for representation on the
different levels:
• INTEL Threat Agent Library (TAL) [
IV. EXAMPLE APPLICATIONS OF SEMANTIC CYBERTHREAT
MODELS
In this paper, we argue that semantic cyberthreat models can help cybersecurity professionals to be more effective and efficient. This section presents some concrete examples from our own experience that support this hypothesis.
Breaches due to attacks from advanced persistent threats (APTs) are often detected post-compromise. APTs quickly initiate lateral movement after the initial compromise, so assessing the scope of the breach can be challenging. In order to assess the scope of the breach, we need to know how the threat agent operates and what kind of indicators, artifacts, tools, tactics, techniques and procedures (TTPs) we should search for. The incident response analysis process typically consists of the following steps: 1) Evidence collection 2) Analysis of evidence 3) Identification of new indicators, artifacts, tools and TTPs 4) Threat agent attribution
Steps 1-3 are performed in an iterative fashion. The analysis
results may indicate that we need to collect more evidence, or
that we should search the existing evidence for new indicators.
If we are able to perform step 4 and attribute the breach
to a known threat agent, then we can leverage our historical
knowledge of this threat agent. We can use this knowledge to
guide our evidence collection and analysis. We have used the
MITRE ATT&CK taxonomy [
A common task for threat intelligence analysts is to find all information related to a single data point, e.g. an IP address, a malware sample or a threat agent. Having a semantic model implemented as a graph makes it possible to complete such a task quickly and reliably by issuing a single graph query.
Current intrusion detection systems operate at DML-1,
DML-2 and/or DML-3. One of the challenges with operating
at DML-4 and above is that TTPs are commonly described
using English prose, i.e. as unstructured data. This makes it
challenging to translate the description to intrusion detection
signatures, and signature development must be performed
manually. Defining formal models for TTPs makes it possible
to automatically generate signatures from structured data when
a new TTP is defined. One concrete example is the procedure
described in [
An example would be an adversary running net
time, followed by the AT.exe command to schedule
a job to kick off just one minute after the current
local time of the victim system. [
Given an endpoint security solution that logs process execution with arguments and command inputs/outputs, a human analyst could write a signature to detect this procedure. The signature would have to detect the following: 1) Execution of net.exe with time as the first argument and victim system as the second argument 2) Timestamp returned by the command in step 1 3) Execution of at.exe with victim system as the first argument and ((timestamp from step 2) + 1 minute) as the second argument
Interpreting the description “to schedule a job to kick off just one minute after the current local time of the victim system” is easy for a human, but very difficult for a computer. A formal definition of this procedure would make it possible for a computer to automatically generate signatures for the procedure by applying transformation rules.
Semantic modelling of threats is a promising approach for automated threat and attack detection at multiple levels of abstraction. A semantic model of threats will enable security analysts to work faster and more efficiently in terms of identifying threat agents and take advantage of previous experience and gathered intelligence when handling incidents caused by known or unknown threat agents. The task of extracting semantic features for all levels of abstraction in our suggested extended DML model is an undertaking of daunting proportions. In order to make this task manageable the reuse of related standards and taxonomies is required.