Incident response is a critical aspect of any security program. A well-designed incident response program can greatly decrease the cost of a security incident or data breach. Additionally, it is also a requirement for most common security frameworks. Consider the following requirements from SOC 2 and ISO 27001 as you learn more about designing an incident response program:
SOC 2 Common Criteria 7.4: The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.
ISO 27001 Annex A.16.1 Objective: To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses.
Collecting Security Events
Designing an incident response program begins with the collection of security events. According to the ISO 27000 standard, an event is:
An identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of controls, or a previously unknown situation that can be security relevant.
Thus, the program should start long before an incident is identified. Events can be collected from many different sources, including server logs, SaaS apps, and virus scanning tools. These events should be stored, and alarms should be set for significant events. The incident response policy should list all sources of security events.
Analyzing Security Events
Once a security event has been identified, the security team must analyze it. The incident response policy should define the criteria for analysis. These criteria may include downtime, probability of account compromise, and possible financial loss. If a security event meets the criteria, it is classified as a security incident. According to the ISO 27000 standard, a security incident is:
Single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security.
Responding to Security Incidents
Once an incident has been identified, the incident response plan should be invoked. The response plan should list procedures to contain, eradicate, and recover from the security incident. Additionally, the plan should contain contact information for internal stakeholders, law enforcement, and any regulatory bodies or customers that must be contacted. These procedures and contacts will vary greatly depending on your organization. After the security incident has been eradicated and all systems have been recovered, appropriate personnel should perform a post-mortem. The purpose of the post-mortem is to define the root cause of the incident. Management should determine if corrective action is needed to prevent a similar incident from happening in the future
Incident response is a crucial element of any security program. Mature incident response programs provide insight into the security posture of an organization and help drive future improvements to security.
Need help designing an incident response program? Contact our team of experts here and we will be happy to help!