Responding to a security breach - The incident response process explained

Incident Response (IR) is the practice of preparing an organization for the event of a security or data breach through a multitude of means.

Not every incident is going to be the same and as such, incident responders must have the ability to react to different situations. This requires a carefully documented and easily executable plan to allow an organization to quickly eradicate malware, ransomware or similar.

Today we’re discussing what an effective IR plan looks like and what vital elements can’t be overlooked to ensure a successful approach.

A full and detailed analysis of an effective IR process can be found in our Insight Paper: “Determining the Effectiveness of an Incident Response Plan” 

The Six Stages of the Incident Response Process

CREST – a non-profit organization providing assurance over the quality of services offered by security firms – has developed a well-defined model for assessing the maturity of each of the six Incident Response stages.

The graphic below shows how this model addresses controls in six stages of the Incident Response process. We are going to look, in detail, at the controls for each of these stages.
Incident response graphic

Preparation

The key to the preparation stage is to conduct a careful analysis during simulated incident tests.

This allows an organization to create a carefully constructed Incident Response timeline with all responsibilities allocated to the most appropriate stakeholder.

An Incident Response plan should also include an analysis of the IR resources a company has at its disposal such as port lists, protocol analyzers, network diagrams etc.

This analysis should conclude in the preparation of an IR Tool Kit, ready to use in the event of a breach.


Identification

An organization should make sure the relative defences are in place to ensure that indicators of compromise are identified.

Such identifiers include:

  • Unusual outbound network traffic
  • New admin users created
  • Anomalies in privileged user account activity (first logon to a system)
  • Geographical irregularities (non-standard login attempts)
  • Increased database read volume (database dump)
  • Large numbers of request for the same file
  • Suspicious registry or system file changes
  • Unexpected patching
  • Signs of DDoS activity

If an IT security team doesn’t feel like these indicators would show up in their security system, further review may be required.

Containment

Once an organization is confident that an incident can/will be identified, the focus then turns to containing that incident. An organization should allocate defined courses of action based on the potential impact of various incidents.

IT needs to examine if it has control of aspects such as the blocking of unauthorized access, blocking of dangerous IP and email addresses or even the isolation of systems on the network amongst others. This exercise ensures the IT function has complete control and visibility of such actions.

Eradication

The next step is to eliminate the cause of the incident – this stage may overlap with the containment stage.

The aim here is to eradicate the cause, the actual incident and the compromise itself. Once this is done, it’s imperative that the eradication is verified (e.g. by monitoring traffic and reviewing critical logs).

The IR process should allow for eradication steps such as:

  • Removing the attack from the network
  • Deleting malware
  • Disabling breached user accounts
  • Identifying vulnerabilities that were exploited
  • Mitigating vulnerabilities that were exploited
  • Is there a formal process for handling evidence when dealing with an incident?
  • Are there steps to follow to preserve evidence when dealing with the incident?

Restoration

A detailed recovery plan should be prepared and reviewed to determine that all recovery processes are carried out to ensure the restoration of the system as soon as possible, such as: restoring the system from back-up logs, notifying the relevant stakeholders and addressing similar identified vulnerabilities on the network etc.

The restore phase must also consider validating that systems are back to being fully operational and protected.

The IR plan should consider including elements such as an external penetration test to assess that the restored fixes are sufficient. Consideration should also be given to the level of detail being provided to stakeholders and the timeline for same.

Lessons Learned

This is often considered the most important stage of the IR process as lessons learned can go a long way to preventing future incidents.

In short, this stage involves:

1) Performing a post incident review to identify all the actions taken during the course of the recovery process

2) Formally documenting these lessons, identifying where lessons were learned and communicating these to the relevant stakeholders

3) Updating and amending the existing IR plan to allow for these lessons to be applied to future incidents

Conclusion

Although it is not possible to fully prepare for unknown future incidents, there are elements of an Incident Response process which require preparation, to allow effective incident mitigation.

The bottom line is that an Incident Response plan not only needs to be formally defined, but must be periodically assessed to ensure it is still effective.

Applying a well-defined and mature Incident Response framework, like the one developed by CREST, helps in covering all important aspects of such an assessment.