In 2019, incidents are inevitable. However, you can dramatically increase the speed and success of your incident response capability if you ensure you have covered these five areas.
In this article, I’ve used the metaphor of a bank robbery to help explain some of the key actions you can take to improve your incident response outcomes.
#1 Log Forwarding
Imagine a bank robbery. Your network is the bank, the robbers are the cyber criminals. It’s common practice for robbers to destroy the cameras while simultaneously robbing the bank. This is the same for cyber criminals, who will regularly clear logs to hide their tracks.
If logs aren't forwarded to a SIEM or elsewhere, it's easy enough for an attacker to simply clear those logs, which means when the Incident Responders arrive to investigate, there are no logs to look through and analyse.
Without logs, incident responders are blind. The footage is gone, the evidence is gone, making it very timely to discover what actions were taken by the attacker, and time is of the essence during incident response. Ensure you are forwarding logs to a SIEM.
#2 Log Retention
Imagine that the bank robbery happened two days ago, and you only retain logs for 24 hours. Again, it's like our previous point where we don’t have the logs to investigate. You need to retain logs for as long as possible, and at least until you can bring in incident responders. We often see clients take too long to bring in third-party assistance. There may have been enough retention in the logs, but now that's gone.
Best practice is to retain logs for 18months.
#3: Preservation of Evidence
If we look at this in our bank robbery analogy, imagine the police are being brought in to try and solve the crime. They don't have any evidence sources. The footage is gone, because the logs aren't forwarded, or the retention was not long enough. There are also no witnesses, but let's say there were fingerprints (memory) that investigators could have used, however now they’ve been smudged because they weren’t preserved, or worse, they've tampered with it.
When it comes to cyber breaches, this tampering often is not intentional, yet it does happen. For example, an IT team who has just discovered a breach may try to take steps to remediate or determine what has occurred on the network. This will alter what is available in memory and on disk, which is essentially tampering with available evidence.
Memory is volatile. To gather as much information as possible, we need to act immediately after a breach. Or if that memory is preserved, then we're able to obtain all that is available.
Imagine in our bank robbery analogy that the cameras are not recording the right areas. There are some hallways that aren’t covered. The entrance is covered, but the safe, and another entrance aren't. So we don't have complete visibility of what actions took place, which can be the same with your network.
When it comes to visibility, there's also an element of time synchronization. For example, if we went to look at the evidence, and we gathered all logs from 8:00 am to 9:00 am, when the robbers were in the bank. The logs weren't timed correctly, which means the footage wasn't being timed correctly. So, you've pulled the wrong logs, and cannot accurately investigate.
It sounds simple to fix in this case, but in real world incidents it can be quite difficult. If time synchronization is not correct, then your incident response could turn from a two day engagement to a two week engagement.
By default, a certain amount of auditing is enabled on various machines, but a greater level can be enabled that would provide more visibility of actions that have taken place. For example, imagine that in our analogy infrared isn't being used on the cameras within the bank. This means if there is an area where the lights are off, or the robber’s have entered at night, we can't see what they're doing!
This functionality can be used for alerting as well. Let's say at a certain time at night there shouldn't be anybody in the safe. There's motion sensing enabled, with infrared. Somebody’s enters the safe, you get an alert and can react to it.
This enables incident response. Up until now we've been looking at the forensic side, determining what has happened in the past. The more forensic data we have available, to know more about the attackers and what they’ve done, enables us to determine what to do to mitigate the threat.
Let's say the bank robbers are in a big bank attached to a hotel above, and they’re on the run. We're not sure what floor. We're not sure of the room number. We’re not sure if they have hostages. Bottom line, more intel is needed.
Investigating the forensics will help us gather that information. All that information will help us understand how to best respond to the attackers.
Where do I start?
Many businesses we speak with are still in the mindset of prevention and haven't gone into detection and response yet. Often these clients will be looking to do a penetration test, ensuring they’ve patched all vulnerabilities. But, what about the other way’s attackers get into your network?
A great place to start is to ensure you have the detection and response mechanisms available to effectively deal with a breach. At Content Security, we have a pen test response service to do exactly that.
Most penetration testers are not quiet on the network. Which means there is a tonne of events that can be looked at from a forensic perspective. If you engage incident responders to conduct a penetration test response during, or at the end of a penetration test, they can see if you have visibility of those events occurring, and if not, then they can tell you why not. Can they be remediated? Were able to detect the penetration test, were you able to respond to it? Why not? It's a great, risk-free way to simulate an actual attack.
5 actions you can take to improve your Incident Response: