The incident response process can be refined through the use of event planning. In this video, you’ll learn about tabletop exercises, simulations, root cause analysis, and more.
Before an actual security event occurs, it’s always a good idea to perform some testing. This gives you a chance to evaluate how well documented your response plans might be. And it also gives you a chance to test your security skill set. If you are planning to perform some type of security incident testing, you want to be sure to do that with test systems. You don’t want to affect any of your production systems while you’re performing these tests.
Another important consideration is you will have a limited amount of time. There are usually others who are involved during these exercises, and they, of course, have other duties to attend to as well. The exercises themselves are designed to test your processes, your procedures, and any of your technical skills. But, of course, it’s always good to sit down after the event is over and evaluate how well you did during that particular test. There might be some processes or procedures that you went through during this exercise that might lead you to make some changes for any future events. And this is why many organizations will get together after the exercise is over to evaluate these processes and see where some changes might need to be made.
At some point, an organization will want to test everything associated with their disaster recovery plan. But running a full-scale disaster event takes time, it takes money, and it takes people away from their primary jobs. There may be times where you might start with a smaller version of this type of drill into something we call a tabletop exercise. Tabletop exercises involve everyone sitting around a table and logistically stepping through the policies and procedures for these security events.
One of the advantages, of course, is that you are all just sitting around a table and discussing what you would do in this scenario. This means you don’t have to go through the process of putting together a full-scale incident drill. But it does allow you to step through your processes and your procedures to see where there might be places you can improve in the future.
This might be something that you can accomplish in just a few hours. You get everyone around the table, and you step through one specific scenario that you can use to evaluate your processes if that was to occur. This means that everyone in the room can talk over what they would do first, what they would do second, and so on. And since everyone in the room is involved with the incident response process, you can, in real time, describe what you would do and then see what the other parts of the organization would do at the same time.
One type of test that occurs quite a bit in actual real-world use is a simulation. A test allows us to perform a simulated attack and to see what the results of that attack might be. For example, you might send phishing emails to the organization and see who might click on them. You might call the help desk and see if someone can change the password for an account or take data and send that data outside of your organization to see if your monitoring systems would catch it.
If you’re part of a larger organization, you might have already been involved in a phishing simulation. This is when the security team will send a phishing email to everyone in the company. It might be requesting somebody to click on a link to update information in your systems or it may be requesting a password change. Obviously, this would be something that you would not want a user to click on inside of their email, and if anyone does click those particular links, you’ll be able to get a report showing exactly who clicked and followed up with the information in that email.
If this phishing simulation is sent by a third party, this also gives you a chance to test your internal systems to see how well it recognizes the phishing attempt and see if your automated filters are able to remove it from your mail system before it ever gets to the users. And if somebody does click on one of those links, you’ll also want to evaluate how your anti-phishing systems occur when somebody tries to visit a phishing site. All of this can now be evaluated after the fact to see where you might want to increase the security of your systems, and you might need to bring in users for additional training for email phishing events.
When a security incident occurs, there are usually a number of different smaller events within that much larger security event. For example, you may have someone that breaches one particular vulnerability in a server. And from there, they begin transferring data, planting other types of malware, and performing other events on your network.
Eventually, you’ll want to know how they originally got into your network or find the root cause. This root cause analysis can give us some insight into processes and procedures that either did not work as expected or we completely neglected a particular part of our security infrastructure. We can usually evaluate log files, look at information that may have been stored on servers by the attacker, and recreate what really happened when that attacker visited the network. This evidence allows us to reconstruct and understand how this person got into the network in the first place.
And in some situations, there are multiple steps or multiple processes the attacker went through to gain access to your systems. So you shouldn’t necessarily look at a single root cause because there may be multiple root causes that allow that user access to your systems. As we’ve already seen with attacks that focus on social engineering, there are times when a user makes a mistake, and that could lead to an attacker gaining access to our systems or our data. The important part is how we address those mistakes and find corrections for them to prevent any future attacks.
One way to prevent an attacker from taking advantage of a vulnerability is to find that vulnerability first. We do this through the process of threat hunting. This might involve us making changes to a firewall rule. Maybe we’re tracking the types of vulnerabilities that were announced in the last few days. And we’re also checking the systems that we have already installed to make sure that they are up to date with the latest patches.
The challenge, of course, is that it’s difficult to identify an attack until the attack is actually occurring. And of course, we would like to prevent this attack from occurring in the first place. So it’s useful to monitor our existing systems and make sure that everything is up to date.
There are also a remarkable number of monitoring tools and automated systems that can identify certain types of attacks and stop them before they gain access to your systems. Having that type of automation can help you prevent an attack from occurring even when you’re not actively watching for it to occur.