You've just observed something unusual: a sudden spike in outbound connections to suspicious domains known for hosting malwares. Concurrently, employees report sluggish system performance and strange pop-up messages on their screens. Additionally, multiple employees report receiving phishing emails with suspicious attachments. Something strange has definitely happened. Is that strange thing a cyber incident ? how do you decide that, and more importantly, what do you need to do in case you decide that it is ? As a SOC analyst, you're in a constant race against time. The sooner you can detect a harmful situation, the faster you can handle it. This is where Incident Response (IR) will play a game-changing role.
In this blog, we will explore the distinct phases of Incident Response, from preparation to post-incident activity. We will cover each step by identifying its purpose and key aspects involved in the process. Along the way, we’ll highlight key questions to ensure a comprehensive understanding of each phase’s significance and how it should be implemented. Whether you are new to Incident Response or looking to refine your approach, this blog will provide valuable insights to help you better manage and respond to cybersecurity incidents with confidence.
Let’s start with the most basic question: What is Incident Response Process?
Incident Response is a process that allows organizations to identify, prioritize, contain and eradicate cyberattacks. According to NIST, the primary steps of the Incident Response Process are as follows:
We'll break down each phase to provide a deeper understanding of its objectives, activities, and outcomes.
As the name indicates, this phase focuses on preparing the organization for a potential cyberattack. It is the crucial step that will directly affect the incident response process and the work for the analysts when dealing with incidents. However, many organizations underestimate and overlook the preparation phase. This may be due to the significant time and resources required to meticulously craft the necessary documentation and processes, especially when compared to its less immediate impact on day-to-day operations.
Now the question is what should we do to ensure that these preparations are implemented correctly? What are the necessary documents to prepare? … Below are the most important actions in this phase.
Before making any decisions or taking action, you have to understand your environment. Without proper knowledge, it's like navigating in the dark without a flashlight. Protecting your infrastructure requires knowing what devices are connected to your network, what applications are being used, who has access to them, and what security measures are in place. By clearly identifying inventory lists, security analysts can focus on protecting them and take actions wisely. This inventory should include at least the following information:
An incident response plan serves as a crucial document for organizations, providing clear guidance on how to methodically investigate and address cybersecurity incidents. Simply, it helps organizations understand what they should do and how, if a cyber security incident occurs. By following the predefined procedures outlined in the plan, organizations can ensure a coordinated and efficient response to incidents, minimizing disruption and mitigating potential damage to their operations and reputation.
I'm sure you're thinking okay thanks for that but what should I be asking or looking for when it comes to creating my plan ? Here are some key notes to consider, both for yourself and your incident response team, during this phase to help prepare this document:
For this point we should understand “Why are Playbooks Important”. As SOC analysts, we may not always know exactly what to do when handling alerts. Playbooks will provide step-by-step guidance, especially to analysts who have just started their careers in the SOC field. Apart from that, it enables the team to perform analysis at certain standards. For instance, checking to see whether there is access to C2 sites/IP addresses and Registry Run keys/Startup Folder for persistence is vital after analyzing malware. A playbook typically includes all incident response phases.
We agree that the more data we have the better even if it’s redundant, right? Of course not! Adopting a “quantity over quality” approach by collecting and managing an overwhelming mountain of data can be resource-intensive and challenging to analyze effectively. Instead, it's essential to focus on collecting relevant and actionable data that aligns with your organization's security objectives. This ensures that the data collected is not only manageable but also provides valuable insights for proactive threat detection and response. Here are some practical steps to follow in order to achieve this:
At the end of this phase, you should always remember “Predicting the exact moment of an incident is impossible… but having awareness and processes to deal with it will save valuable time and resources.”
The most challenging aspect of the incident response process is detecting and assessing cybersecurity incidents. This involves determining whether or not an alert is actually an incident and, if so, evaluating its type, impact, and criticality of the incident , and network systems to ensure an appropriate response. The analysis should provide enough information for the team to prioritize subsequent activities, such as containment. At this stage, we can only say one thing: the game is on.
Key Questions to Address at This Phase:
Understanding the behavior that triggered the alerts is crucial, we must first familiarize ourselves with the specific rules in place. For example, consider an Elastic rule designed to detect a privileged account brute force. If we take a look at the screenshot below, for instance, by thoroughly reading and understanding the query, we can see that this rule looks for repeated failed login attempts within a 10-second window targeting an admin account from the same source address, excluding certain misconfiguration errors. We can also gather valuable insights from the rule description, some url references, MITRE ATT&CK Tactic and Technique, and investigation guide.
This detailed comprehension of the rule's parameters helps us in recognizing and responding to potential threats promptly and effectively.
Ensuring that the appropriate playbook, created and tested in the preparation phase… assuming, of course, that it was done, is utilized to guide your response and actions during this critical phase is important. For instance, if the alert indicates a potential brute force attack, follow the playbook for account compromise, which may include steps such as:
Evidence is a piece of information or data left by the threat that can be collected during an incident response. The step of identifying and collecting evidence is crucial, as it forms the foundation for understanding the incident and supports the investigation by providing key insights into the threat's nature and impact. Evidence can take different forms, each providing valuable insights into the nature of the attack, such as file hashes, IP addresses. To prioritize which evidence to collect, analysts can refer to the Pyramid of Pain, a framework that helps determine the most critical types of evidence to focus on. By focusing on higher levels of the pyramid, such as Tactics, Techniques, and Procedures (TTPs) or the tools used by the attackers, analysts can gather more lasting evidence that is harder for adversaries to alter or conceal, thus improving the overall effectiveness of the investigation and response.
Lemony Snicket sums it up perfectly “Making assumptions simply means believing things are a certain way with little or no evidence that shows you are correct, and you can see at once how this can lead to terrible trouble.” Why did you check the title?... Exactly... the title was sarcastic!
While the title may seem sarcastic, it underscores a critical truth: in cybersecurity, relying solely on assumptions without concrete evidence can lead to catastrophic outcomes. It's essential to base our decisions and actions on solid evidence and thorough analysis.
Once the incident response team confirms that an incident has occurred, they should immediately begin documenting all artifacts and relevant details. Every action taken, from the moment the incident is detected to its eventual resolution, should be recorded and timestamped. The document should include at least the following:
At this point, we have a clear understanding of what the Incident Response process involves. We’ve covered the first two phases: Preparation and Detection & Analysis. In the next blog, we’ll explore the remaining phases of the Incident Response process, completing our journey through the entire process. Stay tuned!
