It is getting better and better that modern security tools can protect companies’ networks and endpoints from hackers. But sometimes, bad people still find a way in.
Security teams need to be able to stop risks and get things back to normal as soon as possible. That’s why it’s so important for these teams to have the right tools and know how to handle an emergency well. You can use resources like an incident response template to make a plan with methods, jobs, responsibilities, and a list of things you need to do.
But that’s not the end of the planning. Teams must always learn to be able to change with the times as threats change quickly. Every security incident should be a chance to learn something to help the company prepare for or even stop future incidents.
SANS Institute defines a framework with six steps to a successful IR.
- Preparation
- Identification
- Containment
- Eradication
- Recovery
- Lessons learned
It makes sense that these steps go in a certain order, but you might have to go back to an earlier step to do something again because you missed it the first time.
The Incident Response does move more slowly now. But it’s more important to do each step right than to try to save time by skipping steps.
1. Preparation:
Goal: Get your team ready to handle events efficiently and effectively.
Not just the incident response team but everyone who can access your systems needs to be ready for an event. Most computer breaches happen because of mistakes made by people. In IR, the first and most important step is to teach people what to look for. To make sure everyone works together well, use a templated incident response plans to spell out everyone’s jobs and duties. This includes executives, security leaders, operations managers, help desk teams, identity and access managers, audit, compliance, communications, and identity and access managers.
Attackers will keep improving their spear phishing and social engineering methods to try to stay ahead of efforts to teach people about these threats. Most people now know to ignore a badly written email that offers a prize in exchange for a small down payment. However, some people will still respond to an off-hours text message claiming to be their boss and needing help with an important job. Because of these changes, your internal training needs to be updated often to include the newest methods and trends.
Your incident response, or security operations center (SOC), if you have one, will also need regular training, which should ideally be based on fake events. An intense board exercise can get your team’s blood going and make them feel like they’re in a real-life situation. You may find that some team members do their best when things get tough and others need more help and training.
Outlining a specific reaction plan is another part of getting ready. The most usual method is to limit and get rid of the problem. You could also watch an event happen so you can judge the attacker’s actions and figure out what they want, as long as this doesn’t cause permanent damage.
Technology is a very important part of incident reaction, even more so than training and plan. Logs are an important part. To put it simply, the more you log, the faster and easier it will be for the IR team to look into an event.
You can also quickly protect yourself by separating machines, cutting them off from the network, and running counteracting commands at scale if you use an endpoint detection and response (EDR) platform or an extended detection and response (XDR) tool with centralized control.
For IR, you also need a virtual setting where you can look at logs, files, and other data and a lot of space to store this data. You do not want to waste time during an event setting up files and virtual machines.
Lastly, you’ll need a way to record what you learned from an event. This could be a notebook or a tool made just for that purpose. Your records should include when the incident happened, what systems and users were affected, and what harmful files and Indicators of compromise (IOC) you found, both at the time and afterward.
2. Identification:
Goal: Detect whether you have been breached and collect IOCs.
There are a few ways you can identify that an incident has occurred or is currently in progress.
- Internal detection: an incident can be discovered by your in-house monitoring team or by another member of your org (thanks to your security awareness efforts), via alerts from one or more of your security products, or during a proactive threat hunting exercise.
- External detection: a third-party consultant or managed service provider can detect incidents on your behalf, using incident response tools or threat hunting techniques. Or a business partner may see anomalous behavior that indicates a potential incident.
- Exfiltrated data disclosed: the worst-case scenario is to learn that an incident has occurred only after discovering that data has been exfiltrated from your environment and posted to internet or darknet sites. The implications are even worse if such data includes sensitive customer information and the news leaks to the press before you have time to prepare a coordinated public response.
When we talk about identity, we can’t leave out the topic of alert tiredness.
If you set your security products’ detection levels too high, you will get too many alerts about actions on your endpoints and network that aren’t important. That will really bother your team, and a lot of alerts might not get read.
If your choices are too low, on the other hand, you might miss important events like the first case. A healthy security stance will give you just the right number of alerts to help you find problems that need more research without getting tired of them. Your security providers can help you find the right mix, and the best system would filter alerts automatically so your team can focus on what’s important. During the identification phase, you will write down all the signs of compromise (IOCs) you find in the reports. These could be hosts and users that have been hacked, malicious files and processes, new registry keys, and more.
The control step will begin once all IOCs have been written down.
3. Containment:
Goal: Minimize the damage.
As much as it is a step in Incident Response, containment is also a tactic.
You should devise a plan that works for your company, considering both protection and business issues. Isolating devices or cutting them off from the network might stop an attack from growing through the company, but it could also cost a lot of money or have other negative effects on the business. You should make these choices and spell them out clearly in your IR plan.
There are both short-term and long-term steps that makeup containment, and each has its effects.
Short-term: These are actions you could take right now, like turning off systems and gadgets that are connected to the network and watching what the dangerous actor does. Each of these steps has pros and cons.
Long-term: The best thing to do is to keep the infected machine offline until the eradication process is over. But sometimes this isn’t possible, so you might have to do things like fixing, changing passwords, stopping certain services, and more.
You should first check your most important devices, like domain managers, file servers, and backup servers, during the containment process to ensure they haven’t been hacked.
In this phase, there are steps like writing down which assets and risks were contained during the event and putting devices into groups based on whether they were hacked. If you’re not sure, think the worst will happen. This part is over once all the devices have been put into groups that meet your meaning of containment.
4. Eradication:
Goal: Make sure the threat is completely removed.
Once the containment part is over, you can move on to eradication, which can be done by cleaning the disk, recovering from a clean backup, or reimaging the whole disk. Cleaning means getting rid of harmful files and changing or deleting registry keys. Reimaging means putting the operating system back on the computer.
The IR team will want to look at company rules before doing anything. For example, if there is a malware attack, certain machines will need to be reimaged.
Documentation is an important removal part, just like it was in earlier steps. The IR team should carefully write down what they did on each machine to ensure they didn’t miss anything. You can do active scans of your systems for any signs of the threat as an extra check after the removal process is done.
5. Recovery:
Goal: Get back to the Normal Operations.
Everything you’ve done has led you here! During the healing phase, things can go back to normal. At this point, the most important choice is when to start activities again. This should happen immediately, but you might have to wait until your company’s off-hours or some other quiet time.
Just one more check to ensure that the recovered systems don’t still have any IOCs. You must also check to see if the root cause is still there and make the necessary repairs.
For future reference, you can keep an eye out for this kind of event and set up safety measures now that you know about it.
6. Lessons learned:
Goal: Document what happened and improve your capabilities.
Now that the incident is comfortably behind you, it’s time to reflect on each major Incident Responses step and answer key questions; there are plenty of questions and aspects that should be asked and reviewed; below are a few examples:
- Identification: How long did it take to detect the incident after the initial compromise occurred?
- Containment: How long did it take to contain the incident?
- Eradication: After eradication, did you still find any signs of malware or compromise?
Probing these will help you step back and reconsider fundamental questions like: Do we have the right tools? Is our staff appropriately trained to respond to incidents?
Then the cycle returns to preparation, where you can make necessary improvements like updating your incident response plans template, technology, and processes and providing your people with better training.
4 Pro Tips to Stay Secure
Last but not least, here are four more things to think about:
- Keeping more logs will make it easier to look into things. To save time and money, make sure you log as much as you can.
- Prepare for attacks on your network by modeling them. This will show how your SOC team looks at reports and how well they can talk to each other, which is very important during a real event.
- People are an important part of your organization’s protection. Do you know that 95% of cyberattacks are made by people going wrong? Because of this, it’s important to train both end users and your security team regularly.
- You might want to keep a special third-party internal investigation team on call so they can help immediately with more difficult cases that your team might not be able to handle. These teams may have dealt with hundreds of events, so they will have the IR knowledge and tools you need to get started immediately and speed up your IR.
You can download a free incident response template here.
