Unless you have planned and have set duties and responsibilities before an incident occurs, you may find yourself in despair trying to do everything at once. There are too many steps to follow, and it is inevitable to accidentally miss a step in the havoc of an on-going incident.
In this article, I wanted to create the foundation of a playbook without including the details on how to accomplish specific tasks. There are many ways to achieve the tasks for completing each step.
What is the purpose of this playbook?
A playbook can help the Cyber Threat Intelligence (CTI) analyst organize the tasks and prioritize them by following a set methodology. In this article, I would like to go over the intrusion infection playbook and have, at a high-level, the tasks that a threat intelligence analyst should usually follow to assist with the investigation. Again, this is a high-level playbook that emphasizes the fundamental steps that the threat intelligence analyst should take without capturing the various sub-steps. Explaining how to complete each task is outside of the scope of this article.
This article assumes that you are comfortable with the general terminology used within cyber threat intelligence. This article is for those who are either:
- Already working as a threat intelligence analyst.
- Those who are familiar with the concepts of threat intelligence and want to understand the various tasks of intrusion analysis better.
If you are new to the field, you can still learn from this article by googling the terms and concepts you are not familiar with to understand better. Some examples are using in each step for guidance.
Below you can see the mindmap that this was based on. You can grab a high-quality image from my GitHub repo here:
What is the difference between IR and Threat Intelligence?
When it comes to tactical threat intelligence, many fail to see the difference between incident response and CTI. This is because both of these critical security functions play a common role in incident response. The incident response team relies on Threat Intelligence to complete specific actions.
An example of this could be for threat intelligence to provide incident responders with information and context related to Tactics, Techniques and Procedures (TTPs) of the adversary. CTI can also give more information regarding the network sector that the attack was identified and any potential impact.
On the other hand, CTI relies on the data that IR is collecting during the investigation. Therefore, IR has an essential role in the collection step of the CTI lifecycle. With this in mind, it is easy for someone to confuse Incident response activities with CTI intrusion analysis. Although every organization may have a different approach to separating those two roles, the main takeaway is this:
Threat intelligence relies on the data collected by the incident response; nonetheless, CTI analysts play a crucial role in the incident response process exploiting the data looking for the malicious activity. CTI is concentrating on patterns(behaviour) and “human fingerprints”(key indicators) to unravel the incident.
Many organizations task incident response teams with threat intelligence activities; however, this delays collecting valuable information and remediation actions. Separating these two roles have a significant benefit on minimizing the Mean Time To Respond (MTTR) and allow the IR team to concentrate on collecting the appropriate data without wasting time in research and contextual information.
STEP 1: GATHER AND ACT UPON THE INFORMATION RELATED TO THE REPORTED INCIDENT:
Validate reported IOCs:
The intrusion analysis starts here. This is the first thing that the CTI analyst should do. This would include validating the lots or claims/alerts that have been reported. This might require initial data to be collected with the help of the IR team.
Example: In case of a phishing investigation where malware was executed on an endpoint, the CTI analyst should confirm that the user received the phishing email and run the payload. To validate this, the CTI team should request the email that the user received and any host-based logs around the timeframe specified by the report/alert.
Investigate collected data:
The next step would be to investigate and enrich the collected data. The aim is to get a good idea of what happened after the payload was executed. Many sources can be used for this purpose; therefore, it is impossible to mention all of them. A large portion of this task can be automated. I include some examples below:
- Investigate: During an incident, it is uncommon that a single data source will be enough to answer the investigation’s leading questions. Often, the CTI analyst will have to pivot between internal and external data sources as one evidence may lead to another.
- Enrich: CTI analysts should check all malicious artifacts against online reputation services. This can save research time and manual analysis. There are also multiple sources provided from the InfoSec community that could aid the investigation.
Example: After the initial malicious payload execution, the malware communicated to an external Command and Control server (C&C) server. Knowing this, the CTI analyst can look into proxy or firewall logs to confirm this activity. Simultaneously, she can initiate an OSINT search and look for more information about the payload and infrastructure she just found to further her findings.
Discover key indicators:
A key indicator is the most important indicator that should be unique across the intrusion. The CTI analyst can use the key indicators to search across the environment for any signs of compromise.
Examples of Key Indicators: A key indicator can be:
- A custom encoded C2 channel.
- Registry or File modifications
- Specific malware strings
Provide Key IOCs/TTPs to the appropriate team:
After enriching the main IOCs and discovering some key indicators within the organization’s environment, the CTI analyst should have a good idea of the network’s compromised systems. This information should be shared with the appropriate teams for further investigation or data collection. The CTI analyst should also communicate the Course of Action (CoA) that the analyst should take against the known indicators.
Example: The incident response team should be aware of all possible compromised systems and gather further logs/data. The security analysts should take a certain CoA to either deny the threat via firewall block or deceive the threat via redirecting it to a honeypot.
Create the timeline of events:
At this point, the CTI analyst should have a good idea of the chain of events that took place and populate them in the form of a timeline. However, it is a good idea that the analyst should take the time and document any major findings during the investigation.
Example: The analyst should always ask this question: “Where am I now regarding the timeline of this intrusion?”. The goal here is to fill in any timeline event gaps before and after the initial report. This will help you answer all the questions related to the intrusion. Some of these questions could be:
- When did the intrusion start?
- What events took place during and up to the initial detection/report?
Determine organizational impact:
Now, the CTI analyst will have enough information to know the impact of this incident. She will be able to determine whether this is an isolated or a widespread incident. The threat intelligence analyst will now have a good idea of the adversary’s objectives and the extent of the inflicted damage.
Example: Some of the questions that the analyst should be able to answer are:
- How widespread is the incident within the organization?
- Was there any loss of information as a result of this incident?
- Are there any critical sectors affected?
- Was there a downtime caused as a result of this incident?
There are lots of other questions that could be relevant depending on the organization.
STEP 2 — RESEARCH AND DOCUMENT THE SPECIFIC THREAT:
After the initial intrusion analysis is complete, it is time to look at all the findings and identify ways to improve the security posture. This is also an opportunity to discover relationships or unique characteristics of the intrusion by comparing it with past incidents. Several frameworks can help during this process. Some of the most well-known frameworks are:
Collect information related to the initial point of entry (if available):
Once the impact is determined, the CTI analyst needs to work backwards in the chain of events and ensure that nothing was missed. Sometimes moving backwards on the intrusion phase, up to the initial entry point, might help uncover other intelligence related to TTPs of the adversary.
Look into internal and external data to uncover patterns:
Maintaining a historical database of past incidents allows the CTI analyst to discover patterns and have a good threat awareness of the environment that is trying to protect. If this is a never seen before the threat, the analyst should attempt to find answers on available open or closed sources. Questions to ask that could help during this step are:
- Have we seen any of the observables in past incidents?
- Can we gather more information about the adversary from OSINT data? (Searching for the key indicators we have observed)
- What are the security gaps that allowed this threat to exploit our network? How can we mitigate them?
- What are the motivations of the adversary?
Document further findings:
If there are further findings from looking into internal and external sources, the CTI analyst should capture all the details. Threat Intelligence Platforms (TIPs) are a good place to store this information. It is important to track any commonalities that are found between intrusion attempts. In the long run, this will allow for a better understanding of the threats that are targeting your organization.
Frameworks such as Mitre ATT&CK and Diamond Model and Analysis of Competing Hypotheses (ACH) techniques can assist with threat clustering and adversary tracking.
Update stakeholders on any advancements:
Once all data are documented and exploited, the CTI analyst must communicate the findings to the stakeholders. This can be done through visual presentations, written reports or one-to-one meetings.
I hope you found this article informative. Any feedback is welcome and please feel free to contribute to this or future playbooks that I will be putting out.
GitHub repository for the playbooks: