How to provide Cyber Threat Intelligence in the frame of a modern SOC?

Find out how to use CTI as an Operational Support (part 1)

Introduction to Cyber Threat Intelligence

Cyber Threat Intelligence is a discipline of Intelligence applied to the cyber field. According to Kent’s Analytic Doctrine[1], the role of (Cyber) Intelligence Analysts is to provide “information and insights to policy decision-makers and action-takers”. In the context of a complex entity, may it be an institution or a large company, there could be many different functions acting as policy decision-makers and action-takers:

•     Information Security Management,
•     Risk Analysis,
•     Secure Architecture,
•     Incident Response,
•     SOC,
•     etc.

All of these interfaces, and insights to provide, make Cyber Threat Intelligence a transversal but central function. In this blogpost, we are going to dive deeper on how CTI can adapt its processes and tools to provide operational support to a specific action-taker, the Security Operations Centre (SOC). The second blog post of the series will address how CTI can support a more specific capability of the SOC: the Threat Hunting.

We could review the past years where the SOC integrated new technologies (SIEM / UEBA, IDS/IPS, NextGen Firewalls, DLP, EDR, NDR, xDR, SOAR, cloud migration, you name it…)[2] new capabilities (Incident Response, CTI, Threat Hunting, Vulnerability / Extended Threat Management…), improved its processes (automation, orchestration, machine learning, analytics…) and adapted to disruptive events like the COVID-19 pandemic (new threats, remote working, virtual collaboration…). From legacy structures mainly involved in passive detection mode, modern SOCs are now highly integrated CyberSecurity Operations Centres providing proactive monitoring and reactive remediation with a lot of automated processes, combined with human expertise.

In that context, CTI also has to adapt its ways of working to new intelligence requirements, and should adapt the architecture of its platform, the Cyber Threat Intelligence Platform (CTIP), to ensure the dissemination of the right intelligence product to the right action-taker or decision-taker. In this blogpost, we are going to browse the different steps of the Intelligence Production Cycle, and try to figure out what needs to be anticipated and taken into account to fulfill SOC intelligence gaps.

The Intelligence Production Cycle:

“Traditional” intelligence institutions often describe the process of producing intelligence in a cycle called the Intelligence cycle, or Intelligence Production Cycle. While variants do exist, it is usually represented as a 5-steps cycling process, with continuous evaluation & feedback:

Fig. 1: The Intelligence Production Process 

It might not be the most recent and optimized Intelligence Production process, though it can be used as a basis and will be helpful to illustrate this article.

Planning & Requirement

This process stage describes the management of the entire Intelligence effort, from identifying the need for data to delivering a relevant intelligence product to a consumer to cover a knowledge gap. It is time to identify the action-takers (e.g. SOC Analysts, Threat Hunters, Incident Responders…), the decision-makers (CIOs, CISOs, Incident Manager…) and the associated use cases you’re going to support with the delivery of Intelligence. Best practices include:

•     Co-defining the Intelligence Requirements with the Intelligence Consumer,
•     Keeping the Intelligence Requirement simple (only one question per requirement),
•     Defining the format of the final Intelligence product,
•     Planning all the steps of the Intelligence Production Cycle, including validation & feedback stages.

Examples of Intelligence Requirements could be:

•     For Proactive Security Operations:
  • “What are the attackers that can be considered as a Threat to my business (Threat Models)?”
  • “What indicators (IoCs, IoAs…) can be used to detect specific Adversaries on the perimeter I need to defend?”

•     For Threat Hunting:
  • “What requests should be performed on my information systems to detect specific adversaries trying to bypass security means during Threat Hunting activities?”

•     For SOC Security Alert Enrichments:
  • “What enrichments can CTI bring to artifacts contained in a SOC Security Alert?”

Many different Intelligence Requirements could be defined with the SOC action-takers or even with the decision-makers (e.g. CIO, CISO…). First synergies might start to appear. For example, different action-takers or decision-makers might share Intelligence Requirements, dread similar impacts or even show overlaps in their Threat Models. 

Collection

The Collection step is the process of acquiring the raw data from all the sources identified as necessary to fulfill an Intelligence requirement during the Planning & Direction step. There is an infinity of sources that can be collected: 

•     Internal Data: data coming from inside my information Systems:
  • System & Network logs,
  • SOC Security Alerts, Security Incidents,
  • Telemetry or direct requests (EDR, NDR, SIEM…),
  • Application logs,
  • Incident Response Reports,
  • Threat Hunting Reports,
  • etc.

Internal data sources are particularly precious in a SOC environment. Every chunk of information gathered, or any malicious behavior observed on one perimeter might bring valuable intelligence, and allow a global rise of the security level by adjusting the security posture accordingly. Having access to the relevant internal data sources should be a priority for a CTI team, as it would allow a precise contextualization of each detection raised by the SOC. 

•     External Data: data coming from sources outside of my information Systems:
  • Threat Reports (OSINT, Community, Commercial),
  • Feeds (OSINT, Community, Commercial),
  • Malware Databases (OSINT, Community, Commercial),
  • etc.

From a CTI integration perspective, it is important to be able to collect all sources at a CTIP level, allowing to capitalize all the knowledge in a single database, with a coherent and uniform structured data model. This will be achieved thanks to the next process step.

Processing & Exploitation

The Processing & Exploitation step consists of synthesizing the raw data into a usable state. In our case, it means extracting the information you need for your analyses from the collected sources, and to store them in a consistent and structured data model. As this step doesn’t really produce any added value for external data sources, automation efforts might be relevant (e.g. feed connectors).

Commercial and open source CTIP comes with different structured data models. Though it might be interesting to go for a standard in an information system environment that can be heterogeneous in terms of technology solutions. Structured Threat Information Expression[3] (STIX™) is a language and serialization format used to exchange CTI. It is an open standard produced by the OASIS Cyber Threat Intelligence Technical Committee[4].

In addition of being relevant for all CTI processes, it integrates some really nice features that can be leveraged for SOC operational support, such as the Sighting STIX Relationship Object[5], denoting the belief that something was seen (Indicator, Malware, Campaign…) or the Course of Action STIX Domain Object[6], describing an action to take either to prevent an attack or to respond to an attack that is in progress. A central STIX Object in the context of a SOC is the Indicator STIX Domain Object. It contains a pattern that can be used to detect suspicious or malicious cyber activity. The STIX™ supports different patterns to express Indicators (STIX pattern, Perl-Compatible Regular Expressions, Sigma, SNORT, Suricata, YARA) in the frame of its Pattern Type Open Vocabulary[7], and it does not limit the user to that defined list. This vocabulary can be completed by the user with other Indicator patterns. The formats supported natively by the STIX™ standard allow a smooth information exchange, while its flexibility allows the integration of more specific use cases.

Once the information is captured, it can be enriched. The point of enrichment is to add information to your information, meaning to add context that supports analysis and decision making. Different web services, commercial or not, can be used to add context (WHOIS lookup, geolocalisation, reputation…). Investigations and pivots can also be performed, in order to discover new related pieces of information. Once again, web services can be leveraged to support that effort (DNS / pDNS records, Portable Executable hashing algorithms, code-signing Certificates, SSL certificates, Malware databases, you name it…).  As Enrichments and Pivots can be provided as services to other functions than CTI, it could be interesting to keep these capabilities available at a SOAR level, and to call them though relevant playbooks.

Analysis & Production

The Analysis & production of intelligence is the conversion of your collected and processed information into intelligence. It includes the analysis and evaluation and analysis of all available data, and the preparation of the final intelligence products, from pieces of information disseminated separately (e.g. IoCs), to final reports which draws separate pieces of information together to identify patterns and draw conclusions. It is time to use your Structured Analytic Techniques to mitigate cognitive biases and logical fallacies, and to assess reliability, validity, timeliness and relevance of the produced Intelligence, which must include assessment and judgments about the implication for action-takers and decision-makers.

In terms of technical toolings, some capabilities might be handy to provide adequate tactical and operational Intelligence. As an example, we can think of a Malware Sandbox to safely observe the behavior of malware in a controlled environment. Some Malware Sandboxes have additional analysis engines based on antivirus detection or static analysis. Such technology might allow us to quickly extract malware IoCs, and give some ideas about actions performed by malware on the victim environment, and therefore crafting some relevant Threat Hunting requests to check the monitored information systems for infection. 

As these capabilities could also be provided as services to other functions than CTI, keeping them available at a SOAR level, and calling them though relevant playbooks can be considered.

Dissemination

Now that the Cyber Threat Intelligence is produced in the right format, it needs to be sent to the right action-taker or decision-maker to fulfill their knowledge gap. Once again, in a heterogeneous information system environment, going for a standard is often the right choice. In parallel of STIX,  the OASIS Cyber Threat Intelligence Technical Committee specifies the Trusted Automated Exchange of Intelligence Information (TAXII™)[8],  an application protocol for exchanging CTI over HTTPS. ​TAXII™ defines a RESTful API and a set of requirements for TAXII Clients and Servers.

On the other hand, TAXII doesn’t define trust agreement, governance and other non technical aspects of collaborative work. Defining these elements is important to manage the sharing boundaries of potentially sensitive intelligence. The Traffic Light Protocol (TLP)[9] is commonly used in that context of information exchange.

The actual dissemination can be done according to what has been defined with action-takers and decision-makers during the Planning & Requirement step, through dedicated and adequate playbook at a SOAR level. This would ensure that the security solutions are receiving automatically the intelligence they are able to process, and to the humans involved to receive the expected Intelligence in the appropriate format. CTIPs usually integrate a tagging system that can be leveraged by the playbooks to ensure appropriate dissemination.

Proposed CTI Functional & Technical Architecture

In order to summarize the content of this blogpost, here is a proposition for CTIP architecture in the context of a modern SOC, including the CTI process steps of the Intelligence Production Cycle:

Fig. 2: Proposed CTIP Architecture

In the next episode of this series of blog posts, we will discuss how CTI can support Threat Hunting activities, including requirements, processes and tools.

Bibliography

•     Kent Center Occasional Papers: Volume 1, Number 5

https://web.archive.org/web/20201102212401/https://www.cia.gov/library/kent-center-occasional-papers/pdf/OPNo5.pdf

•     Introduction to STIX

https://oasis-open.github.io/cti-documentation/stix/intro

•     OASIS Technical Committees by Name

https://www.oasis-open.org/committees/ 

•     STIX Version 2.1

https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html

•     TAXII Version 2.1

https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.html

•     Traffic Light Protocol (TLP)

https://www.first.org/tlp/

 ———-

[1] https://web.archive.org/web/20201102212401/https://www.cia.gov/library/kent-center-occasional-papers/pdf/OPNo5.pdf

[2] Cybersecurity jargon busting: MDR, SOC, EDR, XDR, SOAR and SIEM

[3] https://oasis-open.github.io/cti-documentation/stix/intro

[4] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti#overview

[5] https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html#_a795guqsap3r

[6] https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html#_a925mpw39txn

[7] https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html#_9lfdvxnyofxw

[8] https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.html

[9] https://www.first.org/tlp/

• Share