Using threat intelligence

Cybersecurity programs can make use of CTI in several ways. Here are some examples (this list is not exhaustive):

• Security Operations Centers (SOCs) are only as good as the CTI they have
• Inform Cybersecurity Incident Response Teams’ (CIRT) investigations
• Inform threat hunting, Red, Blue, and Purple teams’ efforts
• Profiling attackers in order to be better prepared for them
• Inform executive protection programs designed to protect executives and their families
• Inform risk management

Let’s dig into that last example a bit more, inform risk management. CTI can inform the risks that organizations pay attention to. Recall that risk is composed of probability and impact. CTI can help quantify both the probability side and the impact side of risk calculations. For example, let’s say you are a CISO and the business leaders you support are very concerned about ransomware because they keep seeing news stories about attacks. CTI can help provide some idea of the probability of encountering ransomware. I’ll discuss ransomware in detail in Chapter 4, The Evolution of Malware, but it turns out that ransomware (the category of malware) is typically one of the least prevalent categories of malware. There are some logical reasons why this is the case that I’ll cover in Chapter 4, The Evolution of Malware. However, if you were to stack-rank risks by priority based on probability alone, ransomware would likely show up near the bottom of the list. But once we quantify the potential impact of ransomware to reflect that encountering it could be an extinction event for your business, it likely bumps it way up in the ranking on the list of risks.

Another use for CTI is to help security teams mitigate risks by providing details about specific threats and how they operate. Understanding the Tactics, Techniques, and Procedures (TTPs) that attackers employ can provide some concrete ideas on how they can be mitigated. NIST defines TTPs as,

The behavior of an actor. A tactic is the highest-level description of this behavior, while techniques give a more detailed description of behavior in the context of a tactic, and procedures an even lower-level, highly detailed description in the context of a technique.” (Badger et al 2016)

A tactic is the reason the attacker performs a particular action. Why do they decide to take a specific action? It was a tactical goal. For example, once an attacker is inside their victim’s network, they typically need to move laterally to explore the network and find sensitive data. The tactic in this example is lateral movement. Other examples of tactics include reconnaissance, persistence, and exfiltration.

Techniques are how the attacker tries to accomplish the tactic – the specific actions they take. For example, the attacker needed to move laterally (the tactic) on the victim’s network, so they used Pass the Hash and stolen web authentication cookies (these are techniques) to do this.

Using this combination of tactics and techniques enables security teams to take a structured approach to planning for attacks. Knowing the tactics and techniques that attackers use allows defenders to put people, processes, and technologies in place that will detect or mitigate the techniques when they are employed. In our example where Pass the Hash was employed, we could plan to mitigate this technique using some guidance from Microsoft or procuring a security product designed to detect it.

Using TTPs this way might seem like a daunting task because there must be many combinations and permutations of attacker tactics and techniques. A great resource to help security teams is the MITRE ATT&CK^® knowledge base (found at https://attack.mitre.org/). This knowledge base contains tactics and techniques that have been seen in use during attacks. It maps techniques to tactics and provides ways that each technique can potentially be mitigated and detected. The popularity of this approach with security teams has skyrocketed in recent years.

Many security teams also use Indicators of Compromise (IOCs) to help determine if their enterprise IT environments have been compromised. Where TTPs can help protect, detect, and respond to attacks, IOCs can help post-compromise to try to determine when and how the initial compromise happened, and what the attackers did with their illicit access afterward. IOCs are described this way in NIST Special Publication 800-53 Revision 5:

Indicators of compromise (IOC) are forensic artifacts from intrusions that are identified on organizational systems at the host or network level. IOCs provide valuable information on systems that have been compromised. IOCs can include the creation of registry key values. IOCs for network traffic include Universal Resource Locator or protocol elements that indicate malicious code command and control servers. The rapid distribution and adoption of IOCs can improve information security by reducing the time that systems and organizations are vulnerable to the same exploit or attack. Threat indicators, signatures, tactics, techniques, procedures, and other indicators of compromise may be available via government and non-government cooperatives, including the Forum of Incident Response and Security Teams, the United States Computer Emergency Readiness Team, the Defense Industrial Base Cybersecurity Information Sharing Program, and the CERT Coordination Center.” (NIST Special Publication 800-53 Revision 5, September 2020).

Examples of IOCs include unusual network traffic (destination, origin, or volume), network traffic to or from known malicious domain names or IP addresses, unusual volumes of authentication failures, the presence of specific tools, files, or registry entries, recently added unrecognized accounts, and many others. Incident response and forensics teams can use IOCs to help them identify compromised systems. To do this, they typically need MD5, SHA1, or SHA256 hashes for files, scripts, and tools that attackers leave behind. File hashes can help identify the presence of files that were potentially used during attacks among the mountains of legitimate files on systems.

IP addresses for command-and-control servers, data exfiltration locations, and other attacker-controlled resources can also be helpful to investigators as they comb through network flow data logs on firewalls, proxy servers, and other devices on a network.

Figure 2.1: An example of IOCs with fictional filenames, hashes, and IP addresses

I learned so much about the tricks that attackers like to use when I worked on Microsoft’s customer-facing Incident Response team. We built tools to collect system data on live-running Windows systems that were suspected of being compromised. We’d compare the data on system configurations and running states with known good and known bad datasets – essentially looking for IOCs. This was as much art as it was science because attackers were using all sorts of creative tricks to try to avoid detection, stay persistent, and perform data exfil.

Some memorable tricks include attackers using IP addresses in Base-8 instead of Base-10 format to bypass proxy server rules, taking advantage of bugs in browsers and proxy servers when domain names in Cyrillic were used, running processes using the same name as well-known legitimate Windows system processes, but from slightly different directories to avoid detection, and so many more. Fun stuff!

Security teams can leverage TTPs and IOCs with a variety of security tools, products, and services. Examples include, Security Information and Event Management (SIEM) systems, behavioral analytics tools, data visualization tools, email filtering services, web browsing filtering services, endpoint protection products, Extended Detection and Response (XDR) products, Security Orchestration, Automation, and Response (SOAR) products, and many others. There are a vast number of ways to leverage CTI to protect, detect, and respond to modern threats.

Different roles on security teams can leverage CTI in slightly different ways. For example, as I mentioned earlier, Cyber Incident Response Teams (CIRT) will use IOCs when performing intrusion investigations. Meanwhile, IT analysts are using CTI to ensure protection and detection capabilities are optimized. CTI has the potential to inform the efforts of many different roles and stakeholders.

The key to using threat intelligence

I’ve provided a few examples of some of the ways that security teams use CTI. Whatever ways security teams choose to leverage CTI, it’s important to recognize that although CTI is a product offered by many vendors and organizations, it’s also a process – a process that is used to collect data, process that data, analyze the processed data, and then share the results with those stakeholders that need them. This typically takes time, budget, and resources to accomplish. I haven’t met a security team yet that has unlimited resources and does not need to make trade-offs. The combination of so many potential sources of CTI, so many uses for it, and limited resources, can lead to security teams drowning in CTI. In many cases, the CTI wouldn’t be helpful to them even if they could consume it.

The most common reason I have seen for this is that teams didn’t take the time to develop a set of requirements for their CTI program. In this context, “requirements” are statements about the specific problems the CTI program is trying to solve. These requirements help the CTI program rationalize the CTI they use by tying the specific CTI collected and analyzed to the specific needs of the program’s stakeholders. If some CTI source has some interesting data, but the data it provides doesn’t help fulfill a requirement defined by a program stakeholder, then that source likely should not be leveraged.

This approach helps the CTI program optimize the resources it has and prevents it from drowning in CTI.

Figure 2.2: An example of CTI requirements

I’ve seen a few different approaches to documenting requirements. Figure 2.2 provides an example. If your CTI program doesn’t have a set of documented requirements, I recommend working with the program’s stakeholders to develop them, as they are the key to an optimized approach.

It’s also worth mentioning that Artificial Intelligence (AI) and machine learning capabilities have matured a lot over the last several years. Services that leverage these capabilities can churn through massive amounts of CTI very quickly compared to human analysts. This can help your organization manage large volumes of CTI on an ongoing basis. Of course, like many aspects of computer science and cybersecurity, the value derived here is a function of the effort that is put into it.