How To Combat An Incident Response Nightmare

Imagine the following scenario, you’re a business owner about to leave work and return home to enjoy some well-deserved down time. Your work phone rings, dread washes over you as you look at the caller ID; one of your IT staff is calling about to ruin your night. An employee’s machine has been encrypted with malware, restricting access after a successful phishing attempt. In addition to this, rampant pop-ups demanding an instant ransom payment is the cherry on top.

Questions like ‘who caused this’, ‘is it localised’ and ‘do we have the finances to pay the ransom’ are bound to whip through your mind, potentially even ‘do we have an incident response plan?’

If the answers to the above questions are ‘no’ and you have neither an incident response (IR) plan or policies in place to deal with a nightmare like this, worry not, everyone starts somewhere.

This blog won’t have all the answers, but it should help serve as a springboard to steer your business and you in the right direction.

What is an Incident Response (IR) Plan?

An IR plan is essentially a set of guidelines to help a business plan and facilitate effective incident response strategies. The plan could detail how an incident is handled, to the processes involved or escalation procedures.

Why is it helpful?

Random actions provide random results, especially in times of high stress and pressure. A well-defined IR plan will help co-ordinate people, processes and technology meaning you can act quickly to minimise the damage caused and prevent similar incidents in the future.

Where do I start?

CYSIAM recommends using the internationally recognised Incident Response Plan and handbook created by SANS [i]. Broken down into six steps, the following stages will provide a foundation for your team to be able to perform incident response, as well as creating a unique, tailored IR plan for your business.

Preparation

This phase, as its name implies, deals with preparing a team to be ready to handle an incident as a moment’s notice. Regardless of the cause, preparation is the most crucial phase as it will determine how well your team will be able to respond in a crisis.

Firstly, a policy needs to be developed with a set of principles or rules to identify whether an incident has occurred. Next, a procedure/response plan is required alongside documentation which incident responders can record key information against, such as timestamp of incident, patient zero, affected hosts, person(s) that reported an incident, type of incident and incident severity.

Having a communication plan is also necessary; the entire cyber security incident response team (CSIRT) should know whom to contact (especially your escalation contacts), when is it appropriate to contact them and why. Responses to incidents can be severely hampered due to organisations skipping over a communication plan.

As a note, the points above are not exhaustive, but gives you’re an idea of the track to start on.

Identification

We need to understand the threat and the scope of the incident within this phase. Are we dealing with ransomware? If so, how widespread or localised is it? This step requires information to be gathered from various sources such as log files, error messages and other resources, such as intrusion detection systems and firewalls as to determine the incident. Helpful questions to ask the CSIRT could be;

• What malicious network connections are there?
• Any abnormal processes?
• What files were dropped because of the threat?
• Any affected users or compromised accounts?
• Which hosts were infected?

This is also the phase where incident responders should be documenting everything they are doing; they should be gathering and documenting the who, what, where, why and how. The more you understand a threat, the easier it is to contain and eradicate. However, the amount of information you can garner about a threat will depend on your own security monitoring and analysis capabilities, this should be reviewed within the preparation phase.

Containment

The primary purpose of this phase is to limit the damage and prevent any further damage from happening. The scope and the threat pertaining to the incident has been identified, we can now isolate any affected systems from the network and reset any compromised accounts to minimise damage to the business, this is otherwise known as short-term containment. Next, system back-up is required before wiping and re-imaging any system to take a forensic image of the affected system(s) with tools such as EnCase or Forensic Tool Kit (FTK). Lastly, comes long-term containment where affected systems can be temporarily fixed in order to allow them to continue to be used.

The effectiveness of the ‘containment’ phase will heavily depend on the layout and segmentation of your network as well as whether your IT staff fundamentally understand the network. Again, this revolves around your organisation’s current security capabilities and preparation; some businesses lack detailed network diagrams or an understanding of their network infrastructure therefore making the ‘containment’ phase more difficult.

Eradication

This phase deals with the actual removal and restoration of affected systems; it’s now time to clean up the evil whilst still isolated in the network.

If your systems have been hit with ransomware, a key point to remember is that most anti-malware vendors have a lead time for submitting signatures to them. You can think of a signature as a typical footprint or pattern associated with a malicious attack. You’ll need to scan your systems for the malware signature and subsequently remove it. You may also install patches and disable unused services to harden the system against further attacks.

Recovery

It’s time to bring impacted systems back into the production environment carefully, as to ensure that it will not lead to another incident. It is essential to test, monitor and validate the systems that are being put back into production to verify they are not being re-infected by malware and risk another nightmare situation.

In terms of monitoring, this stage will be constrained by the skills and tools available to your IT staff. Ideally you would monitor for malicious network connections or unusual processes from restored systems, or simply validate previously seen abnormalities are no longer present. There is a wealth of open-source tools available to IT teams to be able to facilitate a baseline monitoring capability, though this will require training and research by your IT team. Many commercial tools are also available, but care should be taken to understand why you may implement a certain tool and the role it will play within a business, context is everything.

Lessons Learned

Lessons learned is a stage to complete any documentation that was not done during the incident, as well as any additional documentation that may be beneficial in future incidents. This could include creating a playbook which details the technical steps the CSIRT should take in a future similar incident or highlight the areas of improvement required. The overall goal is to learn from the incident and improve the team’s performance.

Ideally, a process to facilitate lessons learned would be drafted within the preparation phase to ensure it is carried out promptly after the incident; a good rule of thumb is two weeks post incident.

Conclusion

Although it was a quick whistle stop tour, this blog should have provided the foundation for IT professionals and managers to be able to create their own IR plan. As mentioned in the introduction, a well-defined IR plan will help co-ordinate people, processes and technology meaning you can act quickly to minimise the damage caused and prevent similar incidents in the future.

[i] https://sansorg.egnyte.com/dl/...