Organizations are bombarded with potential threats every day. Most of the events or incidents posing threats are not likely to cause any damage in your environment, but they need to be investigated, nonetheless. To quickly and efficiently investigate and respond to threats, you need a plan. An incident response plan defines your response, not only to effectively address specific, individual incidents, but also to examine sequences of events to determine if they may match the steps an attacker might take to compromise security in your environment.
The ultimate goal of an incident response plan is not only to effectively address specific, single incidents, but also identify potential threats originating from a sequence of events or incidents that could be used to carry out a broader attack. Having a plan, complete with procedures and processes in place to address different scenarios is important, because, even if you accept that nothing will go exactly according to plan, it still will provide a valuable checklist and reference for everything that needs to be done. That can provide incredible value, especially during highly stressful times of crisis.
Many different security organizations and standards groups publish recommendations or guidelines for incident response processes for companies to follow for their network security incident investigation, remediation or mitigation, and follow-up. These recommendations typically include very similar elements such as the following:
- Preparation — Preparing IT and an incident response team of people with resources, procedures, priorities, and escalation to handle potential incidents in case they happen; deployment and monitoring setup to establish baseline behavior. Setting up alarms, eliminating false positives and false negatives.
- Analysis, Detection, and Identification — Developing tools and providing specific instructions and procedures to analyze incidents, analyze their severity, identify actual and potential exploits associated with incidents, and determining the priority and possible escalation in remediation or mitigation of threats and vulnerabilities.
- Containment, Eradication, and Recovery — Guidelines for isolating systems affected by security incidents, to prevent further damage, finding and eliminating the root cause of attacks, and remediating or mitigating threats. Permitting affected systems back into the production environment after addressing issues (and monitoring systems for future repeat incidents).
- Post-Incident Activity and Lessons Learned — post-mortem data collection and reporting following resolution of issues. Documenting activities and results in addressing incidents and maintaining records for compliance assessments. Review and discussion with all incident response team members, to improve future incident response efforts.
Note: AlienVault's website provides a free downloadable PDF eBook, AlienVault’s Insider’s Guide to Incident Response, that includes many practical tips and advice for developing your own incident response plan, and directing your incident response team to investigate and address security incidents in your own environment.1
What Defines an Incident?
An incident is an unplanned event that requires some measure of investment of time and resources to rectify. Eventually you are going to develop your own internal grading system for incidents, but this is the measure most organizations should begin with.
Incidents in the security world usually imply that an external (although sometimes internal) hostile party has unauthorized access to, or control of, systems that support your organization’s core processes. Many organizations can be compromised for a great deal of time before it is discovered. As a general rule, most organizations declare something an incident at the point at which security analysts from the outside must be brought in to remediate a situation.
What Defines a Breach?
In legal terms, breaches represent a significant loss of data to an unauthorized external party, and may require public disclosure of the loss according to law. A network may be attacked many thousands of times without worry, be compromised (and recover from it) many times during the year, but still continue doing business uninterrupted, as long as it is not breached.
What to Include in Your Incident Remediation Plan
One of the great benefits of security monitoring is not only detecting when security controls have failed, but how they failed, and then rolling that information back into improving overall security.
When a host is compromised by means of a malicious website, cleaning the infected host is only part of the response. On the other hand, blocking the malicious website to prevent any further infections proves the real worth of security monitoring.
Security monitoring without this kind of root cause analysis treats only the symptoms, not the disease. For this reason, make sure that when planning the deliverables from your incident response plan, that you not only emphasize fixing compromised systems, but also collecting information to remediate the problems that caused the compromise to prevent them from occurring again.
Developing an Effective Triage Strategy
The term triage is more commonly used within the medical community, where it means saving lives by helping emergency medical personnel rapidly assess wound or illness severity, and establish the right protocols, in the right order to reduce trauma and sustain patient health and recovery. However, these same principles can be applied to security analysis as well. Some guidelines to help you perfect your ability to triage information security incident types might include the following:
- How to identify the various types of security incidents, by understanding how attacks unfold.
- How to prioritize remediation efforts, for example, to identify which incidents to investigate first by what potential threats could cause the most damage to your business.
- How to effectively respond in crisis situations.
These are just a few ideas to consider in defining triage efforts within your incident response planning. You will likely want to consider more triage and incident response practices based on your specific environment, and your specific compliance and network security requirements.