5 steps to take if your business gets hacked

Whether you’re a small business or a multinational conglomerate, the threat of a cyber attack is potentially ruinous. How you navigate through a hacking incident at your business can be the difference between a speedy recovery and months of legal action, a damaged reputation, and angry customers.

To that end, I’m going to go over some of the key actions you need to take as a stakeholder when responding to a cyber attack.

1. Accept that your normal work day is over

It’s 4pm and you’re wrapping up the day sending out emails, when you notice something suspicious. Maybe it's a ransomware popup or a phishing email from another internal email address. Your stomach drops. You think your company’s been hacked.

It may feel like the world’s ending, but here’s the first rule of thumb: don’t panic. Yes, time is of the essence, but making decisions without thinking them through really won’t help. Take a moment to gather yourself, put the coffee-maker on, and start thinking about how you’re going to take back control of the situation while it’s brewing. Making a knee-jerk reaction could have huge repercussions later on down the line, so it's crucial to take a moment.

How you proceed from there depends massively on how the incident is unfolding. If you think you’ve discovered evidence of an attacker while they’re trying to remain hidden, then you need to notify your incident response team so they can begin investigating, collecting evidence, and formulating a response. If you don't have an incident response plan, check out tip #6.

It’s important to remember that if a hacking group has infiltrated your systems, they could potentially have access to or even taken over your communication systems. It’s not unheard of for intruders to sit on systems for a prolonged amount of time and monitor emails sent to internal security teams for keywords that relate to an intrusion alert.

So, the clock is ticking, but you don’t want to blow the element of surprise. Your organization should have outlined an out-of-band communication method to raise alerts that isn’t susceptible to monitoring and is resilient even in the face of a total network outage. Not only is this essential for quietly informing the security team that you think something is wrong, but it’s also vital for continuing to coordinate a response if you have to use the nuclear option and completely shut down your network.

It’s a little different if there’s a pop-up on your desktop demanding money or your files are going to be encrypted. In this situation, the attackers know that you know they’re in your network. They’ve made all the necessary preparations to launch their attack, and now time is really not on your side.

However, even in this situation, you need to take a second. Ransomware attackers often use time pressure tactics to get you to pay the ransom, but their deadlines are often measured in hours or days, not minutes. A big ticking clock counting down to doom is as much a method of psychological warfare as it is a deadline you’re working against. Especially if you’re in a position to make executive decisions, you need to calm down and not make the first move that comes into your head. Do whatever you can to mentally regain control of the situation, acknowledge that what has happened previously cannot be changed, and focus on the task of remediation ahead.

Also, start a timer from the moment you report to your incident response team. I’ll talk more about why that’s necessary in tip #4.

2. Activate your Incident Response Plan

After you’ve taken a moment to clear your head, you need to get to work. Every organization should have a robust incident response plan in place to guide its actions in the event of a cybersecurity breach.

As soon as a breach is detected, you need to begin activating your incident response plan (IRP). This plan should outline the roles and responsibilities of key personnel, the steps to contain the breach, protocols for communication both internally and externally, and procedures for post-incident analysis and recovery.

The value of the IRP is that it’s well-researched, practiced, and easy to follow. Making decisions while under fire is difficult, so the IRP works as a reference for decisions that were made with a clear head and with the time necessary to carry out detailed research. You should not be writing or rewriting your IRP in the middle of a crisis. Ideally, you should have already held practice incidents that involve the various stakeholders around the business that will need to work together during an incident.

A hacking attack isn’t just a problem for security, or even IT as a whole: It requires actions from the executive team, from HR, from Legal, and from stakeholders responsible for internal and outbound communications.

As such, one of the key functions of the IRP is to dictate how talent is assigned from within the business to the incident response teams. Not everyone who is useful in an incident will work inside the IT security sector of your business, but IT engineers may be brought on to help identify anomalies within their areas of expertise according to the type of threat you’re facing. The success of all further actions will directly correspond to how well your organization identifies the scope of the breach.

If you’re dealing with ransomware, the hacking group you’re dealing will have taken several different steps in order to deploy this attack across your network. You need to start working backwards, figuring out how they compromised your system and pushed their malware across your network, and so on. It’s a similar task if it’s a silent attack, but you might have less to go on—perhaps it’s just a few phishing emails flagged by someone in HR, or some suspicious traffic being sent out of the network.

Something vital to take into account is that you’re now essentially working in a crime scene. How you preserve evidence may be vital for establishing a chain of custody down the line. As such, never work on any live systems until you’re ready to start rolling back.

3. Engage with external stakeholders

You may not have the internal capacity to carry out every task outlined in your IRP. Some employees might be on holiday, others might not have the technical skill needed, and some issues may simply have not been identified when setting up your IRP. It’s unfortunate, but it happens.

You shouldn’t be scared of reaching out to individuals and organizations outside your business (with the right NDAs in place, of course) to fill any gaps you may have operationally during a crisis. You want to execute with as little downtime as possible.

For example, if you’re deciding to shut your network down to avoid further access to personally identifiable information (PII) by an attacker, you don’t want your networking team trying to find out how to do that in real time. Reaching out to your vendors for emergency support and advice can drastically cut down the time you’re spending carrying out technical tasks which will allow your team to focus on the core actions needed for discovery and recovery.

This is particularly vital as their expertise can save you a whole load of money. Not all ransomware gangs use bespoke software developed inhouse to carry out their attacks. Some rely on publicly available software with known flaws, and it may very well be that the solution to your problem is available on the Internet for free, saving you millions of dollars in ransom.

Again, you don’t want to spend the time looking into this. You want to offload the task onto an external cybersecurity team that has proven experience dealing with crypto hacks so that you can get back to handling the other stuff.

You also want a third party like your insurance company to handle your communications with the ransomware group for several reasons. First up: even if you wanted to, how are you going to come up with millions of pounds of Bitcoin (or, god forbid, Monero) on a whim? Most coin exchanges require several days to clear the requirements related to onboarding a new client, and this can take even longer if you’re registering as a business. Then there’s the issue of daily exchange limits, coin exchange fees, and so on. It’s not something you can make happen on the spot. However, if you choose to pay the ransom, your insurer will already have procedures in place to enable the exchange.

Secondly, your insurer will have experience dealing with crypto-criminals. Even if you don’t intend to pay, you can find out valuable information from interrogating the hacker gang. You might ask for a third party to ask for details of files the gang is extorting for proof they actually have the data they claim they’re going to release. Once you’ve confirmed the files are in their possession, your security team can correlate the files to a particular server and start working out how the hackers got in.

4. Notify your customers appropriately

Some jurisdictions require you to report to a government body or independent watchdog within a certain amount of time if you discover a data breach. The criteria and timeframe depends on the jurisdiction in question, but in the case of the UK, adoption of GDPR means you need to report to the Information Commissioner’s Office (ICO) within 72 hours of the moment you discover a breach. There’s a lot of nuance to this, however, as well as some leeway in terms of what you have to report and to who.

It’s not 72 hours from the moment you find out a hacker is on your system—the investigation needs to progress to the point where you’re confident that personal information on living clients has been accessed by a hacker outside of the company. At this point, regardless of your subsequent decisions on disclosure, you need to log the scope of the breach internally. You then need to assess whether or not the data breach could pose a risk to the individuals affected.

If so, the clock is really ticking: by the end of the 72 hour period the ICO must have been made aware of the breach. If not, you need to document your reasoning for not reporting it to the ICO in case an investigation requires it down the line. You must also be able to reassess this decision and, if you find the circumstances have changed, the clock begins ticking again.

A disclosure to the ICO should not materially impact the progression of your internal investigation, so you should report as soon as you’re sure of the impact of a breach. Even in a case where you’re unsure, it’s better to make an unnecessary disclosure than not make a necessary one.

The trickier question is when and how you disclose to your customers that their data may have been accessed. The metric the ICO uses for disclosure is whether the breach represents a “high risk” to rights and freedoms of individuals involved with the breach. If you assess that the breach passes the bar, you’re compelled to inform them without “undue delay”.

Again, there is some leeway here. You need to recognise that even if your first instinct is full disclosure to those involved so they can take actions to protect themselves, you are in the middle of an active investigation. If the hackers you’re working against are still unaware you’ve caught them in the middle of a breach, informing those involved can quickly lead to a full-blown news story that will tip them off. In turn, this could lead to them taking actions which may not only affect the confidentiality of the affected data, but also the integrity and availability of the data.

Put simply, the hackers involved may decide to go scorched earth as soon as they’ve been discovered and start encrypting or deleting entire data stores on the way out. There’s a legitimate argument to be made for delaying the disclosure to those involved.

This argument is much less likely to work on the ICO if you’re the victim of a ransomware attack. In this case, there’s no advantage to not informing those involved as quickly as possible, especially if there’s a threat to release the data publically. In this case, you’ll want to quickly and quietly contact those involved directly to explain the extent of the breach, as well as to take the necessary measures such changing their passwords and being vigilant against spear phishing attempts.

5. Evaluate your actions

You may need to simply shut your internal network down until your investigators can work out when the breach took place. Although this is the nuclear option, allowing your internal IT systems to stay up while a breach is actively taking place may be worse. It’s not as simple as rolling back to backup images made a week before the breach.

Until the investigation is complete, you have absolutely no idea how long the hackers actually spent inside your systems. They may have spent months preparing for this attack, so rolling back may simply give them the access needed to try again with some extra surprises.

To give yourself the breathing room to work out when the first breach occurred, it may simply be the best of a set of bad options to shut down your network in the meantime. You’ll need to make this case to business stakeholders on the response team, which can be pretty painful if it means a reduction in revenue.

You also need to consult with your IT responders and forensics experts to ensure that you aren’t losing any vital evidence by cutting network access. Real-time traffic analysis may allow you to identify which servers are compromised by identifying unusually large data transfers or odd traffic signatures, which are lost if the network loses connectivity.

When the investigation is completed and the forensic responders are sure they’ve identified all the points of ingress, it’s time to identify the technologies that enabled the hack and either patch, uninstall, block ports, or decommission.

Once you’re on the other side of an incident, documentation is key. Not just in terms of what the hackers affected, or how the compromise worked, but how the company as a whole performed. What went well? What was slow? Did the lines of communication work effectively? Did the external stakeholders perform within your expectations? Was any individual or team saddled with too much responsibility? Did anyone burn out?

Identifying these issues within a week or two of the incident will allow you to capture the nuance of the incident in detail and alter your IRP according to what went well and what must be done better.

6. What if I don't have an incident response plan?

If you’re not currently in a cyber attack scenario, great! You should use some of the tips here to start drafting your Incident Response Plan and assigning or hiring team members to perform incident response roles.

If you are currently in a cyber attack scenario, you should let whoever is in charge of liaising with external vendors that they need to contact a cybersecurity company that specializes in incident response, ideally through an encrypted channel of communication such as WhatsApp or Signal. Go, now!

A cybersecurity breach is pure stress. It can have far-reaching implications for your company, but a swift and coordinated response can help mitigate the damage and facilitate recovery.

You can effectively navigate the challenges posed by a cyber attack if you just remember these key points when you’re dealing with one. Unfortunately, a lot of this advice boils down to “Be prepared ahead of time”.

That’s the reality of dealing with a cyber attack: preparedness is safeguarding your company's digital assets and reputation in today's cyber threat landscape.