Effectively respond to a security incident with these five steps

by Michael "Mullins CCNA, MCP" | Sep 08, 2005 7:12:00 PM

Tags: NETWORKING, Michael Mullins CCNA, MCP, network, security, security incident, Security Solutions Newsletter

Takeaway: Incident response is usually one of those security areas that tends to be impromptu—companies don't think about it until they have to. But that needs to change. Mike Mullins discusses five steps you can take to effectively respond to a security incident that can help you prevent future occurrences.

Do you operate a network that has public access? If you monitor that network—you are monitoring your network, right?—then sooner or later, you're going to have a security incident. How you respond to such an incident often decides how long your network will continue to function as a part of your business.

Incident response is usually one of those security areas that tends to be impromptu—you don't think about it until you have to. But that needs to change.

I've written before about creating an effective incident response policy (IRP) and the eight key areas such a policy should address. But what if your organization hasn't gotten around to developing an IRP? Security incidents don't wait for organizations to have their ducks in a row. In fact, they tend to occur at the most inopportune times.

Let's look at five steps you can take to effectively respond to a security incident.

Identification

First, identify the traffic to determine whether it poses a threat to your network. If your logs (i.e., IDS, firewall, event, etc.) uncover an issue or a user reports a problem, analyze the information to determine whether it's accurate and if it has the potential to disrupt or deny network services.

Once you've completed the analysis and determined the information is credible and includes the potential for harm, classify the event as an incident—any adverse event that compromises some aspect of computer or network security.

Containment

After you've identified a security incident, the next step is to contain the damage and prevent harm from spreading further throughout the network—or even harming networks outside your security boundary. The most immediate means of containment is either to disconnect the infected machine and isolate it from the network or to stop the service that's causing the incident.

Make sure you've documented who has the authority to disconnect systems and possibly disrupt business needs. This needs to be in writing, and the designated authority should be available 24/7.

Eradicate

After you've taken steps to contain the incident and its effects, eradication is the next step. Your goal is to permanently remove any evidence of the incident from the network.

This could involve removing hard drives and creating a chain of custody for that data for law enforcement involvement. Or it could mean reformatting those hard drives and restoring the systems to operations. The important thing is to decide how to remove the damage from your network.

Recovery

The next step is recovery. The extent of the damage and your chosen method for eradication will help dictate recovery . Most corporate networks simply require reformatting and reloading the systems, applying the appropriate patches, and restoring the data from a known good backup.

If the problem isn't system-specific and involves network changes or changes in the security architecture, then this is the time to submit changes requests and seek approval for the changes.

Follow-up

After you've recovered from the security incident, the final step is to learn what you can from the actual incident. Every incident provides a potential for learning from that experience. It also gives you the opportunity to modify procedures and operations to mitigate the likelihood of the incident reoccurring.

For example, let's say the security incident involved not applying patches in a timely manner. You need to modify your change management process and patch testing procedures to be able to respond more quickly to threats in the future.

Sometimes the overall problem is a lack of training on the part of the people responsible for the affected systems. This could include users who open attachments from unknown sources or system administrators working with operating systems who don't have the proper training.

Final thoughts

After any security incident, you should create an action report that includes three simple goals.

• Identify how the incident occurred.
• Identify what actions you took after identifying the incident.
• Identify what you've done to prevent this type of incident from reoccurring.

How you respond to incidents and what you learn from those incidents has a serious business implication. That's why it's important to make sure you're prepared before they happen and to learn from your mistakes.

Miss a column?

Check out the Security Solutions Archive, and catch up on the most recent editions of Mike Mullins' column.

Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.

Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.