The lifecycle management of indicators is an essential element during incident response preparation, as it will influence decisions and actions against attackers. It’s a continuous process of indicators of compromise (IoCs) to guarantee the information you work with is (and remains) valid and useful.

A good lifecycle of indicators will in turn generate other indicators to put through the same cycle. There are some basics that you first have to understand before you can start with this process.

Analyze the Cyber Kill Chain

Security and aerospace company Lockheed Martin developed the Cyber Kill Chain framework in 2011, which describes the different phases of a cyberattack. The seven phases of the kill chain cover all of the stages of a single intrusion that — when completed successfully — lead to a compromise.

Within each of these stages is also an opportunity for defenders to prevent a successful intrusion. Each phase of the kill chain offers additional information you can use to further detect and mitigate an attack. The weaponization phase, for example, can reveal document metadata or the characteristics of the tools that are used by the attackers. The delivery phase, in turn, can tell you which email infrastructure is used or which web infrastructure has been set up for delivering a browser plugin exploit.

The information that results from analyzing these phases will include, among other things, IoCs. These indicators describe your adversaries by providing details about the infrastructure they use, fingerprints of their actions and the tactics, techniques and procedures (TTPs) used to attack their victims.

Read the white paper: IBM X-Force IRIS Cyberattack Preparation and Execution Frameworks

How to Apply the Courses of Action Matrix

The indicators extracted when you analyze the different phases of the Cyber Kill Chain should be put into action to increase your defenses. There are essentially two significant categories of action: passive and active.

This categorization of actions is described in another model from Lockheed Martin: the courses of action matrix. The passive actions of the courses of action matrix have no direct influence on the actions of the attacker. To prepare for active phases, however, you should always apply both passive actions.

The following are passive actions:

• Discover: The discover action is a “historical look at the data.” This action heavily relies on your capability to store logs for a reasonable amount of time and have them accessible for searching. Typically, this type of action is applied against security information and event management (SIEM) or stored network data. The goal is to determine whether you have seen a specific indicator in the past.
• Detect: The other passive action is setting up detection rules of an indicator for future traffic. These actions are most often executed via an intrusion detection system (IDS) or a specific logging rule on your firewall or application. It can also be configured as an alert in a SIEM when a specific condition is triggered.

The active phases in the courses of action matrix vary in the type of impact that they have on the attacker or intrusion. It’s important to note that these actions are mutually exclusive, and only one can be applied at a time.

The following are active actions:

• Deny: The deny action prevents the event from taking place. Common examples include a firewall block or a proxy filter.
• Disrupt: Disruption makes the event fail as it is occurring. Examples include quarantining or memory protection measures.
• Degrade: Degrading will not immediately fail an event, but it will slow down the further actions of the attacker. This tactic allows you to catch up during an incident response process, but you have to consider that the attackers may eventually succeed in achieving their objectives. Throttling bandwidth is one way to degrade an intrusion.
• Deceive: Deception allows you to learn more about the intentions of the attacker by making them think the action was successful. One way to do this is to put a honeypot in place and redirect the traffic, based on an indicator, towards the honeypot.
• Destroy: The destroy action is rarely for “usual” defenders, as this is an offensive action against the attacker. These actions, including physical destructive actions and arresting the attackers, are usually left to law enforcement agencies.

How to Feed Your Threat Intelligence Process

Unfortunately, there’s not a single rule that can tell you what action to apply. The type of action that you choose is partly dependent on the amount of information that you still want to acquire on the attacker or intrusion. Denying an initial event from taking place can stop an attacker at your doorstep, but it might prevent you from extracting additional indicators of previously successful intrusions.

Denying email delivery from specific domains can block malicious attachments, but you wouldn’t know what these attachments actually do. Analyzing the attachments and applying passive actions to newly found indicators can reveal additional intrusions that took place via other non-blocked domains. If you want to acquire more information to feed your threat intelligence process, then it might be more useful to apply a deceive or degrade action.

The actions that you apply will also depend heavily on your capabilities on both a technical and organizational level. Although some actions can reveal further capabilities from an attacker, limited incident response resources may make it more appropriate to apply basic disrupt or deny actions. Your choice also depends on your infrastructure capabilities — if you only have a firewall and no way to redirect traffic to a honeypot, then deny might be your only option.

Similarly, if you do not have capabilities to analyze email attachments in a sandbox, then deceiving the attacker by forwarding email to a quarantine mailbox will not give you much advantage.

Lifecycle Management for Effective Threat Intelligence and Response

The courses of action matrix both depends on and supports indicator lifecycle management to sustain effective threat intelligence and response. The majority of organizations will receive indicators that are reported to them by third parties. Via a threat intelligence sharing platform, for example.

Following a report, you’ll likely go through a seven-step process:

1. Insert the indicator into your own intelligence platform.
2. Evaluate the quality of the indicator: Is it relevant to your organization? How likely is it to cause false positives? Do you have the capabilities to consume the indicator?
3. Apply the “discover” passive action by searching for past events matching the indicator. Typically, this is done using your SIEM solution and going through your logs and network data, searching for events that match the indicator.
4. Apply the “detect” passive action. Update your intrusion detection system (IDS) rule set and proxy logging to trigger an alert when the indicator is observed.
5. Apply both “discover” and “detect” actions to determine whether the indicator has been seen in your organization. If it has, then you’ll have to analyze events related to that hit and search for additional indicators. These indicators will have to go through the same validation process.
6. Weigh the benefits of each active action to determine which is best for your organization, and then see that one through.
7. Share the validated and verified indicators extracted from this process with your threat intelligence community.

Initially, the process of validating and verifying indicators can seem complex and resource-intensive — and it does require some training and practice. Ultimately, it will give you the metrics to detect what capabilities you are missing in your organization. Most importantly, it will guarantee that the indicators you use are valid and actionable.

This can, in turn, preserve your resources by not having to investigate events that turn out to be legitimate or unrelated to intrusions. Use the courses of action matrix together with indicator lifecycle management to measure what capabilities your organization is missing, identify what it should take to better respond to security incidents in the future and fine-tune your approach to monitoring and logging those incidents.

Read the white paper: IBM X-Force IRIS Cyberattack Preparation and Execution Frameworks