<img height="1" width="1" src="https://www.facebook.com/tr?id=3212881575388825&amp;ev=PageView &amp;noscript=1">

When a security incident disrupts normal operations, the burst of activity can get hectic and confusing. Teams are trying to determine the cause, isolate the affected systems, keep critical systems running, and ensure that end-users are able to work productively through it all. This is where having an incident-response plan and framework in place can be a big help in getting you back to ‘business as usual.’

There are a number of possible frameworks, but at SOCBOX, we like to approach it as a three-step process.


1. Detection and Analysis

This step is probably the most challenging for IT departments to do on their own. Potential intruders typically use automated tools to probe your defenses. The goal is to determine what software and systems you have in place, and uncover some vulnerability that could be exploited. This abnormal network traffic occurs thousands of times a day, even at a small business.

Security information and event monitoring (SIEM) or endpoint detection response (EDR) tools issue alerts about atypical network traffic. When an organization implements one of these tools, the volume of alerts — even if the tool is very carefully tuned — is very, very high. With alerts coming in every few minutes, someone could spend their entire day simply investigating alerts.

In fact, in some of the more notorious breaches — the Target incident, for example — these tools were in place. The IT teams used them to sort out what happened after the fact. But as the incident unfolded, they received so many alerts, there simply wasn’t time to process them all. A huge component of detecting and responding effectively to threats is not only having visibility of the alerts, but also the expertise to identify the critical ones and analyze what the criminal is doing. Few IT departments are able to maintain this level of expertise in-house.


2. Containment, Eradication and Recovery

What happens when an alert or a series thereof escalates into a full security incident? The actual steps required to secure vulnerabilities, mitigate the impacts of an incident and restore normal function depends on the nature of the incident itself. What we emphasize is the importance of having a process in place. The response plan includes the following:

  • Expected service-level agreements around response and remediation
  • Who should be contacted, and how, in the event of a low-, medium- or high-grade incident
  • How the contacted individuals will respond and who they need to communicate with — whether it’s end-users, IT staff or C-level executives
  • If service will be interrupted during the remediation process, how that will be managed and communicated
  • Responsibility for contacting any compliance organization or authority that is required

These are all parts of the incident response framework that should be spelled out beforehand — not invented on the fly while the team is in the midst of dealing with an incident.


3. Incident Post-Mortem

The post-mortem step is vital because the post-analysis gives everyone the opportunity to learn from the event, prevent similar occurrences in the future, and to fine-tune processes. The post-mortem plan identifies who should be involved and how they should collaborate to produce a post-analysis that includes:

  • Key takeaways
  • Changes that should take place
  • Long-term plan
  • Documentation as necessary or required

Having a response plan in place isn’t just wise; it’s essential for compliance with regulations such as GDPR and HIPAA. At SOCBOX, we share a document called the SOCBOX Incident Management Framework with our clients to establish how our SOC and the client’s IT department will work together to respond to incidents.

Want help developing your own Incident Response plan? Reach out to us here or at 877-287-7789 today.