Release #3: Terminology, Frameworks and Standards - Part 1

In my previous blog posting we defined our CDC, the function it provides and introduced some basic terms. Next we will look at catalogues and models that help defenders to understand the actions of attackers. The MITRE ATT&CK catalogue categorizes typical attack techniques and tactics and provides many additional information which is often very helpful in the daily life of a CDC architect or analyst.

Info Box	Tactics, Techniques and Procedure (TTPs)
!	TTPs are an attacker's actions, regardless of the phase in the kill chain. This refers to tactics, techniques and procedures, not the underlying strategy.

 

MITRE ATT&CK™ Matrix

The MITRE ATT&CK™ Framework describes itself on the web page (https://attack.mitre.org/) as follows: MITRE ATT&CK™ is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community.  

This framework is the result of insights into monitoring active attacks and the recognition that TTPs are often repeated.
 

Info Box

Living of the Land (LOTL)

!

In recent years, attackers have moved to not using their own tools, but to use the already existing tools of e.g. Windows and Linux, i.e. the attacker does not bring his weapons with him, but uses an existing tool ("double use", like a knife or hammer) for his malicious activities. The advantage is that malware scanners and IDSes do not sound the alarm for genuine software. This tactic is known as "Living of the Land" (LOTL) and is not really new, as in the 80s and 90s this was often done, albeit for other reasons (compiling your tools for exotic unix machines was somethimes not possible). A company can respond to this in two ways, first of course preventively (NIST SP 800-61, phase "Preperation") by have a very restrictive rights and access management regime and at the detection phase (NIST SP 800-61 "Detection & Analysis"). This can be done by bahavioral analysis or by defining simple rules, like Excel will never use PowerShell etc.

 

The MITRE ATT&CK Matrix for Enterprise has 12 phases or categories that can be understood as extending and clarifying the kill chain phases during and after the exploitation phase. The categories are:

1. Initial Access
2. Execution
3. Persistence
4. Privilege Escalation
5. Defense Evasion
6. Credential Access
7. Discovery
8. Lateral Movement
9. Collection
10. Command and Control
11. Exfiltration
12. Impact

 

(The TTPs of the attackers have been divided into the above categories, see table (not complete).) 
 
MITRE describes these TTPs very precisely - take a look at the example of "Credential Dumping" (https://attack.mitre.org/techniques/T1003/). Here are concrete tools and services of Windows and Linux described as well as ways to mitigate the vulnerability and to detect an attack. In the CDC the corresponding SIEM use cases can be developed with the help of this information and the right kind of log events. Here is a snapshot of the corresponding entry from mitre.org.

 

Unified Cyber Kill Chain

The Cyber ​​Kill Chain (CKC) was developed in 2011 by employees of Lockheed Martin Corp.  to better understand the constant attacks on their infrastructure and to be able to counteract somehow. An attack is divided into 7 phases, whereby the initial break-in to the infrastructure is the so-called Exploitation phase and before the Exploitation phase there are 3 phases for preparation and after the exploitation phase there are also 3 phases for consolidating access and achieving the  actual goal (fraudulent money transfer with SWIFT, manipulation of clearing systems,  write access to the ATM backend infratructure for software distribution, etc.).

The "Cyber ​​Kill Chain" was derived from the military concept of the "Kill Chain", which is abbreviated to "F2T2EA": 

• Find: observing on the target, gathering information
• Fix: find the location of the target
• Track: monitor the target's movements
• Target: evaluate the target's capabilities and choose the most effective weapon / approach
• Engage: use weapon
• Assess: evaluation of the attack effectiveness

 
Here, the Engage phase would be equivalent to the Exploitation phase in the Cyber ​​Kill Chain.
  

(Source: https://en.wikipedia.org/wiki/Kill_chain) 

As valuable as the "Cyber Kill Chain" was for Lockheed Martin in the situation at the time and as attractive as it is today, for understanding cyber attacks it lacked many important facts and had had to be renewed.
 
Six years after the publication of the of the Cyber Kill Chain, Paul Pols created the Unified Kill Chain (UKC). The UKC removed many of the disadvantages of the CKC and also uses the Mitre ATT&CK framework for the exploitation and lateral movement phase. This makes the model very useful for many important things some of them will be shown later.
 
 

 (Source: https://en.wikipedia.org/wiki/Kill_chain)
 
 
The Unified Kill Chain (UKC) will appear more frequently in this blog because it can serve as a guide for security analysts in the incident response case, the SIEM use cases ("rule", "correlation search", whatever you call it) can be developed so that they can be assigned to the individual phases and it serves excellently as a semi-qualitative scale for the criticality classification of the SIEM use cases and the alarms generated from them. But more on this later.
 
The strength of the UKC is also demonstrated by mapping it to existing models.
 

(Source: https://www.csacademy.nl/images/scripties/2018/Paul-Pols---The-Unified-Kill-Chain.pdf)
 
With the UKC you have a very powerful tool at hand. The CDC anylasts have a common view and use common terms to describe an attack and more importantly if an analyst receives an alram from the SIEM for a use-case that was implemented to detect a TTP at step #11 "Privelege Escalation" she can be certain that these event ins't an isolated event but stands in the context of other actions that happend before and will happen afterwards. Then she can go an look for other signs of the attack, the focus could even be narrowed if the TTP is typical for an attack or an actor than previous and following actions might also be typical.
 
You should agree to standards, best practices and models before you start to design your CDC. This will not only help you during your daily life but will also show a coherent picture to the auditors that will verify your CDC.
 
What I really like a lot of the UKC is that you can directly use it to set a criticality level for a SIEM use case which directly sets the priority of a SIEM alarm. And not only that, if your CDC analysts develop a Playbook (basically instructions for analyzing and handling a potential security incident - a details on it later, sometimes called Runbook) for let's say "a phsishing incident", then they can use the same Playbook for SIEM alarms as well as calls on the hotline or tickets opened in the ticketing system, with the same priority and the same set of instructions.
 
Here is a possible example that can be adjusted for your needs, it is based on the following diagrom from Paul Pot's paper:
 

 
 Putting it all together:

UKC Phase	Criticality or Impact of potential Incident (Alarm)	Priority for Triage
Initial Foothold Reconnaissance Weaponization Delivery Social Engineering	low	low
Initial Foothold Exploitation Persistence Defense Evasion Command & Control	medium	medium
Network Propagation (Office Network)	high	high
Network Propagation (internal/high protection-level Network)	critical	critical
Action on Objectives (on "Crown Jewels")	crisis	crisis

The "Initial Foothold" phase should be divided because "Reconnaissance" has a much lower impact than "Exploitation". And because the "Credential Access" on the outer rim office network is less serious than on a server system for a clearing application for bank transactions in the production network, the quantitative "Impact" value differs too.
 
Maybe you ask yourself what sense it makes to have a "Impact" and a "Priority" column with the same values. If you like you can add a asset value as additional column between impact and priority and calculate the priority based on Impact x Asset-Value (like in Risk Assessment). For example your SIEM might be able to use the asset value or security level of the asset from an asset inventory DB and calculate the priority dynamically based on the effected asset... or you just make your life simple and assign a hardcoded qualitative value like we did here. No matter how you do it, the auditors want to see that you have a structured way to prioritize alarms in the CDC and also have a meaningful (based on standards and best practice) way to assign an impact level to potential security incident.
 
If you build a CDC in a highly regulated company it is very likely that it is also part of your nation's critical infrastructure and under this circumstances their might already be a Crisis Management process and/or Business Continuity Management incident response team in your company. Use their language and their models because in case of a critical incident or at a crisis a CDC will not be able to handle the incident alone. When a crisis happens the organizational overhead and the communication requirements increase a lot, it would be naive to copy this functionality in the CDC but not use the existing processes, especially when it comes to customer communication, press releases and 24x7 incident handling.
 
Just an idea, as we are at the topic: The table above could be enhanced by another column to add an escalation step based on the criticality of the incident.
 
And... no matter what kind of "Impact" and "Priority" values you use, it should match the already existing models in your company.
 
During my time serving as Department Lead of a Cyber Defense Center I was involved in about 4 or 5 crisis situation (not anytime a security issue, and not everyone was affecting our company directly but we gave support to subsidiary companies).
During the incident handling you sit in a dedicated crisis room with its own physical access control, you are connected to other crisis rooms at the different locations via big video screens, everyone in the company that has a role in handling the crisis is on board, in regular meetings you check the progress of the incident response plan. If someone cannot attend he or she has to name a backup/deputy. Communication content and timing for reports to Government and banking offices (like for PSD2 or BSI Kritis), customers, and the public is agreed on, and the crisis team organize a 24x7 coverage of Crisis Managers, that handle the crisis meetings. they have the power to give order to everyone in the company no matter what hierarchy level they live at. This is the power and support you need in a CDC when it gets rough and dirty.

And by the way, most importantly you get food and coffee and don't need to leave the room.
 
Ok enough of old war stories. Next we will have a look at useful models that describe and support the work of the defenders.
 
Cheers,

Thomas