Identifying and responding to an incident is an important part of IT security. In this video, you’ll learn about incident preparation, detection, precursors, indicators, and more.
As a security professional, you’ll be responsible for responding to security events that occur in your organization. Events like a user clicking an email attachment and suddenly infecting themselves with malware, and that malware then begins communicating with other services and sending information outside of your organization. Or maybe you’re dealing with a distributed denial of service attack with botnets that are overloading your internet connection. Or maybe information that was stored confidentially on your servers, has now somehow made its way onto public servers on the internet. And sometimes the thief contacts you before making it public, to see if you’d like to pay a little money to keep it away from the public’s eyes. Or you can have a user installing peer-to-peer software inside of your organization and effectively opening up all of your systems to access from the outside. Each one of these security incidents are very different but they all require some type of response by the security professionals in your organization.
These types of incidents are often responded to by your incident response team. This is a group of people that have been specifically trained to deal with these types of circumstances. This might include the IT management team for your security department, so you have corporate support. It could have compliance officers that are responsible for making sure that all of the data is compliant with all of the rules and regulations followed by your organization. You’ll of course need technical staff to help troubleshoot and resolve these types of problems. And there may be users in your community that can help with these situations as well. This is certainly not a comprehensive list, you could have management within the organization, public relations, applications developers, and other people who would be critical for responding to these types of incidents.
NIST, or the National Institute of Standards and Technology here in the US, have created a document that can help you understand the process you’d go through to handle these types of security incidents. This is NIST special publication 800-61 Revision 2, which is titled computer security incident handling guide. This gives you information about the entire lifecycle when you’re handling a security incident. This includes preparation, detection and analysis, containment, eradication, and recovery, and lastly your post-incident activity.
The key to handling a security incident properly, is to make sure you’re well prepared. There needs to be all of the right people and processes in place so you know exactly what to do when the incident occurs. This would include communication methods, which will document exactly who should be contacted and how they should be contacted, this would also include your hardware and software tools, so you know exactly how to respond to these problems, store and capture data that’s important and be able to have information that you might want to use later on as evidence.
There will also be a need to have documentation of the organizations network, , understand exactly where data may be located, and once you have created and stored some of this evidence you may want to create hash values of that information so that you can be assured that none of that information changes. You also want to prepare for the mitigation process, so you want to be sure that your planning includes a clean operating system and application images. And lastly, and probably most importantly, we need policies and procedures so that everyone knows exactly what they should be doing when a security incident occurs.
To be able to respond to a security incident, you have to know that the security incident has occurred. And there are many different ways to monitor and identify these security incidents. This is an ongoing challenge because we receive so many different types of attacks all the time, every day. And there are always security tools we have in place that will prevent the majority of these types of attacks. But how do you identify the legitimate threats and know if a particular incident has occurred? These security incidents often include many different devices, many different operating systems, and you often need someone who’s very knowledgeable in order to understand exactly when an incident might have occurred.
Sometimes we can be informed when the potential for an incident may have increased. These precursors give us a little bit of a heads up or at least help us to predict where particular areas of the network may receive a security breach. For example, we may look through a web server log and see that someone was using a vulnerability assessment tool to try to identify any open or known vulnerabilities on that server. Or it may be that announcement day where we receive a list of vulnerabilities in Microsoft operating systems or Adobe Flash, that tell us that we need to update those systems to avoid any type of vulnerability. Or there might be direct emails, Twitter messages, or Facebook posts from a hacking group that tells you that they are going to try to attack your network.
This means that we’ll need to monitor our systems and see if we can identify cases where a particular security incident might have occurred. For example, we might find that our intrusion prevention system has identified a buffer overflow attack against our system, and they can tell us whether that particular attack was successful or whether it was stopped by the IPS. We might also have alerts and alarms that come from our anti-malware or antivirus systems that can tell us if a particular piece of malicious software is running on a device. We can also have messages from our file integrity monitoring systems that will be able to tell us if any of the critical operating system files on our servers have been changed or modified. And if we’re monitoring network traffic, we may be able to tell if there are differences in the traffic as compared to what might be normal on that particular segment.
If you do find that there’s malicious software or some type of breach, one of the best things you can do is isolate and contain that particular security incident. You would never want to leave it running just to see what it does because nothing good can ever come from a situation like that. Instead we might want to take that malicious software and run it in a sandbox. This would be an isolated operating system that is specifically designed to run software and see what the results of running that software might be. This is also an environment that can be completely deleted after performing your analysis, so that you can be assured that that malware is not going to get outside of your sandbox.
But even the sandbox doesn’t provide for perfect analysis of malware. Some malware can recognize when it’s running in a sandbox and it will perform differently in a sandbox than if it’s running in an open network. And there’s some malware that recognizes when you lose connectivity to the internet, so when you isolate that system, it begins deleting files or damaging the operating system. Once we’ve identified that an incident has occurred and we’ve identified where malware might be on a system, it’s time to recover that system. We would first need to eradicate this malware and remove it from that system. Sometimes this involves completely deleting everything on the system and recovering from a known good backup or a known good image or we may want to recover the system and then fix the vulnerabilities that caused this incident to occur in the first place.
This is why it’s always important to have a backup so that you can restore this system very quickly. If you don’t have a backup, then you’ll need to rebuild the entire system from scratch and in some cases, you may have lost data because you don’t have a backup. In either of those situations you’ll want to be sure that you have rebuilt the system and that you have then repaired the system to close any of those vulnerabilities. And lastly, you want to lock down the perimeter of the networks, so that you can stop the attack before it gets into your private network.
On large networks, the reconstitution process can be very difficult and very time consuming. You want to be sure that you have cleaned every system that could have been touched by this malware, or this security incident, and this might take months of work to be able to recover everything on the network. This usually starts with making high value changes and making changes that can be done very quickly. So we may want to send patches out to our systems, or modify the firewall to prevent a certain type of traffic from entering your network. Then you can look at a much larger response across the entire infrastructure and begin looking at changes in how the network is designed, look at the operating systems that may be used for a particular project, and perhaps roll out additional security controls so you can prevent these types of incidents from occurring again.
And once the incident is over, we can take a step back and look at what processes worked and what processes didn’t work during our incident response. We might want to have a post incident meeting where everyone attends to talk about what occurred during the process, and we want to be sure we do this as quickly as possible because we tend to forget some of the details as time goes on. You want to make sure you have plenty of documentation, and that you’re able to offer ideas on what to do better for the next incident.
An important piece of documentation would be able to understand exactly what happened, and when it happened, so you know exactly the time frame that everything occurred. You also want to examine how all of these plans you put in place before the incident were able to execute during the actual incident. And then what would you do next time to make those plans work even better? Being able to look back and have an objective view of how things went is going to help you the next time something happens on your network. And it may be that this particular incident has caused you to have a different idea of things to look for the next time. So you may want to update your alarms and alerts, so that you’re able to receive additional precursors that might identify when an incident is going to occur.