Cyber Threat Intelligence is an important part of a comprehensive security program, but it needs to be approached deliberately.
Threat intelligence comes in multiple forms; the two I am going to focus on are Indicators of Compromise (IoCs) and Tactics, Techniques, and Procedures (TTPs). The MITRE ATT&CK Framework, Diamond Model of Intrusion Analysis, and Lockheed Martin Cyber Kill Chain provide a good framework to start with.
When creating a roadmap to follow with your threat intelligence, you need to determine what your current security posture is and what data sources you have available, as well as your plan to handle detections and threat hunting findings based on your threat intelligence.
What is your current security posture
When planning for your Threat Intelligence Program, you need to assess where you are in your Cyber Security and where threat intelligence will bring the greatest return. Some questions to ask are:
1) Do you have a centralized log source or Security Information & Event Management (SIEM) that you are able to use?
2) Do you have log sources for searching or detecting IoCs or TTPs?
3) Do you have the capacity for responding to detected threats?
Creating a plan
Knowing the capabilities that you currently have is the first step in creating a plan for your Threat Intel Program. Threat intelligence is only useful if there are actionable steps that can be taken in response to the threat. Here are a few use cases for using IoCs and TTPs gathered via threat intel:
Indicators of Compromise (IoCs), which usually consist of IPs, URLs, Domains, File Hashes, and other similar set values, are only available after someone or an automation sees a file and determines it to be malicious.
There are a ton of open source threat feeds available to pull IoCs from, but you have to know your environment and capability before you start that process. Knowing your logging sources and what they log is an important first step. There is no reason to add file hashes to an IoC threat list if you have no log source logging file hashes in your environment.
At the same time, ensure that any IoCs you add also involve enough context to be actionable for the responder. If an IP is added to a threat list with no context, how would a responder know how to approach a potential threat match? Include what the threat is, being as exact as possible. With an IP, often threats use hosting IPs, so these can trigger a lot of false positive alerts, so try including what potential domains, ports, or processes the threat that uses that IP will be associated with. That will decrease analyst fatigue and lead to more fruitful threat lists.
IoCs are also extremely helpful to look for when threat hunting. IoCs are often released when they are already out of date, but being able to look over their past may reveal potential intrusions that were missed at the time.
Alerting based on IoCs is usually done by having a threat list is your SIEM solution that runs the threat list against activity seen in the logs. Splunk uses Enterprise Security Threat Intelligence Management to be able to ingest multiple threat intel feeds to run against all data in the CIM Data Models. I also included a few data sources below that can be investigated for your use cases for IoCs.
Open Source Data Sources:
Tactics, Techniques, and Procedures (TTPs) require more work and research to set up as alerting, but they are much more reliable indicators to alert on and hunt for.
TTPs are usually found by Incident Responders who see trends in the techniques that threat actors use in different parts of the attack. The alerts based on the TTPs usually will be based on the actual event logs and activities seen, rather than looking for a static value.
Often the TTPs will be found in CISA/FBI releases or papers released by security vendors with attack details. Alerting or hunting for TTPs can often show false positives that can be tuned out pretty easily with some confirmation of expected activity.
An example of the difference between looking at IoCs vs TTPs can be seen in the recent malware releases targeting Ukraine.
Searching for the IoCs provided would only find matches for the direct IoC values provided in the release, which is important if detected, but those values are easily changed by threat actors and they are possibly already out of date.
A TTP-based detection could look at “HermeticWizard is started using the command line
regsvr32.exe /s /i .” and look for cmd.exe executing a potentially malicious .dll. This same attack vector was mentioned in May of 2017 by Black Hills Info Sec. A potential detection for the TTP could be:
How to handle alerts and make improvements
The most important thing to consider with a Threat Intel Program is to make sure that all intel is actionable. There are different levels that you can consider, but without any action that the responders can take, the intel just becomes noise.
You can add IP IoCs to a firewall block list, or just alert when there is allowed activity to confirm and tune if a false positive. TTPs can be used for threat hunting or creating alerting searches that you can continually refine to reduce the false positives in your environment.
Threat intelligence is a major help to a security program, but it needs to be carefully planned and considered before implementation. Cybersecurity is something that needs to be constantly tuned and updated to stay current with the threats that are out there, and threat intelligence is no different.