What processes should you have in place before, during, and after a security incident? In this video, you’ll learn about the processes you can follow to help detect, contain, and resolve a security incident.
<< Previous Video: Incident Response Planning Next: Gathering Forensics Data >>
If you ever want to read through some guidelines that you can use to help understand the incident response process, you might want to look at the documentation from the National Institute of Standards and Technology. It’s the NIST Special Publication 800-61, which is the Computer Security Incident Handling Guide. This will give you an overview of the entire incident response lifecycle, which tells you how to prepare for the incident, how you can detect and analyze that an incident has occurred, how to contain eradicate and recover from an incident, and any post-incident activities you should follow.
Before an incident occurs, there are a number of tasks that can help you prepare. One is to determine the communication methods, and who will be contacted during an incident. You want to understand how to handle hardware and software that is involved during an incident. For example, what do you do with laptops? And how do you handle removable media? You also want to be sure that you have resources available.
Make sure that you have documentation about your network configurations, any network diagrams, baselines, or anything else that can help you understand what the normal operating is of your environment. You also want to be sure you have a good toolkit of software. Make sure that you have clean operating system and application images, and you should know exactly what policies should be followed if there is an incident. And you want to be sure that everybody involved knows exactly what to do when an incident occurs.
There are many different ways to detect when an incident occurs, and these detection methods may have different levels of detail or different levels of perception. We have a challenge being able to identify these because all of our systems and all of our networks are constantly being attacked all the time. So how do you break out what is a legitimate threat versus one that is not a legitimate threat? These security incidents are very involved and very detailed. It usually involves many different systems, and it usually takes someone with extensive knowledge to be able to identify and be able to react to one of these security incidents.
It’s always useful if you can be warned before an actual incident occurs, and there are a number of different ways to be able to monitor your environment to give you a heads up on what might be coming. One way might be through your existing web server logs. You’re logging everything that everyone is doing on a web server, and there are a number of vulnerability scanners they can sift through all of that data to provide you with some insight on where security incidents might be occurring.
Another good precursor to look for are the monthly announcements on security vulnerabilities. We can look at the monthly Microsoft patch release or anything that might be coming from Adobe to find out where the particular holes may be in our operating systems and our applications. And in some cases, you may be told directly that a particular group is going to attack you, especially if your organization is very public or you have a particular group of people that don’t like you. They may be telling you, we’re going to try to bring down your systems.
There are a number of indicators that may be able to tell us that an incident is underway or that a particular exploit is successful. One way might be to look at buffer overflows. If we can identify these through an intrusion prevention or an intrusion detection system, then we may be able to know that someone’s trying to attack a particular application. If your anti-virus systems are identifying malware, then you want to have all of those logs sent back to a central place so that you can then have the administrator notify everyone that an incident has occurred.
You might also have monitors on your hosts that are able to determine if any major changes occur, or if anybody modifies any files. And that, of course, can alert you that something is either going to happen or something is already underway. And, of course, if your network traffic changes from what might be normal, it may be a clear indication that something is afoot on your network.
When an incident has occurred, it’s usually a bad idea to leave it alone and see what happens. These types of incidents can grow very rapidly, so you want to be sure to isolate and contain everything that might be involved. In some rare occasions, you may be able to limit the scope to a single sandbox. This is where the attacker thinks that they are on a real system but it’s really a virtual environment that you’ve created just to collect these incidents.
The bad guys also know that you may take these systems and isolate them from the rest of the network, and we have found malware and other types of malicious software they’re constantly checking to see if they have access to the internet. And if that particular communication channel is severed, the malware will automatically delete itself and anything else on the system. After the incident is over, it’s time to get back to normal. If this is malware that has been installed, then we need to eradicate that malware, disable any user accounts that may be involved, and fix any vulnerabilities that might be on that system.
If this is a complete system, we might want to recover from known good backups, or it may be a case where we have to rebuild everything from scratch. The process of getting back to 100% normal may take some time, and it’s common to have a phased approach to get back up and running. Sometimes it may take months to get back to normal, especially if this is a large-scale attack.
Normally, this reconstitution will start with the devices that you can change very quickly. You can implement new firewall policies and install patches in a relatively quick form. But some changes may be much more involved. You may have to change part of your infrastructure or have a very large-scale security rollout, and those may take a bit more time to be able to implement those updates.
Nobody’s system is 100% perfect, so this is an opportunity to make things better. It’s common to have a post-incident meeting to bring everyone together and discuss what was found during this particular incident. You don’t want to wait too long because memories fade over time.
You want to have everybody fresh and familiar with exactly what just occurred in your environment. This is the place where you can start asking questions and documenting the incident, finding out exactly what happened with a detailed timestamp. This will be a good opportunity to evaluate how your incident plans were able to be executed. Did everything work the way you expected? And if they didn’t, are there things you could do next time to make the entire process more effective?
If you were evaluating precursors prior to the incident, did any of those precursors give you any idea that this was going to happen? And if they didn’t, are there other precursors we should be following so that we can prevent this from occurring next time? All of these tough questions will help you evaluate your process, make some changes to make the process more efficient, and you’ll be ready for the next security incident.