Incident Detection and Response Threat Simulation

We talked about communications and coordination. Both of these things are very important when it comes to legal requirements, policy requirements, regulatory requirements. You're going to want to make sure that you understand what those communication needs are and how to coordinate the resources during the incident response process. Last but not least, you're going to want to consider who else needs to be part of that incident response team. Perhaps you need your general counsel. Perhaps you need your HR team. Perhaps you need outside representation or outside help from a technical perspective. All things that you need to consider as part of preparing for your incident response program.

As we closed out last week's Whiteboard Wednesday, we talked about rehearsal. This week, we're going to expand on that a little bit. The first thing that you're going to want to do as part of your rehearsal now that your IR team structure has been put in place, you're going to want to define the threat scenario. In order for this activity to be as real as possible and as impactful as possible, you're going to want to define a threat scenario that is realistic for your environment and certainly realistic for the capabilities of your team. For example, if you have a team of small incident responders, perhaps some threat detection analysts, you're not going to want to do a full scale breach and theft of data. That is probably too much for your team to handle. On the flip side, if you have a very, very mature team, you're not going to want your threat response scenario to be a malware outbreak. That's going to be a poor use of these people's time.

Once you've defined the threat scenario, you're going to want to do the exercise walk through. This is where you bring everybody to the table, and you're going to do a threat simulation exercise in a very, very safe environment. You're going to want to break down the threat scenario into steps. Most of the time, you're going to talk about initial infection vector first. Was it spear phishing? Was it a vulnerability exploit? Was it lateral movement from a partner? Once you've defined that initial infection vector, you're going to want to identify where your technology or where your people are going to start identifying that threat.

That is the beginning of the exercise. You're going to want to solicit input from the people who are responsible for monitoring that technology for the alerts that they're going to be seeing and the data contained within those alerts. As an example, your antivirus solution or your endpoint threat detection solution might identify attacker activity on an endpoint. Part of that attacker activity is going to include network information. Your endpoint engineer is going to need to communicate with your network engineer such that the network team is aware of what's going on on the endpoint from a network perspective.

After the initial infection vector, you're going to want to focus on lateral movement. How is the attacker moving around your network? Are they leveraging advanced techniques like pass the hash, or are they using more basic techniques like using the Windows task scheduler to launch remote jobs? That is also a point at which you're going to want to engage your technical staff to give you feedback on the information they're going to see as part of those activities. If you have a very mature team, chances are good they're going to know exactly what to look for and exactly the evidence they're going to uncover. If it's a rather immature incident response team, perhaps they haven't had exposure to these techniques. At that point, you may want to bring an outside entity in to help you navigate those waters, to help them understand the evidence that they're going to be looking at and the data that's going to come out of those particular pieces of evidence.

Once you've established a movement pattern for the attacker, you're going to want to stage a data theft. Again, this is going to be the most important data in your environment. If you're a financial services firm, perhaps that's credit card data that you're processing for your customers. If you are a manufacturing firm, perhaps that is schematics or designs for the widgets that you're creating. Make sure that the data that the attackers are after is the most valuable data that you have in your environment. That'll make this exercise that much more realistic. In this particular piece of the threat scenario, you're going to want to make sure that you have the ability to detect unauthorized access to this data. There are lots of tools out there that are available, and we'll talk about that during a future Whiteboard Wednesday.

Once the attackers have identified their data, they're typically going to want to package it up and exfiltrate it. There are lots of different techniques to do that. The purpose here is for the network team to identify large volumes of data that are escaping the network either through a trickle, meaning small packets over a long period of time, or as large blasts, a big data transfer outside of your network.

After the exercise has completed, you're going to want to circle up and do lessons learned. There are a number of different ways to do that. If you have engaged an outside team to help you with this threat simulation exercise, that should be part of their deliverable. They have evaluated everything that's gone on during the table top exercise and they will help you identify areas for improvement. If this is something that you were doing internally, you can solicit feedback from the people who were involved in this exercise. They will be best placed to know if they had the right tools, the right amount of communication, and the right level of coordination to do what they want. Specifically, the lessons learned that you're going to want to derive from this is your effectiveness and your effectiveness specifically in threat detection, investigation, and communication.

Thanks for watching this week's Whiteboard Wednesday. Tune in next week.