"Every incident starts as an event, but not all events become incidents"
The gravity of that statement rings true to any incident response team that has had to deal with numerous events that, on the surface, seem to be an incident but turn out to be just an event. To better understand the difference between an incident and an event, let's take a look at the analogy of a security guard: A security guard acts as a sentry at an entry point and watches but does not respond to all visitors passing through the checkpoint. He/she stops and questions suspicious individuals or packages asking for validation. As long as proof of validation is present, the interaction is documented as a Security Event with no further action beyond documentation. However, if the guard did not receive proof of validation or the individual tried to make a run for it, he/she will immediately initiate incident response procedures which would be based on the severity of the incident. Further, they may have to hand over the response efforts to an operations group (aka Incident Response Team) and return to their station.
With that said, what exactly is Incident Response? An incident response encompasses the operational, technical expertise and procedures necessary to respond to an incident. The incident response team is commonly staffed by subject matter experts, administrators and technical leads. However, for an organization to get the most out of an incident response plan, defining these roles and their expected outputs is critical.
The incident response process can be broken down into four main stages:
Preparation. This will involve identifying and enumerating all assets in your environment, categorizing them in order of criticality, baselining asset behavior, setting a threshold and creating a clear communication plan.
Detection and analysis. It will encompass actual retrieval and analysis of any data related to the incident, initiating the incident response and incident handling plans and determining the extent of the incident.
Containment, Eradication and Recovery. At this point, measures like network/endpoint isolation, server wipes and rebuilds, kerberos key re-generation and authentication removal or lock will be put in place.
Post incident activity. The final stage of the incident response process where the incident data collected throughout the process will be used to harden infrastructure, generate more precise alerting and review and alter team actions based on the incident response effectiveness.
Now that we understand what an incident is and what the incident response process entails, it is time we dive in to the Incident Response plan and why every organization needs one. One thing you should keep in mind when formulating an IR plan is that anything that is security related must always map back to the business needs and should aid in achieving the overall objectives of the organization. The main reasons your organization needs an IR plan includes the following:
a. An IR plan prepares you for emergencies helping you prepare a process ahead of time.
b. It creates a repeatable process which an IR team can follow when attending to an incident.
c. Provides smooth coordination in large organizations with clear lines of communication.
d. It exposes existing security gaps which can be addressed before a crisis occurs.
e. It enables preservation of critical knowledge and best practices when dealing with a crisis.
f. Provides clear documentation and accountability which can be presented to compliance auditors in turn reducing an organization's liability.
g. The IR plan improves coordination and effectiveness of an IR team over time.
When creating an IR plan for your organization, it must adequately address the following elements;
Mission. It should adequately reflect both the organization's mission and that of the IR team.
Strategies and goals to accomplish the intents of the policy.
Act as a Maturity roadmap for the Incident Response policy.
Define the team roles to support the strategies and goals
Serve as a metrics to measure the incident response effectiveness and capabilities.
How the program fits into the overall operation of the organization.
How the IR team will communicate with members of the organization and other external organizations.
Bearing all this in mind, an effective IR plan should be clear and concise, have a communication strategy, have a standard template, and most importantly put to the test through conducting frequent drills and simulations to adapt to the immediate needs of the organization.
References: