Reacting immediately to a cyber event could save your reputation.
Data breaches, resulting in exposed credentials and damage to brand and reputation, continue to make headline news. As a result, cyber incident response is gaining more high-profile attention in the media and, crucially, in boardrooms across all industries. But, according to the UK Government’s 2020 Cyber Security Breaches Survey, only 21% of businesses say they follow the most common responses when experiencing a cyber security incident.
Ensuring that everyone in your business knows what to do as soon as a breach is detected is a critical priority that may save both your reputation and your bottom line. Furthermore, understanding whether your security professionals are providing enough information, and involving the right people to ensure management teams make the right investments and strategic decisions to shape incident response plans, is also key.
I remember being asked once if sending the incident response team on a touch-typing course would be beneficial – the theory being that they could out-type hackers during an attack. The joys of epic keyboard battles notwithstanding, it was apparent to me that the reality of incident response (and sometimes IT in general) wasn’t clear to the group of individuals who were key players in the process. Without naming and shaming, there are plenty of examples of public relations faux pas in the period following a major security incident and they all demonstrate the importance of keeping your Top Brass informed. This article will give you a primer on a typical incident response process, which will hopefully add more context to what your public relations team may tell you to say, or why your technical team have locked you out of their office!
The anatomy of incident response
The incident response process can be described as having six phases:
Phase 1: Prepare
As you might imagine, this is the phase that requires the most attention and effort. Good preparation needs all areas of the organisation to contribute, and this process should be led by senior management – the incident response process will either be dictated by, or dictate new, business processes. Preparation will involve everything from defining roles and responsibilities, deciding a communications strategy, to implementing uniform and thorough log-collection on your computing and network infrastructure. Remember the old adage: “Fail to prepare, prepare to fail”. In reality this is actually a continual process, so part of your initial preparation should be to define suitable processes by which you can onboard new systems and review measures for existing ones.
You should seek assistance here too – getting expert help to check how prepared you really are, and to identify any gaps in your defences will pay dividends in the long term. The cyber threat landscape changes on a daily basis and reaching out to recognised experts is always a good option. You can also invest in cyber insurance or subscribe to a recognised incident response service; these are good alternatives when you may not have the internal resources to manage a cyber event.
Phase 2: Identify
This phase is relatively short, but decisive, and it is where the preparation starts to pay off. With this being the first ‘live’ step in the incident response process, it’s important to document everything. Your preparation should have included a standard format for documentation, and it should start with the basics: who’s handling the event, what time the event was first reported, what systems are affected, etc. Your responders will then start working through a predefined checklist to determine the state of the affected systems and compare them to an established baseline for what’s considered normal. (Notice that I’ve been using the word “event” rather than “incident”; part of your preparation should be to define what actually constitutes an incident and, until it’s confirmed that an event meets that criteria, it’s still just an event.) During this phase, responders will use the information gathered to determine the next steps, which may be to downgrade the event and exit the response process, monitor the event for a period of time to gather more data, or declare an incident and escalate.
Phase 3: Contain
If you reach this phase, it’s because you have an incident in progress. The natural response is to immediately try to contain the problem, but in order to do so effectively you must first confirm what type of incident you’re dealing with. Whilst it may seem counter-intuitive that this isn’t performed during the identification phase, remember: during that phase you’re identifying the nature of the event, not the type of incident. A distributed denial-of-service (DDoS) attack, corporate website defacement, and an unauthorised employee accessing sensitive corporate records are examples of potential incidents. Each of these examples warrants a very different response, so effective action requires effective classification of the incident. Likewise, incidents of certain types might require notification of other parties, such as senior management, partners, customers, or even government bodies. Again, this will have been covered during your preparation phase, along with suitable immediate actions, such as disabling accounts, blocking traffic at the firewall, and so on.
These actions come with risks and making a wrong decision could make matters worse, rather than better, so think about them carefully beforehand. An example of a poor response would be pulling the power on a compromised machine – it destroys valuable evidence and, whilst it may stop the incident in progress, the machine can’t be investigated while it’s off. Instead, it would be better to isolate the machine in a non-invasive way, such as blocking traffic at the firewall, so that malware can’t spread to other devices. This is important because it’s at this point that your responders will collect volatile system data, such as memory images, so the actions they take will do as little to upset that state as possible. Once your responders have confirmed that the incident has been contained, the process can move on to the next phase.
Phase 4: Eradicate
The incident cannot progress beyond this point, so it might not be until now that you get much information from your responders. Let your responders work and they can give you a more meaningful update during this phase as the hunt for the root cause begins. The type of incident will dictate how to go about this, but an example would be finding an attacker’s malware implant on a machine, ensuring it’s copied in a forensic image, then restoring the machine to a known good state and tackling whatever vulnerability was exploited (e.g. installing missing patches). The final step in this phase is to conduct a full analysis across all systems to ensure the vulnerability doesn’t exist elsewhere – assume it does, and assume the attacker already knows that.
Phase 5: Recover
Once the hole has been plugged and everything has been returned to a safe state, you’re ready to resume business as usual activities. It’s prudent to continue more stringent monitoring during this phase, rather than standing-down immediately, in case of any repeat events. For instance, a DDoS attack may be a precursor to, or a distraction from, a network intrusion, which you’ll be in a better position to find and eliminate if you’re scrutinising your network logs more than usual.
Phase 6: Follow-up
As much as you might want to wash your hands of the whole ordeal, the follow-up is just as necessary and important as the preparation, as it closes the loop. This is where the documentation and analysis pays dividends, as this phase is all about lessons learned that provide input back into your incident response preparation. Likewise, the documentation should be reviewed, compiled into a formal report, and safely stored as important reference material for any future incidents, or regulatory audits.
Conclusion
Although the phases of an incident response process have only been described at a high level, it still demonstrates that the benefits of having a robust plan in place far outweighs the hardships of getting there, because you can quickly regain control of a potentially dangerous situation. Ever the stoic, I’ll paraphrase Rudyard Kipling: “If you can keep your head when all about you are losing theirs . . . yours is the Earth and everything that’s in it.”
ITC is ready to help; whether it’s knowing where to begin with your incident response plan or responding in the event of a breach – please get in touch.
