Managing a SOC: Advantages and limitations of the ATT&CK matrix
The aim of this article is to demonstrate that the excellent ATT&CK matrix should be used as a support tool rather than the central element of an information security monitoring strategy. Indeed, it is sometimes assumed that ATT&CK is sufficient to manage a Security Operations Center (SOC), and we will focus here on showing that this framework alone cannot be used to ensure SOC management that is both pragmatic and aligned with security objectives.
The knowledge base MITRE ATT&CK[1] Today, it is increasingly emerging as a leading reference in the world of cybersecurity, whether for SOC, CERT, CTI, or IT (Penetration Testing) teams. It is consistently used, in particular, in specialized publications on cyber threats, such as those from FireEye.[2], Microsoft[3], or even the «"Threat Landscape"» of the CTI Intrinsec[4].
This framework offers, among other things, the advantage of allowing these different cybersecurity professions to speak the same language, based on a the same reference framework that lists and describes offensive operating methods, also called TTP (TTP meaning «Tactics, technics, and Procedures»[5]), which is even evolving, under the impetus of the NSA, into a corollary of defense («D3fend»[6]).
Thus, for example, during a SOC training session (also called «"purple teaming"»The offensive team typically expects to receive a list of TTPs (Triggered Targets) that are supposed to be detectable by the SOC (Security Operations Center). At the end of training, or "purple teaming," both the SOC ("blue team") and offensive ("red team") teams can confirm, TTP by TTP, what was detected and what wasn't. This allows the SOC to improve over time by leveraging feedback from missed detections, and also to verify the presence of traceability before detection (and therefore the depth of coverage of the monitoring).
Furthermore, this framework also allows for the formalization of the methods used by the most frequently observed attackers, thus defining trends and guiding the efforts of SOC and even CSIRT security teams. In fact, MITRE ATT&CK has likely already become the industry standard in the cybersecurity world for documenting offensive methods, both for software vendors and service providers.
However, to date, the ATT&CK matrix comprises 14 tactics, but more importantly, 185 techniques and 367 sub-techniques. In other words, the repository is extensive and constantly evolving! A SOC's ability to cover such a vast repository with 100% seems unrealistic and, above all, largely irrelevant in the client's context. The pragmatic question that arises, therefore, is: Where should the effort be focused on improving SOC detection capabilities? More specifically, how should we choose which techniques, sub-techniques, and even tactics should be subject to cybersecurity oversight in the short, medium, and long term?
Indeed, let's take a concrete example: the use of scripts is one of the most common TTPs (Tactical Threats and Procedures) at the moment, corresponding to the "Execution" tactic in ATT&CK. This TTP is notably often used by various attacker groups who engage in extortion., via ransomware[7] (and possibly prior exfiltration of information, with blackmail involving the threat of disclosure). This can represent a major security challenge for a given organization or company.
But, if in fact, this same entity considers that the phishing is also a major security issue, so the TTPs of the "Command and Scripting Interpreter" technique«[8], referenced T1059, will not necessarily be the most relevant in terms of detection. Conversely, the TTPs of the "phishing" technique«[9], referenced T1566, seem much more suitable.
Yes, but… The real problem is that the sensors[10] necessary for the detection of T1566 are quite different of those for T1059. More specifically, for the "Command and Scripting Interpreter" (T1059) part, the ATT&CK repository lists the following sensors:
- Command Execution,
- Module Load,
- Process Creation,
- Script Execution
Whereas, for the "phishing" part (T1566), the reference indicates the following sensors:
- Application Log Content,
- Network Traffic Content,
- Network Traffic Flow
We can clearly see that the two lists have nothing in common. The work required to establish effective detection capabilities for the SOC, define logging policies, collection strategies, integrate data into the SIEM, and design detection strategies will therefore be heavily impacted. The fundamental question that then arises is: How to define the prioritization of SOC actions, as well as the possible means to acquire and/or deploy (referred to here as sensors) in order to achieve the desired detection capacity?
As is very often the case in cybersecurity, we will be discussing here three bases: technology (therefore certainly financial resources for the acquisition of security solutions, and maintenance in operational condition), people (therefore certainly HR resources to be validated and made concrete through recruitment), and operational (or even organizational) processes to define the overall functioning as well as the exploitation of security technologies. Overall management cannot therefore be improvised., It needs to be framed.
Therefore, if the need for security is formalized through feared events For example, if a user is contacted by email to commit fraudulent acts on the application system (impacting integrity and confidentiality), then the SOC can manage the response efforts much more effectively. Some may recognize this as a scenario similar to the "CEO fraud" scam.«[11], And clearly, the TTP "phishing" seems more relevant, so the Efforts to ensure detection will certainly be focused on messaging logs (MTA and MDA layers of messaging) including anti-spam, as well as on application logs.
And this is certainly where the ATT&CK database shows its limitations, if it were to be used as a single reference and framework to drive a SOC. Indeed, there is no formalization of security needs in the ATT&CK database., nor even its browser[12].
But above all, this framework also lacks a true formalization of the concept of cyber risk, except that one can certainly consider the TTPs in the ATT&CK database as operational scenarios that could lead to dreaded events. [FL3] (in a logic EBIOS RM[13]). This is the approach that the Intrinsec SOC has implemented for over a year, and the feedback is very positive.
Conclusion
The ATT&CK base itself cannot SO be used as single reference to formalize the security needs, nor truly define the priorities for the SOC, because it does not currently include any concept of SOC management. At best, we will be able to achieve a graphical representation of the current situation, in the best-case scenario, with the "Security Stack Mappings".«[14] For example.
However, it can serve as an essential reference for offensive operating methods that the SOC must detect, once they have been validated in the context of the risk analysis used to define SOC needs, and associated with the risks themselves which have been formalized by the security risk analysis.
In other words, ATT&CK can be used as a technical or operational application of the risks formally defined in French within risk analysis. And in this regard, the Intrinsec SOC recommends drawing inspiration from EBIOS RM in terms of methodology.
Dear EBIOS Risk Managers, The SOC is listening to you to improve and define its priorities!
[1] See. https://attack.mitre.org/
[2] See. https://www.fireeye.fr/current-threats/annual-threat-report/mtrends.html
[3] See. https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/
[4] See. https://mailchi.mp/16e75cab7389/threat-landscape-by-intrinsec-5005930
[5] See. https://www.mitre.org/publications/technical-papers/ttp-based-hunting
[6] See. https://d3fend.mitre.org/about
[7] See. https://www.ssi.gouv.fr/administration/glossaire/r/
[8] See. https://attack.mitre.org/techniques/T1059/
[9] See. https://attack.mitre.org/techniques/T1566/
[10] Sensors corresponding more or less to "data sources" in the ATT&CK reference system, the definition of which evolved in October 2021, see. https://medium.com/mitre-attack/introducing-attack-v10-7743870b37e3
[11] See. https://www.economie.gouv.fr/dgccrf/larnaque-au-president-toujours-tres-frequente
[12] See. https://mitre-attack.github.io/attack-navigator/
[13] See. https://club-ebios.org/site/tag/ebios-risk-manager/
[14] CF. https://github.com/center-for-threat-informed-defense/security-stack-mappings
