Steps To Effectively Respond To A Security Incident And Threats On A Wireless Network

Sean Franks

BIS 634

Steps to Effectively Respond to a Security Incident and Threats on a Wireless Network

Incident response is usually one of those security areas that tend to be impromptu--companies don't think about it until they have to. But that needs to change. In this paper I will discuss five steps - identification, containment, eradication, and recovery and follow up a business use to effectively response to a security threat and I will suggest four actions -use encryption and passwords, e-mail protection, install antivirus software, install workstation firewalls a businesses can take to effectively prevent a security incident in the future.

Businesses today must manage growing risks to their mission critical networks from attacks such as spyware, rogue wireless LANs, compromised remote/VPN users, DDOS attacks, system misconfigurations, and unpatched OS's, all of which increase the risk of a network breach and interruption to both sales and business operations.

Does your business 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 tend to be impromptu--you don't think about it until you have to. But that needs to change. Every organization should develop an incident response policy (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 businesses 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 need 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 security technician's 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. Another step to eradicate incidents for happening is to embrace encryption and passwords

If the computer or PDA accessing your network supports encryption, then, by all means, use it. PDAs and wireless computers are accessing your company's information, and you need to make sure to safeguard it. If the device doesn't support passwords, it doesn't belong on 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