One of the more exciting experiences I’ve been involved in recently is being the technical point of contact for simulating attacks and breaches on the SOC team. This has some major benefits to us as a team, and as a business, and is something that both sides get to enjoy.
- Management get peace of mind that we have a broad plan for when an attack of that type happens and that we are capable of responding appropriate and in a timely manner.
- We get to discover gaps in processes, visibility and capability.
- We get to test our skills and ensure that when the time comes, we don’t suffer analysis paralysis.
These simulated attack scenarios get set up to mimic our corporate setup as much as possible, with some liberty taken depending on the objective. For example, worried the team are too reliant on a certain tool? Take it away from them.
We’ve simulated a variety of different attack techniques, allowing us to go back to vendors and other areas of the business with questions around why techniques were not detected, how we can detect them and what additional visibility we need. These simulations have included:
- APT based threats
- Supply chain attacks
- Malware outbreaks
- Vulnerability exploitation
And they involve all areas of the business. And allow us to find out:
- How we interact with other teams?
- How do the SOC team/CSIRT/Crisis management respond?
- Do we know what our roles are?
- Do we all know how to use the tools provided to us? Or even what tools we have access to?
- Are we prepared to make that hard call when the business needs us to? We lost everything in under an hour, so when you only have minutes to make a call, would you do it?
All of these are important questions for any team responding to a security incident, so ensuring that we train for the day, especially as cyber threats continue to increase, is now more important than ever.
So, what does it take to do this?
A lot of patience and determination. 🙂
When we started, these were tabletop exercises. Paper or email based injects; tabletop exercises. The problem here is you know they are not real. There’s no alerts on your tools, or even evidence on devices of it occurring. There’s nothing for you to investigate, nothing to really respond to. If your team is full of technical people, which it likely is, for a lot of them this isn’t fun, and even more so it doesn’t provide you with real information on your current situation.
So we decided it was time to change that. Every exercise we build new VM’s that match our naming structure, that are connected to a domain with identical naming conventions to our own, IP address mapping, our security tooling. When possible, you can even connect to them from our network. if your analyst can ping that device, something that small makes a huge difference for their perception of it. We use real malware, actually exploit vulnerabilities, after all we want them to respond how they really would.
In some cases, we just use real devices. We get vendors involved to help. Now only does this assist with building relationships, but it moves that realism one step further, as now everything is real. As we grow on this, hopefully customers too so security isn’t seen as something that just takes x% of your revenue, but actually wins you contracts. Most recently we simulated a supply chain attack. A vendor was a victim of an attack recently, so we used that scenario to simulate a supply chain attack. We implied credentials to our system were stolen, and with their help we had accounts they actually have in our estate used to login to systems from an IP address behind a VPN. New MFA options added to accounts, data exported from databases and uploaded to servers that we control, but for the SOC team would have just been another server on the internet and scripts to find passwords in config files. It was the most realistic simulation we’ve done to date, because it was real. Nothing got fabricated for this, so much so that we had upper management ask us to tell people it was an exercise so that we didn’t end up in a situation where it gets misunderstood by someone not directly involved, and the next thing you have is a news article on Maersk being attack, again.
This is something every incident response team should work on implementing, and a capability they all need to have.