Incident Response Process PDF

Incident Response Process The three pillars that sustained security posture, two of them (detection and response) are directly correlated with the Incident Response (IR) process. To enhance the foundation of security posture, we need to have a solid incident response process....

Incident Response Process The three pillars that sustained security posture, two of them (detection and response) are directly correlated with the Incident Response (IR) process. To enhance the foundation of security posture, we need to have a solid incident response process. Chapter 2 Incident Response 1  Incident Response Process This process will dictate how to handle security incidents and rapidly respond to them. Many companies do have an incident response process in place, but they fail to constantly review it to incorporate lessons learned from previous incidents, and on top of that, many are not prepared to handle security incidents in a cloud environment. Chapter 2 Incident Response 2  Incident response process. There are many industry standards, recommendations, and best practices that can help you to create your own incident response. You can still use those as a reference to make sure you cover all the relevant phases for your type of business. The one that we are going to use as a reference in this book is the Computer Security Incident Response (CSIR) publication 800-61R2 from NIST(1). Chapter 2 Incident Response 3 Chapter 2 Incident Response 4  What is Incident response ? Incident response refers to the organized approach that organizations utilize to detect, manage, and recover from Cybersecurity incidents, such as data breaches or Cybersecurity incidents. It encompasses a series of planned procedures aimed at minimizing damage and restoring normal operations as swiftly as possible. Chapter 2 Incident Response 5 Chapter 2 Incident Response 6  Reasons to have an IR process in place It is important to be aware of some of the terminology that is used, and also what the final goal is when using IR as part of enhancing your security posture. Chapter 2 Incident Response 7  Reasons to have an IR process in place Why is it important? Let's use a fictitious company to illustrate why this is important. Chapter 2 Incident Response 8  Reasons to have an IR process in place The following table has some considerations about each step in this scenario: Chapter 2 Incident Response 9  Reasons to have an IR process in place The following table has some considerations about each step in this scenario: Chapter 2 Incident Response 10  Reasons to have an IR process in place The following table has some considerations about each step in this scenario: Chapter 2 Incident Response 11  Reasons to have an IR process in place Companies that have a good security posture would have an incident response process in place. They would also ensure that the following guidelines are adhered to: All IT personnel should be trained to know how to handle a security incident. All users should be trained to know the core fundamentals about security in order to perform their job more safely, which will help avoid getting infected. There should be integration between their help desk system and the incident response team for data sharing. Chapter 2 Incident Response 12  Reasons to have an IR process in place This scenario could have some variations that could introduce different challenges to overcome. One variation would be if no indication of compromise (IoC) was found in step 6. In this case, the help desk would easily keep troubleshooting the issue. What if at some point things started to work normally again? Is this even possible? Yes, it is! Chapter 2 Incident Response 13  Reasons to have an IR process in place When an attacker infiltrates the network, they usually wants to stay invisible, moving laterally from one host to another, compromising multiple systems and trying to escalate privileges by compromising an account with administrative level privileges. That's the reason it is so important to have good sensors not only in the network, but also in the host itself. With good sensors in place, you would be able to not only detect the attack quickly, but also identify potential scenarios that could lead to an imminent threat of violation (3). Chapter 2 Incident Response 14  Creating an incident response process Although the incident response process will vary according to the company and its needs, there are some fundamental aspects of it that will be the same across different industries. Chapter 2 Incident Response 15  Creating an incident response process The following diagram shows the foundational areas of the incident response process: Chapter 2 Incident Response 16  The foundational areas of the incident response process The first step to create your incident response process is to establish the objective - in other words, to answer the question:1What's the purpose of this process it is important that you are very clear as to the purpose of the process so that everyone is aware of what this process is trying to accomplish. Chapter 2 Incident Response 17  The foundational areas of the incident response process Once you have the objective defined, you need to work on the scope. Again, you start this by answering a question, which in this case is: 1To whom does this process apply? Although the incident response process usually has a company-wide scope, it can also have a departmental scope in some scenarios. For this reason, it is important that you define whether this is a company-wide process or not. Chapter 2 Incident Response 18  The foundational areas of the incident response process Each company may have a different perception of a security incident; therefore, it is imperative that you define what constitutes a security incident, and give examples. Along with the definition, companies must create their own glossary with definitions of the terminology used. Different industries will have different sets of terminologies, and if these terminologies are relevant to a security incident, they must be documented. In an incident response process, the roles and responsibilities are critical. Without the proper level of authority, the entire process is at risk. Chapter 2 Incident Response 19  The foundational areas of the incident response process The importance of the level of authority in an incident response is evident when you consider the question: Who has the authority to confiscate a computer in order to perform further investigation? By defining the users or groups that have this level of authority, you are ensuring that the entire company is aware of this, and if an incident occurs, they will not question the group that is enforcing the policy. Chapter 2 Incident Response 20 The foundational areas of the incident response process What defines a critical incident? How are you going to distribute your manpower when an incident occurs? Should you allocate more resources to incident "A" versus incident "B"? Why? These are only some examples of questions that should be answered to define the priorities and severity level. Chapter 2 Incident Response 21 The foundational areas of the incident response process To determine the priority and severity level, you will need to also take into consideration the following aspects of the business: Functional impact of the incident in the business: The importance of the affected system for the business will have a direct effect on the incident's priority. All stakeholders for the affected system should be aware of the issue, and will have their input in the determination of priorities. Type of information affected by the incident: Every time you deal with PII, your incident will have high priority; therefore, this is one of the first elements to verify during an incident. Chapter 2 Incident Response 22  The foundational areas of the incident response process To determine the priority and severity level, you will need to also take into consideration the following aspects of the business: Recoverability: After the initial assessment, it is possible to give an estimate of how long it will take to recover from an incident. Depending on the amount of time to recover, combined with the criticality of the system, this could drive the priority of the incident to high severity. Chapter 2 Incident Response 23 The foundational areas of the incident response process In addition to these fundamental areas, an incident response process also needs to define how it will interact with third parties, partners, and customers. Chapter 2 Incident Response 24  The foundational areas of the incident response process For example, if an incident occurs and throughout the investigation process it was identified that a customer's personal identifiable information (PII) was leaked, how will the company communicate this to the media? In the incident response process, communication with the media should be aligned with the company's security policy for data disclosure. Chapter 2 Incident Response 25  The foundational areas of the incident response process The legal department should also be involved prior to the press release to ensure that there is no legal issue with the statement. Procedures to engage law enforcement must also be documented in the incident response process. When documenting this, take into consideration the physical location where the incident took place, where the server is located (if appropriate), and the state. By collecting this information, it will be easier to identify the jurisdiction and avoid conflicts. Chapter 2 Incident Response 26  Incident response team The format of the team will vary according to the company size, budget, and purpose. A large company may want to use a distributed model, where there are multiple incident response teams with each one having specific attributes and responsibilities. This model can be very useful for organizations that are geodispersed, with computing resources located in multiple areas. Other companies may want to centralize the entire incident response team in a single entity. This team will handle incidents regardless of the location. 27 Chapter 2 Incident Response  Incident response team After choosing the model that will be used, the company will start recruiting employees to be part of the team. The incident response process requires personnel with technically broad knowledge while also requiring deep knowledge in some other areas. The challenge is to find people with depth and breadth in this area, which sometimes leads to the conclusion that you need to hire external people to fulfill some positions, or even outsource part of the incident response team to a different company. 28 Chapter 2 Incident Response  Incident response team The budget for the incident response team must also cover continuous improvement via education, the acquisition of proper tools (software), and hardware. As new threats arise, security professionals working with incident response must be ready, and trained to respond well. Many companies fail to keep their workforce up to date, which is not good practice. When outsourcing the incident response process, make sure the company that you are hiring is accountable for constantly training their employees in this field. 29 Chapter 2 Incident Response  Incident response team If you plan to outsource your incident response operations, make sure you have a well defined service-level agreement (SLA) that meets the severity levels that were established previously. During this phase, you should also define the team coverage, assuming the need for 24-hour operations. Chapter 2 Incident Response 30  Incident response team Here, you will define: Shifts: How many shifts will be available for 24-hour coverage? Team allocation: Based on this shift, who is going to work on each shift, including full-time employees and contractors? On-call process: It is recommended that you have on-call rotation for technical and management roles in case the issue needs to be escalated. Chapter 2 Incident Response 31  What is the On-Call Process? On-call processes are essential in various industries, particularly in IT and healthcare, where immediate responses to incidents are crucial The on-call process involves having designated employees available to respond to emergencies or incidents outside of regular working hours. These employees monitor systems, respond to alerts, and resolve issues as quickly as possible. Typically, organizations implement a rotational schedule where team members take turns being on-call, ensuring that someone is always Chapter available 2 Incident Response to address 32 urgent needs  Incident life cycle Every incident that starts must have an end, and what happens in between the beginning and the end are different phases that will determine the outcome of the response process. This is an ongoing process that we call the incident life cycle. What we have described until now can be considered the preparation phase. However, this phase is broader than that it also has the partial implementation of security controls that were created based on the initial risk assessment (this was supposedly done even before creating the incident response process). Chapter 2 Incident Response 33  Incident life cycle Also included in the preparation phase is the implementation of other security controls, such as: Endpoint protection Malware protection Network security The preparation phase is not static, and you can see in the following diagram that this phase will receive input from post-incident activity. Chapter 2 Incident Response 34  Incident life cycle The other phases of the life cycle and how they interact are also shown in this diagram: The DETECTION and CONTAINMENT phase could have multiple interactions within the same incident. Once the loop is over, you will move on to the post-incident activity phase. Chapter 2 Incident Response 35  Handling an incident Handling an incident in the context of the IR life cycle includes the detection and containment phases. In order to detect a threat, your detection system must be aware of the attack vectors, and since the threat landscape changes so rapidly, the detection system must be able to dynamically learn more about new threats and new behaviors, and trigger an alert if a suspicious activity is encountered. Chapter 2 Incident Response 36  Handling an incident While many attacks will be automatically detected by the detection system, the end user has an important role in identifying and reporting the issue in case they find a suspicious activity. For this reason, the end user should also be aware of the different types of attack and learn how to manually create an incident ticket to address such behavior. This is something that should be part of the security awareness training. Chapter 2 Incident Response 37  Handling an incident Even with users being diligent by closely watching for suspicious activities, and with sensors configured to send alerts when an attempt to compromise is detected, the most challenging part of an IR process is still the accuracy of detecting what is truly a security incident. Chapter 2 Incident Response 38  Handling an incident Oftentimes, you will need to manually gather information from different sources to see if the alert that you received really reflects an attempt to exploit a vulnerability in the system. Keep in mind that data gathering must be done in compliance with the company's policy. In scenarios where you need to bring the data to a court of law, you need to guarantee the data's integrity. Chapter 2 Incident Response 39  Handling an incident The following diagram shows an example where the combination and correlation of multiple logs is necessary in order to identify the attacker's final mission: Chapter 2 Incident Response 40  Handling an incident In this example, we have many IoCs, and when we put all the pieces together we can validate the attack. The following table explains the diagram in more detail: Chapter 2 Incident Response 41  Handling an incident As you can see, there are many security controls in place that can help to determine the indication of compromise. However, putting them all together in an attack timeline and crossing the data can be even more powerful. that detection is becoming one of the most important security controls for a company. Sensors that are located across the network (on-premises and cloud) will play a big role in identifying suspicious activity and raising alerts. A growing trend in Cybersecurity is the leveraging of security intelligence and advanced analytics to detect threats more quickly and reduce false positives. This can save time and enhance the overall accuracy. Chapter 2 Incident Response 42  Handling an incident Once the incident is detected and confirmed as a true positive, you need to either collect more data or analyze what you already have. If this is an ongoing issue, where the attack is taking place at that exact moment, you need to obtain live data from the attack and rapidly provide a remediation to stop the attack. Chapter 2 Incident Response 43  Handling an incident For this reason, detection and analysis are sometimes done almost in parallel to save time, and this time is then used to rapidly respond. Having said that, it is important to mention that there is a separate phase for containment eradication and recovery, which is something that is going to be covered in the next section of this chapter. Chapter 2 Incident Response 44  Handling an incident The biggest problem happens when you don't have enough evidence that there is a security incident taking place, and you need to keep capturing data in order to validate the veracity. Sometimes the incident is not detected by the detection system. Perhaps it is reported by an end user, but he can't reproduce the issue at that exact moment. There is no tangible data to analyze, and the issue is not happening at the time you arrive. In scenarios like this, you will need to set up the environment to capture data and instruct the user to contact support when the issue is currently happening Chapter 2 Incident Response 45  Best practices to optimize incident handling You can't determine what's abnormal if you don't know what's normal. In other words, if a user opens a new incident saying that the server's performance is slow, you must know all the variables before you jump to a conclusion. To know if the server is slow, you must first know what's considered to be a normal speed. This also applies to networks, appliances, and other devices. To mitigate scenarios like this, make sure you have the following in place: Chapter 2 Incident Response 46  Best practices to optimize incident handling System profile Network profile/baseline Log-retention policy Clock synchronization across all systems Based on this, you will be able to establish what's normal across all systems and networks. This will be very useful when an incident occurs and you need to determine what's normal before starting to troubleshoot the issue from a security perspective. Chapter 2 Incident Response 47