The concept of CTI is as old as war. Understanding a threat actor's intentions, capabilities, objectives, resources, and thought process leads to a better-informed defender. Ultimately, the end result of intelligence could be as simple as updating a firewall block policy with a feed of known malware Command & Control (C2) infrastructure. Additionally, it could be a dossier on threat actors targeting your organizational industry vertical. Ultimately, a better-informed defender can make actionable changes in an organization's risk profile by better directing all lines of business within an organization.

Ask any IT security professional what CTI is, and you'll likely get different definitions. The definition of threat intelligence almost always varies from organization to organization. This is often due to the differing motivations within each organization for having a threat intelligence program. We're not going to wax poetic about the differing threat intelligence definitions, so instead, we'll focus on the definition as it relates to this book.

If we were to distill down what CTI is, simply put, it is data and information that is collected, processed, and analyzed in order to determine a threat actor's motives, intents, and capabilities; all with the objective of focusing on an event or trends to better inform and create an advantage for defenders. Many organizations face challenges regarding CTI functions – such as a flood of alerts generated from an automated API feed. A properly executed CTI collection and enrichment program can help assist with those challenges.

Data, information, and intelligence

When talking about CTI, it's important to differentiate between data, information, and intelligence. It's important to understand the distinct differences between data, information, and intelligence so that you can store, analyze, and determine patterns more efficiently. As an example, a URL is a piece of data that contains a domain – the registrant data for that domain is information, and the registrant being commonly associated infrastructure with the Threat Actor Group (TAG) APT29 would be considered intelligence.

Important Note

This is the first time we've used the acronym of TAG. To clarify our vernacular, a threat actor is a person or entity responsible for malicious cyber activity. A group of threat actors working in unison is called a TAG and, often, is identified directly through naming conventions such as APT29, which was referenced earlier. We'll be covering more on TAG naming conventions in Chapter 2, Threat Actors, Campaigns, and Tooling.

Data is a piece of information, such as an IP address, malware hash, or domain name. Information is vetted data, but often lacks the context that is needed for strategic action, such as an IP address with no malicious/benign categorization or contextualization. And finally, intelligence is adding a layer of analysis and context to that information and data and, therefore, making the intelligence actionable, such as a feed of malware hashes associated with cybercrime actors operating out of Europe.

To help in adding context, examples of each can be found in Table 1.1:

Table 1.1 – Table demonstrating data, information, and intelligence

The process of converting data into threat intelligence includes a combination of collection, processing, analyzing, and production, which will be explored later in the chapter.

Understanding the importance of threat intelligence and the differentiation of data, information, and intelligence is paramount to a structurally sound CTI program. Now that we've looked at those important aspects, we're going to dive into understanding the difference between the different types of intelligence: tactical, strategic, operational, and technical.

When thinking about CTI, it's easy to assume that it is one discipline. On the surface, an analyst collects data from several sources, analyzes that data, and synthesizes intelligence, which, ultimately, helps the organization take action. However, closer inspection reveals there are really four distinct types of CTI.

Tactical CTI

Tactical CTI is the data and information related to the Tactics, Techniques, and Procedures (TTPs) used by threat actors to achieve their objective. Ultimately, tactical CTI is intended to inform defenders, threat detection and response engineers, incident responders, and other technical teams throughout the organization in order to motivate an action of some sort. Unlike strategic CTI, tactical CTI is almost exclusively used by technical resources. Usually, tactical CTI is consumed directly by those responsible for defending an organization.

The most common deliverables include targeted reports, threat feeds, and API feeds of malicious observables. Many of the reports that are generated focus on the technical details pertaining to a malware family, threat group, or campaign of activity. Some examples of what might be included in tactical CTI reports include the following:

• Targeted industries
• The infection vector of the threat actor
• The infrastructure used by the attacker
• Tools and techniques employed by the threat actor

To produce tactical CTI, a combination of open source and vendor-provided intelligence and data is most often used. To create tactical threat intelligence, the producer should employ an active collection and enrichment process. Some examples of sources of tactical CTI include the following:

• Malware analysis details
• Honeypot log analysis
• Internal telemetry data
• Scan data (such as Shodan.io)

Next comes strategic CTI.

Strategic CTI

Strategic CTI is often non-technical threat landscape information that is related to risk-based intelligence and, typically, includes relevant industry vertical intelligence. Strategic CTI is most often used by senior decision-makers throughout organizations.

The most common deliverables include reports or briefings. It's common for the data sources for strategic CTI to be open source and include a wide variety of sources. Take a look at the following:

• Local and national media
• Government policy documents
• Industry reporting
• Content produced by industry organizations
• Social media activity

Let's move on to operational CTI.

Operational CTI

In an ideal world, CTI would enable preventative action to be taken before a threat actor compromises an organization. Operational CTI is intelligence unearthed about possible incoming attacks on an organization. Operational intelligence is typically technical and strategic in nature and includes information pertaining to the intent, capabilities, and timing of impending attacks. This provides insight into the sophistication of the threat actor or group, helping dictate an organization's next steps. Operational CTI helps enable defenders to block activity before the activity even takes place, but due to this, operational CTI is, most often, some of the hardest to generate.

The most common deliverable for operational CTI is spot reports with technical indicators and context extracted from other strategic intelligence. There are many sources that can generate this type of CTI, including the following:

• Intercepting the chat logs of threat actor coordination
• Social media
• Chat rooms and instant messaging rooms (such as Discord or Telegram)
• Underground forums and marketplaces
• Public and private forums and message boards

Next, let's take a look at technical CTI.

Technical CTI

Technical CTI is exactly what it sounds like – technical indicators related to an actor's tools, malware, infrastructure, and more are used to conduct their activities. Technical CTI differs from tactical CTI because technical CTI most commonly focuses on Indicators Of Compromise (IOCs), and tactical CTI relies on analyzing TTPs.

For example, say tactical threat intelligence indicates that the financially motivated criminal group FIN7 has attacked the banking industry in the United States and Europe. Technical threat intelligence would provide the specific hashes, infrastructure, and other details pertaining to the specific attack.

Ultimately, technical CTI is intended to inform defenders, threat detection and response engineers, incident responders, and other technical teams throughout the organization. The most common deliverables include the following:

• Feeds or reports including malicious hashes, infrastructure, and other file attributes
• Changes to a system infected with specific malware; for example, registry modifications
• Confirmed C2 infrastructure
• Email subject lines
• Filenames or file hashes

Sourcing technical threat intelligence comes from a litany of locations, for example, consider the following:

• Information security industry blogs and white papers
• Malware analysis
• Industry trust groups
• Threat feeds

To wrap up, in the following table, let's examine the distinct differences when comparing and contrasting each intelligence type, their respective audiences, and length of intelligence value:

Table 1.2 – A table comparing intelligence types

Within each of the CTI types, there is often a conversation about Subject Matter Expertise (SME) and relative team function. In the following section, we're going to explore the concept of SME within each CTI type.

Subject matter expertise

The concept of SME is a common conversation among threat intelligence circles. When setting up a threat intelligence program, it's important to consider the possible positives and negatives associated with dividing relative team functions among three broad SME focus areas: vulnerability and exploitation, cyber (criminal and nation-state), and brand:

Table 1.3 – Intelligence SME types

While CTI functions employing subject matter experts don't fit every team structure, it's an important consideration to take into account when constructing a team focused on CTI. In the following section, we're going to dive into the importance of CTI and its relative uses and benefits to an enterprise.

I think it can wholeheartedly be stated anywhere within this industry that CTI is important to everyone as it provides contextual information that allows for strategic decision-making. This context allows it to be used by almost any level of analyst or researcher throughout any organization. Its use is not limited to some elite subset of intelligence analysts who claims to know every move of a TAG. Key judgments can be formed from contextual intelligence at any level of employment; from a Security Operations Center (SOC) analyst implementing a firewall policy change after receiving intelligence that a URL is serving a web shell that is known to be associated with several TAGs or even a C-level executive making informed strategic decisions to improve the security posture of their organization.

However, to utilize threat intelligence, several key factors need to exist for it to be useful. First, it needs to be timely in the sense that the delivery of information is provided to a key decision-maker before a key event so that a judgment can be formed around its context. Second, the intelligence must be actionable, that is, the intelligence provided should allow for that key judgment to be realized and a decision made that allows the individual or organization to make a decision based on its delivery. Third, intelligence should be relevant. By actionable, we're referring to the ability to take any action based on the intelligence itself. Finally, intelligence must be delivered in a format that has the lowest barrier to entry for consumption by an organization. This means that any individual or organization that wishes to benefit the most from the existence of CTI must incorporate it into their processes and procedures or even develop security automations around it.

The context of the threat provided by the intelligence is where its value truly lies, as it assists any individual or organization with prioritization, which is one of the most important benefits of threat intelligence. No matter what security role you play in an organization, your role will benefit from the context that threat intelligence provides, as this will allow you to prioritize your key decision-making around the data your organization is consuming.

For example, let's consider this paradigm. Organizations that are only now beginning to look at implementing some form of threat intelligence program into their security organization often start by identifying free data feeds or online services that contain some form of security information, usually in the form of a threat data indicator or IOC. While this is a great start in the collection of data and information that could be used to create threat intelligence, without the context surrounding this information and the appropriate indoctrination by people, processes, and technologies, this approach usually leads to just more information and the encumberment of your human workforce.

With all of this extra information, the burden is just added to your analyst to decide what to review and prioritize and what to ignore. This approach can lead to operational misses, such as incidents that could have been prevented if the appropriate prioritization were placed on the information you were receiving from your threat data feed. CTI can assist in providing context around this information that you receive and give you key insights into the TAG's TTPs. This will assist in informing your decision-making and help you prioritize your actions based on the contextual intelligence provided.

Now that you're aware of the uses and benefits of CTI, let's explore how to get CTI.

Getting information about threats is relatively easy; either you're creating data through internal product telemetry, you're collecting from a data feed, or you're doing both. Data and information that can be used as a foundation for threat intelligence is just a Google search away. This kind of search will present you with lots of sources that provide threat data in the form of feeds that you can utilize to begin the evaluation and intelligence enrichment processes. One important thing to note, though, is that this information is not CTI but threat data feeds. Once you have it in place, you will still need to go through the process of considering whether the information is credible, actionable, and timely as well as considering how you will work it into your internal standard operating procedures or security automations. Right now, I want to walk you through the process of gathering some technical information from an open source resource published on the internet. This will give you an introduction if you are starting your journey from scratch.

Some of the most common indicator types that individuals and organizations are seeking some type of context and reputation for are URLs, domains, and IP addresses. These indicator types are riddled throughout the logs of any corporate ecosystem, and nobody with any kind of digital footprint is doing business without accessing some form of these. Domain, URL, and IP address reputation intelligence can assist internet users to determine whether the internet endpoint is safe, suspicious, or even malicious, essentially allowing the individuals or the corporation to protect themselves against any known malware source, its delivery mechanisms, or any malicious content on the web.

Let me introduce you to a free web-based service called urlscan.io. Their mission is to allow anyone to analyze unknown and potentially malicious websites easily and confidently. According to their website (https://www.urlscan.io), the following is true:

When a URL is submitted to urlscan.io, an automated process will browse to the URL like a regular user and record the activity that this page navigation creates. This includes the domains and IPs contacted, the resources (JavaScript, CSS, etc) requested from those domains, as well as additional information about the page itself. urlscan.io will take a screenshot of the page, record the DOM content, JavaScript global variables, cookies created by the page, and a myriad of other observations. If the site is targeting the users of one of the more than 400 brands tracked by urlscan.io, it will be highlighted as potentially malicious in the scan results.

The urlscan.io service itself is free, but they also offer commercial products for heavy users and organizations that need additional insight.

To begin utilizing urlscan.io, simply navigate to their website and type the URL you are seeking a reputation for into the form field at the top of the page, as referenced in Figure 1.1. Then, click on Public Scan to begin the process:

Figure 1.1 – The urlscan.io landing page

Once you click on Public Scan, urlscan.io goes through the process described earlier to initiate some form of reputation determination regarding the site you are seeking questions about. It will provide you with the results of its analysis and even a verdict that you can utilize for decision-making. Examples of malicious urlscan.io results can be seen in Figure 1.2, along with all the additional observable information produced during the scan of the URL:

Figure 1.2 – The urlscan.io results for a malicious domain

You can clearly see in the results of the URL scan that urlscan.io believes this domain contains some form of malicious activity specifically targeting Credit Agricole, a financial services company based out of France. You can see in the results of the scan that there is a large amount of data and information produced about the URL that can be collected and utilized as a part of creating your CTI.

If you click on the Indicators tab on the website, you will be presented with Figure 1.3:

Figure 1.3 – The Indicators tab on urlscan.io

The results of the URL scan allow us to provide you with a small demonstration of how data can be transitioned into information that can be utilized as the foundation for CTI. In the following list, you will find a sampling of indicator data from the URL scan along with the indicator types:

• URL: https://www.dorkyboy.com/photoblog/templates/smokescreen/styles/js/mdddss/lmmnodejs/
• DOMAIN: dorkboy.com
• IP ADDRESS: 174.136.24.154
• HASH: 1c8399c9f4f09feb8f95fe39465cc7e70597b0097ad92da954 db82646ec68dc3
• HASH: 7b0da639a2ad723ab73c08082a39562aa3a2d19adb7472f1 dbb354c5fd0b4c20

In this example, the URL indicator was the first piece of data that was utilized to start an operation investigation for this use case. Through the utilization of urlscan.io, it was determined that the associated indicators could be tied to the initial data. Often, this is called pivoting and is part of the hunting and enrichment process that we will describe, in detail, in later chapters. This hunting and enrichment process provides us with information we can then utilize to create our threat intelligence. Finally, based on the result set, we can see that the URL is malicious and that the threat actor performing the malicious activity is specifically targeting the financial services industry in France. Further investigation would show that the URL points to a phishing kit deployed on a compromised website, which is being utilized to collect account credentials.

Based on all the information provided here, you can see that in the right context, strategic decisions about the URL can be made to protect your users or harden your security posture.

Important Note

It is important to note that in the preceding example, the URL is specifically malicious in this instance – this does not always mean that the domain should be categorized as the same. Often, legitimate domains are compromised, and threat actors upload kits meant to target specific brands and will specifically socially engineer users to the deep URL within the domain. Once a compromise has been identified, the domain owner will go through the process of cleanup to eliminate the malicious URLs in the domain. Malicious categorization contains a timeout and revaulation period, ensuing the verdict is accurate and any initial malicious categorization should expire or be reevaulated.

Almost any organization can retrieve and receive CTI, but that doesn't necessarily mean that the intelligence is actually usable and good. In the following section, we're going to take a deep dive into what constitutes good CTI.

Almost anyone can generate threat intelligence. However, not everyone can generate good threat intelligence. In order to generate threat intelligence that is considered good and is useful, there are five key traits to consider in combination with the Admiralty, source, and data credibility ratings. When combining all of these key concepts together, the end result should generate timely, accurate, and useful threat intelligence.

Let's look at the traits of good CTI.

The five traits of good CTI

When thinking of CTI in general, there are five key traits that can be distilled down to illustrate what constitutes good CTI.

Those five traits include the following:

• Accuracy: Is the intelligence correct in every detail? This is a key concept ensuring that only accurate intelligence is retained.
• Completeness: How comprehensive is the intelligence? Completeness helps ensure all related intelligence is gathered and collected.
• Reliability: Does this intelligence contradict other trusted sources? Reliability means that a piece of information is reliable and doesn't conflict with another piece of information or data in a different source or system. When data or intelligence conflicts from two sources, that intelligence then risks becoming untrustworthy.
• Relevance: Do you really need this intelligence, that is, in terms of the geographical location and/or nature of the business your organization is in? Looking at relevance establishes a need for intelligence. If irrelevant intelligence is being gathered, time is being wasted along with the possible pollution of current or future collected intelligence.
• Timeliness: Is the intelligence up to date? Simply put, intelligence that isn't timely can lead to analysts making the wrong decisions based on historical or incorrect intelligence. Timeliness ensures decisions aren't made with stale information.

There are many methods available to ensure the accuracy, completeness, reliability, relevance, and timeliness of intelligence. However, one tried and true method for ensuring those are met is a framework called Admiralty.

Admiralty ratings

The Admiralty System or NATO System is a method for evaluating and rating collected intelligence. It consists of a two-character notation that evaluates the reliability of the source and the assessed level of data credibility of the intelligence. Employing Admiralty ratings to collect intelligence is an important data quality and source reliability assessment tool.

Source ratings

Understanding the reliability of an intelligence source (automated, semi-automated, or human) is paramount when considering onboarding an intelligence source. A source rating should be applied to intelligence that is collected and analyzed.

Applying a source rating is an important process in CTI as it serves as a historical ledger of activity of the source of the intelligence, making it easier for perusal in the future. When examining source ratings, sources are classified in order of decreasing reliability, with A being the most reliable:

Table 1.4 – Data and intelligence source reliability scale

Source ratings play an important part in any CTI program. Source ratings help establish a baseline trust rating for any source – whether that is data or human in scope. In the following section, we're going to discuss an additional part of CTI: data credibility ratings.

Data credibility ratings

Within CTI, it's important to trust but verify the data sources of threat intelligence. Assigning a credibility rating to threat intelligence helps to establish the fundamental accuracy of an organization's CTI program. Additionally, when employed, credibility ratings help establish a profile of the intelligence that is being collected. And finally, data credibility, while somewhat subjective, helps eliminate confirmation bias by seeking independent source validation.

Data credibility ratings measure the levels of corroboration by other sources. When examining source ratings, the credibility is classified in order of decreasing credibility, with 1 being confirmed by independent sources:

Table 1.5 – Data credibility ratings

Data credibility ratings help a CTI organization judge the credibility of the data they are ingesting. While data credibility ratings play a crucial role in CTI, fusing the data credibility rating with source ratings makes for a great combination to assess data and intelligence accurateness, reliability, and trustworthiness.

Putting it together

In principle, it should be easy to apply Admiralty codes to threat intelligence, but in practice, it's more difficult. The question that often arises is, ultimately, what data and intelligence can we trust?

While that answer will vary, one method to consider employing is from a paper titled The Admiralty Code: A Cognitive Tool for Self-Directed Learning, written by James M. Hanson at the University of New South Wales (2015; https://www.ijlter.org/index.php/ijlter/article/download/494/234).

Using Table 1.5, it's easy to start applying source and credibility ratings to collected CTI:

Table 1.6 – The Admiralty code for evaluating data credibility

Using the preceding table as an example in which to apply to threat intelligence, an information security industry threat intelligence blog would be considered B1, which is usually reliable and confirmed and can, thus, be considered credible.

A second example would be intelligence from a little-known independent researcher on their personal blog with no independent confirmations. This intelligence could be rated F3, or the source cannot be judged, and the credibility of it would be possibly true, requiring additional investigation.

Employing Admiralty ratings in conjunction with intelligence life cycles in a CTI program is a generally accepted mechanism to enable a CTI program. Let's move on to threat intelligence life cycles next.

Within the field of CTI, there are several intelligence life cycles that can be considered for implementation. In many cases, the most widely used models are the threat intelligence life cycle and the F3EAD cycle. Each model provides its own distinct benefit, and the application of each model depends on the organization's needs. However, implementing one of these models is paramount, as it provides consistent, actionable, reliable, and high-quality threat intelligence.

The threat intelligence life cycle

The threat intelligence life cycle is a process and concept that was first developed by the United States Central Intelligence Agency (CIA). Intelligence is the product of a process that includes collecting data, analyzing it, adding context, and finally, delivering that intelligence as a product of some sort. Following this life cycle will give your organization a structured, repeatable way of delivering consistently accurate and timely intelligence. The threat intelligence life cycle is a five-step process, which is meant to be followed in order, starting with planning and direction:

1. Planning and direction
2. Collection
3. Analysis
4. Production
5. Dissemination and feedback

Let's examine the threat intelligence life cycle in greater detail:

Figure 1.4 – The threat intelligence life cycle

When analyzing the threat intelligence life cycle, it's best to look at each stage individually to better understand how the stage fits into the overall threat intelligence life cycle. So, let's examine each stage in closer detail.

Planning and direction

Generally speaking, the first phase of the threat intelligence life cycle begins with planning and setting the direction for what intelligence will be collected and analyzed, as well as for what purpose. Objectives and direction are derived based on Prioritized Intelligence Requirements (PIRs), Prioritized Collection Requirements (PCRs), and Essential Elements of Information (EEIs).

Collection

In response to the PIRs, PCRs, and EEIs, data collection can begin. Data can be collected from several sources, ranging from humans to open source and public locations, all the way to messaging apps such as Telegram. Often, this data is collected both manually, by an analyst, and en masse, via automated means. Data processing takes place after the data is gathered; it should be stored, organized, and normalized in such a way that makes the data easy to analyze. Since the collection phase typically ends up generating a lot of data, the processing stage includes the systematic way to store intelligence in a centralized location, such as a Threat Intelligence Platform (TIP).

Analysis and production

After the data has been centralized in a standardized way, we begin the process of analyzing and making the data into intelligence that is deliverable in some format. For example, the analysis could include deduplication, Admiralty scoring, pivots, and enrichment. Production could include turning the intelligence into some sort of deliverable format, such as a report for higher executives.

Dissemination and feedback

Finally, after the intelligence has been analyzed and produced, it should be disseminated with feedback sought. Additionally, after a thorough review of the intelligence, decision-makers will likely take actions based on the intelligence. The entire process is then reviewed, and feedback is sought from internal and external key stakeholders and consumers of the intelligence.

Typically, using the threat intelligence life cycle in your organization is a strategic decision, which when used in unison with the second, more tactical life cycle, F3EAD, can be a great complement to adopt. Let's examine the F3EAD life cycle in greater detail.

F3EAD life cycle

The F3EAD cycle is an alternative intelligence life cycle that can be considered for application within a CTI organization. While this life cycle is typically used in militaries worldwide involved in kinetic operations, the F3EAD life cycle can just as easily apply to CTI. F3EAD is more tactical in its approach, as opposed to the more strategic threat intelligence life cycle, which can be viewed in six individual stages:

1. Find
2. Fix
3. Finish
4. Exploit
5. Analyze
6. Disseminate

When used in unison with the threat intelligence life cycle, both operational and strategic objectives can be more holistically accomplished:

Figure 1.5 – The F3EAD life cycle

Now, let's examine Figure 1.5 in detail.

Find

The find stage is the who, what, when, why, and where of CTI. In this stage, a tactical target of intelligence is defined, located, and collected. As an example, an incident responder would find suspicious information across several endpoints.

Fix

The fix phase effectively transforms the data and intelligence gained from the find phase into evidence that can be used as a basis for action within the next stage. An example of activity in the fix stage includes an incident responder correlating multiple IOCs across a cluster of infected endpoints within the enterprise.

Finish

The finish stage is the action phase. In this stage, an action is taken based on the first two stages, find and fix. Let's use the preceding example: after the incident responder isolates the suspicious endpoints that were grouped together, they are taken offline and wiped.

Exploit

The exploit stage deconstructs the intelligence from the first three phases and develops after-actions and next steps. An example of this stage includes a malware reverser that statically reverses the engineering samples identified on the infected endpoint by the incident responder. The malware reverser can then assist in deploying organization-wide mitigation methods.

Analyze

The analyze stage is the fusion stage. It includes folding the intelligence that has been identified into the broader web and context of intelligence. An example of this would be the aforementioned reverse engineer entering malware intelligence and data from reversing efforts into a TIP.

Disseminate

As the result of the previous stage, the results are disseminated to both tactical consumers (for example, SOC) and strategic consumers (for example, CISO). For example, this could include the malware reverse engineer passing the isolated malware activity to the SOC for further blocking across the organization.

When the threat intelligence life cycle and F3EAD are used in unison, like two large cogs, the enterprise can truly benefit from each unique approach. One way of visualizing these cycles working together includes looking at both cycles as cogs in a larger threat intelligence cycle. The interfaces between the threat intelligence life cycle and F3EAD are at the collection and analysis phases and F3EAD's find and analyze phases.

While there are many intelligence life cycles that could be implemented inside a CTI function, and there's no one-size-fits-all implementation, we've shared two prominent models that are easily adaptable to CTI. In the next section, we're going to examine a very important implementation consideration: the maturity and hunting models.

In the context of CTI, there are many maturity and hunting models for organizations to consider. In particular, there are three maturity models that are widely leveraged that will be discussed in this chapter. Each model approaches different core problems using the Threat Intelligence Maturity Model (TIMM) by looking at the organization's overall intelligence maturity relative to a CTI program's adoption. Then, there's the threat Hunting Maturity Model (HMM), which addresses and defines an organization's hunting maturity rating. Finally, there's the detection maturity model, which is used to address an enterprise's ability to detect malicious behavior and will help an organization rate its attack detection capabilities and relative maturity.

While not all organizations have the relative capabilities to hunt through their data or have established CTI practices, it is important to rate and track the maturity of your threat intelligence program, its detection capabilities, and determine the organization's ability to hunt through data, if applicable.

TIMM

First published by ThreatConnect, the TIMM is intended to enable an organization to rate the maturity of a CTI function within an enterprise. Each level is distinct, starting at the least mature, or level 0, and going all the way to the most well-defined CTI program at maturity level 4:

• Maturity level 0: Organization is unsure where to start.
• Maturity level 1: Organization is getting accustomed to threat intelligence.
• Maturity level 2: Organization is expanding threat intelligence capabilities.
• Maturity level 3: Organization has a threat intelligence program in place.
• Maturity level 4: Organization has a well-defined threat intelligence program.

Let's examine each maturity level in detail:

Figure 1.6 – Maturity levels

Maturity level 0 – organization is unsure where to start

Maturity level 0 is defined by an organization that doesn't have any threat intelligence program or experience in threat intelligence. Usually, threat intelligence programs start their life as threat collection programs. Typically, at this level, the organization has no staff that is solely dedicated to CTI, and it is likely that any staff dedicated to threat hunting is not formalized in any fashion.

A great starting point to mature from level 0 includes collecting, storing, and aggregating organizational log data from endpoints, servers, or any connected device. Ideally, aggregation can occur in a systemic and formalized way, such as with a Security Information and Event Management (SIEM) tool.

Maturity level 1 – organization is getting accustomed to threat intelligence

Maturity level 1 is when the organization starts becoming accustomed to threat intelligence. Organizations at this level are typically starting to understand the vast nature of the threat landscape. Organizations have basic logging, with logs often being sent to a SIEM tool. Often, analysts suffer alert fatigue due to the lack of resourcing, the lack of alert tuning, event overloading, or a combination of all of those factors.

Analysts operating at level 1 will typically block and alert based on triggered rule alerts from a system such as an Intrusion Detection System (IDS), sometimes enabling analysts to perform rudimentary hunting. Analysts at level 1 usually leverage a centralized SIEM. In level 1, analysts are typically trying to tune alerts to make analysis more easily accessible. From a human capital perspective, organizations at level 1 will sometimes have limited cybersecurity staff performing threat hunting and intelligence.

While an organization rated as level 1 is still maturing and is reactionary in its approach, a great starting point to mature from level 1 to level 2 includes automating and tuning alerts in a SIEM or similar environment on top of considering an additional headcount that's necessary for scaling a threat hunting organization.

Maturity level 2 – organization is expanding threat intelligence capabilities

Organizations finding themselves at maturity level 2 will find that they are maturing in their CTI capabilities. Most often, level 2 is where you will see organizations draw contextual conclusions based on the intelligence they're generating. Typically, organizations operating at level 2 are collaborating to build processes that can find even the most basic indicator's role in the vast landscape of a criminal cyber attack, for example. To facilitate this level of automation, CTI teams use scripts or a TIP.

Teams operating at level 2 will often find themselves ingesting data feeds that are both internal and external from a litany of threat intelligence providers and data. Teams at level 2 will often start the shift from a reactive approach (for example, blocking indicators on a firewall from an active incident) to a proactive approach (for example, proactively blocking indicators from a high-fidelity enriched feed from a threat intelligence provider). In many organizations, there might be one or two full-time analysts dedicated to a CTI function.

Organizations looking to mature from level 2 to level 3 should be focusing on security automation. Security orchestration should also be a focus area during the maturation process within level 2. Both automation and orchestration can be done in a combination of ways, including analysts creating custom scripts and tools to help automate their key workflows. One primary key to mature to level 3 includes the ability of the CTI team to create their own intelligence.

Maturity level 3 – organization has a threat intelligence program in place

Maturity level 3 is a level that many organizations won't reach, and that's perfectly fine. Not all organizations will have the same level of funding and resourcing available to achieve level 3. Maturity level 3 is defined by a team of security analysts or threat intelligence analysts with semi-automated workflows that are proactively identifying threat activity possibilities. It is common for this team to have incident response and forensics functionality in addition to CTI capabilities.

Processes and procedures have been thoroughly developed in level 3, and analysts working in the CTI function are typically tracking malware families, TAGs, and campaigns. A TIP is a commonplace finding at organizations at maturity level 3, which gives analysts the capability to store and analyze intelligence over a long period of time. Security orchestration might be in place for level 3, but it is likely not fully integrated into end-to-end security operations.

Workflows designed at level 3 should allow full intelligence integration into a SOC, detection engineering, incident response, and forensics functions. This enables these business functions to make proactive and reactive decisions based on intelligence provided by the CTI team. Analysts should focus on adding context to indicators identified as opposed to merely focusing on individual indicators of maliciousness. This, in turn, is the process of a level 3 maturity team creating their own intelligence versus merely consuming others' intelligence. Analysts should find themselves asking questions, such as what additional actions are related to this indicator?

Organizations that are maturing from level 3 to level 4 should focus on integrating orchestration, incident response, and intelligence enrichment into all security operations. Businesses that have reached maturity level 4 should also focus on deriving strategic value from the threat intelligence they're generating versus just tactical intelligence generation.

Maturity level 4 – organization has a well-defined threat intelligence program

Maturity level 4 is a step that many organizations strive to achieve, but few actually do. Due to a combination of funding, staffing, and inexperience, many organizations struggle to reach level 4 maturity. Organizations at level 4 maturity have stable threat intelligence programs with well-defined, formalized processes and procedures with automated and semi-automated workflows that produce actionable intelligence and ensure an appropriate incident response. Organizations operating within level 4 often have larger organizational functions, with mature procedures to provide intelligence to a litany of internal service owners, such as the organizational incident response function.

Organizations in level 4 will continue using the TIP mentioned in previous levels, with CTI teams beginning to build a security analytics platform architecture that allows your analysts and developers to build and run their own tools and scripts tailored to the unique organizational requirements. Teams operating at level 4 utilize automation as much as possible, such as leveraging the API feeds of a targeted attacker activity that's automatically ingested into a TIP. The CTI analyst can vet the intelligence and pass it to security operations for blocking.

A primary differentiator in level 4 is the amount of organizational buy-in for CTI functions. CTI functions at level 4 enable business decisions at the highest levels, including both strategic decisions and tactical decisions.

Now that we've covered the TIMM, let's examine an additional model to consider for implementation: the threat HMM.

The threat HMM

Organizations are quickly starting to learn the importance and benefit of threat hunting. The best foundation for beginning threat hunting is to follow a standard model that not only measures maturity but also ensures a systematic process is being followed by analysts themselves. Before we can discuss the concepts related to the threat HMM, first, we need to approach the question of what is threat hunting?

Threat hunting can be best described as the process of proactively and systematically hunting through organizational logs to isolate and understand threat activity that evades an enterprise's compensating security controls. The tools and techniques that threat hunters employ are often varied, with no single tool being the silver bullet. The best tool or technique almost always depends on the threat the analyst is actively hunting.

It is important to note that hunting is most often done in a manual, semi-automated, or fully automated fashion, with the distinct goal of enabling detection and response capabilities proactively by turning intelligence into a detection signature.

The threat HMM was developed by David Bianco and describes five key levels of organizational hunting capability. The HMM ranges its levels of capability from HMM0 (the least capable) to HMM4 (the most capable):

• HMM0: Initial
• HMM1: Minimal
• HMM2: Procedural
• HMM3: Innovative
• HMM4: Leading

Let's examine each HMM level.

HMM0 – initial

The first level is HMM0, which can best be described as an organization that relies primarily on automated alerts from tools such as IDS or SIEM to detect malicious activity across the organization. Typically, organizations in HMM0 are not capable of hunting through their enterprises proactively. Feeds may or may not be leveraged in HMM0, and they are typically automatically ingested into monitoring systems, with little to no enrichment applied. The human effort in HMM0 would primarily be to resolve alerts generated from detection tools.

Data sourcing in HMM0 is usually non-existent or limited, meaning that, typically, organizations do not collect much in terms of data or logs from their enterprise systems, severely limiting their proactive hunting capabilities.

HMM1 – minimal

An organization operating in HMM1 still primarily relies upon automated alerting to drive its detection and response capabilities and processes. Organizations in HMM1 are primarily differentiated by their sources of collection. In HMM0, we learned that organizations had limited internal data sources (for example, endpoint logs), with no structured way of looking through those logs. HMM1 organizations find themselves collecting, at the very least, a few types of data from across the enterprise into a central collection point, such as a SIEM.

Analysts in HMM1 are able to extract key indicators from alerts and reports and search historical data to find any recent threat activity. Because of this search capability and limited log collection, HMM1 is the first level where true threat hunting happens despite its limited nature.

HMM2 – procedural

Organizations in HMM2 find themselves with the capability to follow procedures and processes to perform basic hunting across enterprise datasets (for example, endpoint logs). Organizations in HMM2 often collect significantly more data from across the enterprise, such as firewall logs, endpoint logs, and network infrastructure logs.

It is likely that organizations in HMM2 won't have the maturity to define new workflows or processes for themselves, but they are capable of hunting both historically and, in some cases, proactively.

HMM2 is typically the most common level witnessed among organizations that employ active programs.

HMM3 – innovative

Many hunting procedures found throughout enterprises focus on the analysis techniques of clustering similar behavior (for example, detecting malware by gathering execution details such as Windows Registry modifications and clustering activities identified elsewhere across the enterprise). Enterprises in HMM3 find themselves not only proactively hunting through a litany of internal log data sources, but they are also performing a grouping and clustering of activity. This clustering or grouping of activity involves identifying similar clusters of threat activity to proactively block, monitor, or further assess. Additionally, organizations operating in HMM3 often have highly skilled threat hunters who are adept at identifying nefarious activity across information systems or networks.

Typically, analysts in HMM3 leverage grouping and clustering to identify new threat activities that are bypassing traditional security controls. Analysts performing in HMM3 can identify nefarious activity while sorting through a needle in a haystack. Traditionally, automated alerts are highly tuned, with very little noise being produced.

As the number of hunting workflows and processes develops and increases, scalability issues that might pop up will be solved in HMM4.

HMM4 – leading

Enterprises in HMM4 are leading the way in terms of defining procedures that organizations in HMM0–HMM3 generally follow. Organizations in HMM4 are advanced in terms of log collection, alert tuning, and the grouping/clustering of malicious activity. Organizations in HMM4 have well-defined workflows for detection and response purposes.

Automation is heavily employed in HMM4, clearly differentiating it from HMM3. Organizations in HMM4 will convert manual hunting methods (such as pulling WHOIS information for a domain being used as part of C2 infrastructure) into automated methods (such as automatically enriching domain intelligence with WHOIS information). This automation saves valuable analyst time and provides the opportunity for analysts to define new workflows to identify threat activity throughout the enterprise.

The detection maturity model

Ryan Stillions published the Detection Maturity Level (DML) model in 2014, but it is still useful today to measure organizational maturity. At its core, DML is a detection model intended to act as an assessment methodology to determine an organization's effectiveness of detecting threat activity across information systems and networks. DML is used to describe an organization's maturity regarding its ability to consume and act upon given CTI versus assessing an organizations' maturity or detection capabilities.

It's important to note there is a distinction between detection and prevention. As its name implies, the detection maturity model deals directly with detection versus prevention.

The DML consists of nine maturity levels, ranging from eight to zero:

• DML-8: Goals
• DML-7: Strategy
• DML-6: Tactics
• DML-5: Techniques
• DML-4: Procedures
• DML-3: Tools
• DML-2: Host and network artifacts
• DML-1: Atomic indicators
• DML-0: None or unknown

The lowest of these levels is the most technical with the highest being the most technically abstract, disregarding level zero, of course.

Let's examine the detection maturity model in greater detail.

DML-8 – goals

Being the most technically abstract level, determining a threat actor's goals and motivations is often difficult, if not impossible, in some circumstances. The threat actor could be part of a larger organization that receives its goals from a source higher up in the operation. Additionally, the goals might not even be shared with the individual that has a hands-on keyboard. If the goals are criminal in nature, it is often hard to determine the motivation of the attacker.

In some cases, goals are easy to determine, such as ransomware, which, typically, has a very clear motivation and goal. Many times, determining a goal is merely guessing at what the attacker's true goals were based on the behavior and data observations of lower DMLs (for example, stolen data, targeted victims, and more).

DML-8 is, typically, what C-level executives are most often concerned with, with who did this, and why? being an extremely common question when called into a board room.

DML-7 – strategy

DML-7 is a non-technical level that describes the planned attack. Usually, there are several ways an attacker can achieve its objectives, and the strategy determines which approach the threat actor should follow. Threat actor strategies vary based on goals and intent, such as a shorter-run criminal attack. Determining a threat actor's strategy is often partially speculative in nature, with observations drawn from behavioral and data observations over a period of time. A good example of this type of observational information being built over time includes the threat actor known as Sofacy. Sofacy has been tracked for years throughout the security industry, with new and unique attacks and new tool development occurring routinely. Watching this actor evolve over time can help inform an analyst of the attacker's intent, but without evidence, there is a degree of estimation.

It is important to note that both DML-7 and DML-8 are often hypothetical in nature. For this reason, they are not easily detectable via conventional compensating security controls.

DML-6 – tactics

In order to succeed in DML-6, an organization's analysts should be able to reliably detect a tactic being used regardless of the technique or procedure used by the threat actor. Typically, determining a tactic is a diverse process, done over time, most akin to profiling an attacker. A good example of this includes the activities identified in Gorgon Group, which were first identified by Palo Alto Networks. This blog details the tactical details of a cybercriminal and nation-state espionage actor that played out over a long period of time. Detailing the actor's TTPs over time gives explicit details about operational cadence, TTPs, capabilities, and in some cases, motivation.

Tactics form the first technical level of the DML. In most cases, tactics are not detected by a single IOC or single detection alert or signature. Tactics are typically identified by skilled analysts, rather than technical correlation.

DML-5 – techniques

Traditionally speaking, being able to detect an adversary's techniques is superior to determining their procedures. Techniques differ from procedures in that techniques are usually correlated to the individual versus correlation to a group.

Many threat actors aren't aware that when they perform attacks, they leave behind digital breadcrumbs helping analysts determine the specific techniques employed. DML-5 is primarily concerned with determining the techniques of an individual actor.

DML-4 – procedures

The process of determining actor procedures makes it effective at detecting adversary activity throughout an enterprise. In its simplest form, determining procedures isolates the threat actor activity that appears to be performed methodically two or more times during a specific time period that is deemed accurate by the organization.

Many of the procedures identified at this stage help an analyst determine broad behavior patterns, such as identifying procedures that would include a threat actor systemically connecting to victim systems and dumping credentials for lateral movement. As such, detection and alerting on procedures are typically broader in scope.

DML-3 – tools

Determining the specific tools that a threat actor employs is often not difficult and can provide a wealth of intelligence to a CTI analyst. Being able to detect adversary tools means you can reliably detect tool activity and the variations and functionality changes that the tool might experience.

Detecting tool functionality can be broken down into two categories: transfer and presence and the functionality of the tool. Both will be examined in detail:

• Transfer and presence: This is the ability to identify the transfer and presence of the tool on either a server/endpoint or across the network. Additionally, this identifies active usage in the environment.
• Functionality: This is the ability to identify the functionality of the tool via analysis techniques, such as static reverse engineering.

Detections are typically built from analysis originated by the transfer and presence and the functionality of the tools themselves.

DML-2 – host and network artifacts

Many organizations spend a lot of time focusing on detecting host and network-based artifacts. Being perhaps the easiest of all to detect, host and network indicators are simply artifacts that are observed before and after an attack. If those tools or malware change, for example, even in the slightest sense, the detection methodology and strategy would shift.

While technical in nature, DML-2 is considered rather rudimentary when compared with more holistic detection methods, such as those found in DML-3, DML-4, and DML-5. Attribution poses an additional challenge when looking at detecting host and network artifacts. CTI analysts should never attribute tools to a specific threat actor, group, or country based on just host and network artifacts alone. Many tools are spread across threat actors and are shared, making it extremely difficult, if not impossible, to attribute a tool to a TAG.

DML-1 – atomic indicators

Atomic indicators are indicators that cannot be broken down into smaller parts and, due to that, can't retain their meaning in the context of the intrusion activity. DML-1 is considered one of the most rudimentary of all detection methodologies. Some examples of this include IP addresses, domains, and URLs. Detection at this level usually comes in the form of malware hashes, domains, URLs, IP addresses, and other technical indicators specifically related to attacker activity.

While technical in nature, atomic indicators are rather weak from a detection benefit perspective. Atomic indicators are temporal in nature; they are temporary and prone to change. Additionally, atomic indicators lack additional context and often provide little intelligence value. Detection and response methods employing atomic indicators are usually playing whack-a-mole, by blocking specific indicators that are constantly changing.

DML-0 – none or unknown

DML-0 is reserved for organizations that want but do not have detection capability, or organizations that aren't mature enough to recognize the need for a CTI function. Organizations operating in DML-0 often don't have robust logging solutions to facilitate internal threat hunting. Organizations in DML-0 often have cybersecurity staff, but they are unlikely to be devoted to threat hunting.

In the Threat intelligence maturity, detection, and hunting models section, we've examined three unique models that can be used for organizational maturity in different functional areas within the CTI field. Specifically, we've examined the threat intelligence maturity, detection, and hunting models that should be used to determine your own organization's maturity. The models discussed will help your organization assess its overall threat intelligence maturity, as well as the concepts of hunting and detection of threat activity. Leveraging one of these maturity models will help organizations adapt and make meaningful decisions to mature the CTI function.

In the next section of this chapter, we'll coalesce all the information found throughout the chapter to determine what you can actually do with the intelligence once it's been collected and enriched.

Every organization has different levels of stakeholders that exist within each of its own IT security groups. This includes the frontline defenders working in the SOC up to the CEO of an organization. CTI informs the entire organization in this chain, and as such, the context it provides allows for tactical and strategic decision-making at every level along the way. Further, the context provided by the CTI allows stakeholders to identify and prioritize which of the pieces of intelligence should be utilized and actioned first.

From the start, it's a no-brainer to utilize technical CTI to improve the effectiveness of internal security architectures to assist in blocking attacks or access to malicious C2, to identify vulnerable systems and patch software to reduce the security footprint of an infrastructure, and to identify possible security alerts and triage these events from the SOC and IT support groups.

The tactical CTI provided can assist with signature generation within your enterprise by focusing on blocking the TTPs utilized by the threat actors. This can be through the utilization of threat frameworks such as MITRE's ATT&CK framework (https://attack.mitre.org/), which we will discuss in greater detail in a later chapter, but it can be also utilized by operational groups such as incident responders, forensics, and security researchers to assist them in identifying and analyzing much larger and more complex attacks.

From the identification of any key event, these business organizations will look toward the CTI to assist in identifying numerous things, including the following:

• What tactics are being utilized by the threat actors targeting the organization?
• How does the attack work?
• Are there any additional attack characteristics elsewhere across the organization?
• What do we need to do to remediate immediately or at least stop an ongoing attack?
• What internal assets are they targeting?

Tactical CTI can accelerate the response to key events such as that referenced previously by providing context around security data and information. Additionally, security practitioners can continue to hunt and pivot off of indicators and information collected during the response process to enrich the operational investigation along the way. Further tactical CTI can assist with remediation. The knowledge of the threat actor's TTPs can assist in the identification of probable systems that have been compromised and help with the identification of IOC discovery during incident response and forensics.

Finally, the operational and strategic benefits could allow executives of an organization to make security posture improvement decisions for the corporation before they become a victim of an attack, allow for appropriate strategic investment into security, and most importantly, be the organizational cheerleader for security within the organization, putting the importance on security at every level of employee. Actions such as these will ensure the immediate security posture improvement of an organization, reduce the footprint of corporate risk, and keep the reputation of your corporate brand in good standing.

We've just gone through and thrown everything but the kitchen sink at you trying to illustrate the motivations behind starting and building a threat intelligence program! Some of the key takeaways from this chapter should be what CTI is, what its benefits are, and how it can be used by every level of employee to prioritize and improve the security posture of an organization. Further, we tried to frame what good intelligence is by utilizing several known frameworks for judging the credibility and reliability of your gathered source information. We also walked through the threat intelligence life cycle that is used to hunt, pivot, and enrich information to create CTI. Finally, we walked you through a model in which you can rate the maturity of your organization's CTI capability.

In the next chapter, we will start ramping up the technicality by introducing core concepts such as defining threat actors and campaigns, as well as looking at tools and vulnerabilities that threat actors often leverage. Further, we will clearly define threat actor types and discuss the attribution of threat actors in depth. Finally, we will introduce standardized naming conventions for identifying campaigns and TAGs and discuss the advantages and disadvantages of attribution overall.