Leaders have worried about cybersecurity for some years now, and we have seen that spending on cybersecurity technology as well as consulting has trended upwards for a while. Yet, far too few companies actually have a plan for what to do when they get hacked. That is a when not an if. This post gives you a quick rundown on some of the basics you should think of in terms of incident response. Our primary goal is to maintain or reestablish service delivery to minimize business impact.

You need to practice before you can perform: you need to practice getting hacked.

Preparation


Let our advance worrying become advance thinking and planning.

Winston Churchill

At some point your company will be hacked. The outcome of that depends on the actions you take when it happens – and those actions depend a lot on what you have planned and prepared for. This first chapter is thus what you should do before you get hacked.

Here are some key aspects of good preparation:

  • Think through the scenarios: create a threat model for your business. Who are the adversaries and what are their expected attack patterns? What would the outcomes be in terms of financial impact, reputation or legal situation? Cybehave’s RiskTool can greatly help with this.
  • Plan to detect incidents. How can you discover that you have been hacked? Plan monitoring and checks intended to discover what is going on. This means: keep logs and monitor them. Train users to report unusual events – both in the digital domain and the physical world.
  • Make your systems recoverable. Make sure user accounts can be recovered, make sure backups exist.
  • Keep essential information available: who to call, network maps, documentation. Procedures, plans. Plan for your entire IT system to be down, and your normal backups to be compromised. Some things should be kept on paper.
  • Make sure you have someone who is responsible for responding to incidents and give them the necessary resources to prepare and practice in terms of money, time and attention.

You are preparing in order to be able to do the actions required under the next 5 phases of incident response.

The key phases of incident response: planning what you should do when getting hacked according to this model will significantly help you recover faster, cheaper and with more confidence.

Identification

This section is about understanding that you have been hacked. It is thus something you should do all them time, both when everything looks normal and when you have been hacked. You don’t know before you know.

This is what you need to do to know that you have been hacked. You should systematically monitor systems and have people who are responsible for following up on potential incidents. Automate signals extraction if you can – like creating alerts on too many wrong login attempts. Here’s a bullet point least of essentials:

  • Plan for identifying scenarios from your threat model. Make sure you have the right logs in place.
  • Make sure you can correlate events: synchronize logs and preferably gather them in a central and protected location. There are good cloud solutions too for this.
  • Have a procedure for incident classification: gather evidence, review, look for natural explanations, look at follow-on events, classify as false-positive, or escalate to incident response if required.
  • Make sure your detection methods are protected so a hacker cannot easily turn them off.

Containment

This should be a high priority when you have been hacked!

A compromise of your information systems is bad – and you don’t want it to spread. Many cyber attacks start with one system being breached, and then the attacker moves laterally in the network. Or one computer is infected with a virus – and then it spreads to the entire network. The containment phase is about stopping this.

Most businesses can’t just disconnect form the internet and “pull cables” to stop the spread of the compromise. The containment actions should follow a prepared plan that takes short and long term business impact into account. To do this properly, again, you need that threat model.

Typical containment actions would include:

  • Moving infected machines to its own VLAN/subnet and stop all network communication with the rest of the network
  • Removing integrations with accounts to avoid further account takeover (e.g. if you have lots of services integrated with yout Gmail account)
  • You may want to keep internet access available for a while to monitor potential Command and Control traffic from malware.
  • If hit with malware, try to understand what the malware can do before disrupting it. Could it turn destructive and for example delete all systems if disconnected form the internet? You may need to get a sample of the malware to do malware analysis on it, if your firm has access to such capabilities.
  • Make forensic copies of disks for further analysis.

The key for most companies should be to minimize the impact to the business – not to maintain a chain of custody for use of digital evidence in court. Delaying response may lead to greater damage, and these trade-offs must be taken into account when making decisions about containment actions to take. To avoid “analysis paralysis” it makes sense to define som decision criteria here and have people with authority to make such decision available.

Business containment

Don’t forget your business incident containment. During incident handling it is easy to only think about technical assets such as computers and networks -but relationships are equally important.

  1. Who do you need to inform?
  2. Do you have a communications plan?
  3. Do you need a media strategy?
  4. Do you need to involve the authorities?
  5. Can you get assistance from third-parties (service providers, suppliers, customers)?

Eradication

Most people who have been hacked start thinking about eradication – but only those who have prepared, identified and contained the threat will be able to!

When you understand the incident to some degree and you have it contained, it is about time to start eradication: throwing the adversary out. There are two things you should make sure of:

  • The attacker has been eradicated from the systems contained. Restoring from a clean backup, or from source, is the way to go. If you want to make sure, start with a formatted disk (or new cloud resources).
  • You should stop the attacker form getting back in. Patch everything – leave no known vulnerabilities. If you run custom software written by your organization, consider a penetration test, or at least a vulnerability scan as part of the restoration process.

Recovery

Recovery is getting back to normal. This is in most cases best done gradually in order to isolate any reinfections.

  • Test your backups and your restore media. Make sure they are not compromised before you recover the system!
  • Recover user accounts and document recovery.
  • Recover the system in a disconnected test environment if you can. You may want to allow read access to data from other systems but no write access yet.
  • As you bring the systems back into production monitor closely for reinfections. Sometimes systems are compromised again repeatedly without any obvious vulnerabilities. Are zero-days or insider threats credibly in your case?

Recovery should be measured. This makes it possible to quantify the ability of your team to respond – in training as well as in real incidents. Define desired recovery time objectives (RTO) – the time needed from detection to recovery of the service and measure your organization’s performance.

Lessons learned

Time to improve – when you have done the actions required after getting hacked in order to get back to delivering business services – you need to create an after action reivew, a post mortem, a lessons learned report. Your ability to respond to incidents depends on continuous improvement. Preferabily within 24 hours of recovery, gather the team and get their input on the taks that were done. Note down what you need to change for each of the phases to be better the next time.

  • What did you learn about threat actors and their methods? Should you update your threat model (RiskTool) to capture this new knowledge? What are likely developments in future attacks based on what you have seen here?
  • Did you have the appropriate resources to respond to the incident?
  • Do you need new detection abilities to identify future incidents? How did you discover this incident? Are you confident that you would identify it quickly if it were to reoccur in a week?
  • Did the containment work? If not, what was overlooked? Why?
  • Were you able eradicate the threat on first attempt? Did you need to patch many vulnerabilities before recovery? Why? Does this mean your patch management should be improved?
  • During recovery, did you have any problems? Did backups work? Did you get reinfected and why?
  • Who should be notified of lessons learned? Do some of the things discussed have implications for others, such as senior managers, IT help staff, sales team?

Create a short lessons learned report – share internally whit the team and requires stakeholders.

Key take-aways

  1. Prepare for the worst to happen. Create a plan. Have a playbook.
  2. Don’t forget keeping required stakeholders in the loop. Plan your communication as diligently as you plan your recovery.
  3. Practice in peacetime so that you can act in the face of aggression.

Leave a Reply