IT Security 101: Incident Response (IR)
Introduction
In this installment of ITSEC101, I will take a look at Incident Response (IR).
IR is a formalized approach for effectively reacting to major security events that have resulted in some level of impact. It is separate to general alert response, in that it is a process triggered after an event has resulted in a negative outcome, such as a malware infection, protected data disclosure, business email compromise, etc.
It is important to understand what IR is, how to make it effective, and when to utilize it.
Security Events, Alerts and Incidents
Before going into the details of IR, I’d like to take a look at the difference between events, alerts and incidents. This is an important distinction because not all security events are necessarily worrisome, and not all alerts require the same level of response.
Security Events
Security events occur constantly. Any time a user logs in, logs out, a password fails, a suspicious email arrives, a system reboots, the power goes out, and so on, is an event. The important thing to think about is, when are security events important? Which events indicate a fault or misconfiguration, a potential threat, or worse, full-blown compromise?
Security Alerts
Security alerting is a mechanism by which interested parties are informed when certain security events, or thresholds of event activity, occur. Alerts are configured by administrators, or come preconfigured within security and system monitoring tools. Their purpose is to inform someone when something interesting happens that requires follow-up. Just as events are ongoing, alerts are also constant and care should be taken to ensure they are providing useful information that can be appropriately actioned. Alerts can identify accidental failures, or malicious activity, and must be configured properly so that responders can take action. Alerts that lack context, or point toward unimportant events, can lead to alert fatigue, complacency, and a lack of confidence in the reporting tool. Too much noise in alerting can also mask the really important events.
Security Incidents
Security incidents are security events with negative outcomes that have been realized. These require a higher level of response than the every day alert. Therefore, a documented process should be developed that helps an organization consistently and effectively identify, respond to and recover from such events. The process is known as the Incident Response Lifecycle, and the procedures an organization develops for each activity in the process are collectively called the Incident Response Plan.
The Incident Response Lifecycle (IRL)
The IRL describes a series of steps an organization goes through in order to prepare for incidents and see them through to a successful conclusion.
There are different interpretations of this concept from different frameworks and standards, all offering the same general idea with slight variations. In its most basic form, the IRL can be broken down into 5 main steps:
Preparation -> Detection and Analysis -> Containment -> Eradication and Recovery -> Post-Incident Activities
In the Preparation phase, an organization develops its strategy. This includes the selection and deployment of administrative and technical controls to protect the environment and prevent an incident from occurring in the first place. That is why it is important to use the lessons learned from past incidents to not only modify the response approach, but also to identify areas of improvement in the overall security posture. Training and testing are also included in this phase, to specifically prepare staff on the organization’s IR approach.
The Detection and Analysis phase, also referred to as Identification, is the point at which an incident’s scope and impact are identified. As events can move quickly, it is key to have other sources to refer to for assistance, such as risk assessments, business impact analyses (BIAs), business continuity plans (BCPs) and disaster recovery plans (DRPs), as these are extensive and time consuming processes. Instead, the technical arm of the response team should utilize their tools to review alerts, logs, and other sources of activity, and gather as much data on the event as possible to identify the scope and impact.
In the Containment phase, procedures are initiated to reduce the impact. This includes deploying antimalware tools, segregating and quarantining systems, severing network connections, etc. Care should be taken during this phase to maintain forensic data, balanced against the severity of the threat and the organization’s need to prevent further damage.
The Eradication and Recovery phase are some times considered separate phases. During Eradication, steps are taken to remove the threat, whereas during Recovery, steps are taken to return systems to functional states. However, these activities often occur simultaneously. In general this is an overall attempt to return to business as usual. Threat components are eradicated, devices are patched, cleaned or replaced, data is restored from backup, systems are spun back up, permissions are restored, networks are reconnected, etc. The speed and methods involved may be dictated by other sources already mentioned such as BCPs and DRPs.
Finally, Post-Incident activities typically include lessons learned documents and sessions, and the validation of previous stages, such as ensuring systems are clean, fully restored, and appropriate steps have been taken to prevent immediate reoccurrence, and to monitor the situation. This phase then feeds directly into a new Preparation phase.
The IRL is a systematic approach to IR and a good description of the overall process. It is an ongoing and evolving process, where each preparation phase includes lessons learned from the previous incident. There are many moving parts, and it is not always possible to follow each piece step-by-step. Often, the activities occur in tandem with different teams performing different tasks. That is why it is vital to have a plan in place so that everyone knows exactly what to do and when, and have the proper channels in place to coordinate activities.
The Incident Response Plan (IRP)
The IRP is a codified set of procedures that should be followed during all incidents. It should be consistent, repeatable, actionable, and flexible, regardless of the actual events or scope involved in the incident. As part of the IRP, playbooks are developed to help teams respond to specific cases, but overall the general approach should be the same.
The key components of an effective IRP include:
Role Assignment
Call Trees and Communication Channels
Playbooks
The roles necessary for IR include:
IR Leadership / Management / Coordination
IR Commander / Coordinator
IR Technical Teams
Communications
Incident Scribe
The IR leadership team is responsible for oversight of the entire process and its development. This is separate from the designated incident coordinator who is responsible for oversight during an incident. This person makes sure the IRP is being followed, and directs the other members of the Incident Response Team (IRT), also called the Security Incident Response Team (SIRT), or Cybersecurity Incident Response Team (CSIRT).
The IRT includes individuals responsible for specific activities. The IR Technical Teams typically comprises security team members and IT staff familiar with systems who can perform the various identification, analysis, remediation and recover tasks.
The IRT should also include members of HR/PR or Legal to help the team understand any regulatory or legal requirements. These members should also manage communications with the rest of the company, as well as external parties such as law enforcement and the news.
Lastly, someone should be designated to document all activities and collect relevant sources of data to help with post-incident activities, as the other teams will be busy with their tasks.
To assist with coordination, call trees should be maintained, and communication channels should be established so that the IRT and other interested parties can be alerted and kept informed. Further, the communication plan should include a method for coordinating during an incident. All communication should be done securely, and have backup methods in place should the initial channel be affected by the incident.
Finally, for quick and effective response, playbooks should be developed for different event scenarios, with step-by-step instructions on each phase of the process. They should be geared toward different threats and assets, and easily accessible and available offline in the event that digital copies are affected by the incident.
Conclusion
That is the basics of IR. There are certainly nuances to the process, and more specifics that could be explored, but they go beyond the scope of this introductory lesson. For further reading, see the Resources section below.
Daily Cuppa
Today’s cup of tea is Tulsi Masala Chai provided by Organic India. Organic, Fair Trade, and full of spicy flavor and energizing aromas.
If you enjoyed this article, or the site in general, feel free to buy the author a cup of tea.