Most of the hard work related to security incidents happens before an event occurs. In this video, you’ll learn about tabletop exercises, walkthroughs, simulations, communication plans, and more.
Usually when we talk about security incidents, it’s usually after the fact, when one has already occurred. But much of your work is going to be done well before an incident ever occurs in your environment. And there are a number of things you can do prior to an incident occurring that can help you with the planning process.
The first step is going to be performing exercises. It’s going to be testing yourself, and everyone in your organization, on what they would do if an incident occurs. These can be scheduled, so you might have them once a year, or twice a year, or even more, so that everybody becomes accustomed to what they would do during an incident.
We want to be very careful that when we’re performing these exercises that we’re not affecting anything related to our production networks. Although this incident is probably something that would affect our production network, we want to be sure that we don’t touch anything with our production network during these exercises.
Some security events could take weeks, or even months, to resolve. But when you’re performing these exercises, you have a limited amount of time. So any event that you plan to do needs to have a narrow focus that you can complete in a certain amount of time.
Once the exercise is over, we can look at our documentation and determine how we were able to perform during this particular test. Going through the process of getting everyone together, performing a full scale test of a particular security incident, and being able to go through from the very beginning to the very end– these full scale drills can take a lot of time to complete, and they’re very costly because you have so many people and so many resources involved in this disaster drill.
But many of the challenges that we have during these incidents are logistical issues. They might also be related to what process we follow whenever an incident occurs. And because of that, we don’t necessarily have to go through a physical drill to be able to find these issues. Instead, we can talk through the drill occurring to determine what we would do first, what we would do second, and continue through the entire process.
We call these types of drills tabletop exercises, because we’re getting everyone around the table, we’re being presented with a particular scenario, and then we’re stepping through what we would do if this particular incident occurred, instead of actually performing the tasks.
This means that everyone in the room can step through what they would be doing. They can discuss the process with others in the organization. And you may be able to find places where the process you’re following doesn’t match what other people were expecting, and you can resolve those process and procedure problems before an actual incident occurs.
There may be times when you want to go one step beyond a tabletop exercise, and have all of the players step through everything they would do if an incident occurred. This would be a walkthrough. And this allows you to test all of your processes and procedures, not only with the management of your organization, but with everyone who would be responding to this particular incident.
This would involve all the different parts of the organization, and you would use all of the tools that you would normally have available to you. This allows you to go through every process and procedure and see how it would work if you were to actually perform it.
So you could grab your tool kit, you can make sure that all the software and hardware that you’re using is ready to go, you could see if you have all of the software up to date, and you want to be sure that it’s working properly. And if you run into a problem, you can resolve it now during the walkthrough, rather than waiting for an actual event to occur.
Many organizations perform ongoing simulations where they will pretend that a particular event has occurred, and see how people in the organization respond to that. A good example of this would be a phishing attack or a password request. And you can see how many people would click on that phishing attempt and provide credentials to what would be a simulated attacker.
This usually starts with creating an email that would entice people to click on information inside of that message, and ultimately provide their login credentials. This could be sent to individual users or groups of users. And then you can check your reports to see who click through, and who provided those credentials.
If you’re sending this email through from the outside, you can also test your anti-phishing mechanisms to see if those email filters are working the way you would expect. And if the phishing got through your filter, you may have to modify the filter so that it doesn’t get to your users.
Ultimately, you’ll have a list of all of the users that received the email. You’ll know exactly who clicked on links in the email. And ultimately, you’ll know who provided credentials once they click through that link. At that point, it’s very common to take that group of folks who click through and send them to specific anti-phishing training, so they know what not to do the next time they receive one of these messages.
An IT department doesn’t commonly operate in a vacuum. There are usually customers of IT that have applications, data, and other technical resources that the IT department is managing for them. These are the stakeholders in your organization, and when something is not working properly, it’s the stakeholders that are going to be suffering.
So it’s always a good idea to maintain a good relationship with your stakeholders. Involve them in the planning process for these types of security events. And if there is an event that occurs, you can bring them in and have them involved in the resolution process.
Most of this relationship building, though, doesn’t occur when an event happens, it occurs prior to the event. Often years before an event would occur. There’s ongoing communication and meetings to make sure that everyone is involved in the process. And if you do have a security exercise, it’s important to involve all of your stakeholders. And of course, once the event or the exercise is over, you want to continue to involve them in the process, so they know exactly what to expect if a security event occurs.
Many of the problems that occur during a high stress event can be mitigated by simply having a good line of communication. So if you are planning for a security event, you want to be sure that your contact list is up to date and has all of the current information, so that you can contact everybody who needs to be informed.
In your organization, this could include your CIO. You could have a Head of Information Security, and of course, your internal response teams would be involved. And you’ll certainly need to involve people who are not in the IT organization, such as human resources, your PR group, and your legal team.
And in some cases, you may need to call in external resources, such as the owner of the data, or perhaps federal or state authorities. And if you’re part of a US government agency, you may need to call US-CERT, which is our Computer Emergency Readiness Team.
One type of security incident that’s important to plan for is a disaster. The IT team is responsible for the uptime and availability of all the data, and very often a disaster is going to affect that uptime and availability.
These disasters can present themselves in many different ways. It might be a flood, or hurricane, or a fire. Or perhaps you’ve had a system failure, or a technology failure in your software, or your hardware. And of course, human beings can cause our own types of disasters. Someone doing construction could accidentally cut through a water line that’s directly above your data center, or you may overload a circuit on your power system and cause an entire floor’s power to go out.
All of these situations need to have a comprehensive disaster recovery plan so you know exactly what to do, and when to do it. This may involve recovery at your current location, or you may have to use a different location for recovery.
You also have to think about where your data is stored, and what it would take to recover that data if you weren’t able to access it inside of your own building. And once that data is recovered, we need the applications to go along with it. And we need to make sure that we have the personnel in your IT department to be able to build all of these new systems, should a disaster occur.
When a disaster or security incident occurs, we need to find some other way to get our job done. And often, this will require continuity of operations planning, or COOP. this is something that we would put together well before a disaster occurring, so that we know what to do if we don’t have our normal systems in place.
We rely constantly on the technology that we’ve created, and we often don’t even think about how we would perform our job functions if we didn’t have our laptop, or smartphone, or any of our other technology. But of course, there needs to be some type of alternative because this technology may not be available during a disaster.
So we might use manual transactions that we’ve created on paper receipts, and instead of using automated transaction approvals, we would pick up the phone and call someone to get those approvals. If we have to use these processes, it will probably be painful and less efficient than our technology, but at least we’d be able to get some of our work done. But we want to be sure that all of these contingencies are well documented prior to a security event occurring.
Inside of our organization, we need to have a group of professionals who have been trained to respond to these security incidents. This is our Incident Response Team, and they have been specifically trained to deal with these types of problems.
They first would determine what type of incident is occurring, and what type of response does it need. For example, a virus infection has a certain set of responses that may involve a small group of people. But something like ransomware, or a distributed denial of service attack, may involve a larger group of people in your organization.
The Incident Response Team may not be a separate department within your organization, but instead may be a group of people that come together in a committee if an incident occurs. This means they can be pulled in when a response is needed, and when no security incident has occurred, they can go back to doing their normal day-to-day job.
This is the team within your organization that responds to any incidents that might be occurring. They provide the analysis of what is occurring, and what needs to be done to resolve it. And they provide the reporting that gives us the information we need to make our networks even stronger for the next incident.
If you’re involved in a security incident, the first thing you’re going to think about is how much data is going to be affected by this? The data is some of the most valuable assets that your organization has. So you want to be sure that you have backups of everything. But perhaps more important, especially during a security incident, where is that data located, and how much of it do you have?
You need to make sure that you have copies of this information. Some of it might be on site, some of it may be off site. There may be different life cycles of this data that is stored in different ways, depending on how you’re storing the information. And there may be data that is purged or deleted after a certain amount of time has gone by.
Some organizations are also required to store certain types of information for a certain amount of time. This regulatory compliance may affect financial organizations, or organizations that deal with certain types of data.
There might also be very good reasons to have this backup available for operational problems. For example, someone could accidentally delete data, and we need an easy way to restore that data, if needed.
Or if there’s a disaster, and a flood or fire happens to take out all of your storage systems, you need to have some way to restore that data from the backup.
And of course, not all of the data in your organization has the same priority or the same criticality. We need to make sure that we have access to all of the data, but we need to understand, more importantly, what data we restore first, what data we restore second, and so on. There needs to be very clear understanding of what applications are going to be used, and where the data is located for those applications.