Home

In the News

Virus Report

Subscribe Now Online

Media Kit

Archives

Contacts

Calendar of Events

Articles

Article Submissions

Web Seminars

White Papers

Inside Current Issue

March 2006 Issue

Inside Current Issue: Cover Story

Planning for Cyber Breaches Leads to Top Response
By Axel Tillmann

Most Fortune 1000 companies have established security departments with clearly defined duties, separate from the traditional Network Operations groups. Typically security is, among many other tasks, responsible for accessing and identifying threats to the corporate network infrastructure and endpoints. The approach is typically focused on prevention and detection. Companies have invested millions in firewalls, IDS, IPS, SIM/SEM, antivirus and NAC.

While prevention and detection typically reduce impacts to the infrastructure, it is a painful experience for most customers when threats still appear. It is the overwhelming consensus of leaders in the security industry that those threats will intensify and will be more intelligent in bypassing prevention. This belief is founded in the detailed understanding of our vulnerabilities and the knowledge that future attacks will be more often done with criminal intent, versus past attacks, which were devised as a “sport” by high-school/college kids.

These facts now force companies to take a hard look at responding to threats. The response splits into two groups: quarantining and remediation. Both are manual processes with response taking some organizations hours, even days, just to be able to identify individual nodes on the network. This is why a detailed response plan needs to be in place for quick and smart reaction.

Decisions
Making decisions about something before it happens is a tenet of good planning. Deciding what actions to take before an event occurs allows for quick response and implementation once something does happen. This way you don’t have to make any last calls under the gun. This is why it is good policy for network administrators to look into their crystal balls and define, classify and prioritize future possible incidents, as well as define what’s going to be done once they do penetrate your network.

For example, if an employee installs a peer-to-peer file-sharing program on his desktop, will this be considered a cyber-security incident or is this merely an issue for desktop support?

While one usually equates a cyber-security incident as a real-time attack, actions that have the potential to enable attacks or break corporate policy may also fall into this category. There are some clear types of malicious activity that must be classified as incidents, including external penetration by hackers, loss of confidential information, denial of service, and the many forms of self-propagating malicious code (ie, viruses and worms).

Even with these activities that are obviously cyber-security incidents, it is important to classify and prioritize them. For example, in cases involving loss of confidential information or those perpetrated by a hacker, things such as evidence collection and prosecution of the perpetrator have to be taken into consideration. These considerations will impact how you respond. If your number one goal is to collect evidence, how you contain the incident is important.

This is often more different than how you might respond to a typical virus or worm incident. In this case, the priority is to quickly isolate and contain the infection to stop the bleeding. Analysis for this type of attack is more focused on identifying how the malicious code made it inside the network, as opposed to if a server’s logs have properly been saved to present as evidence.

Organization Work Flow
Once you have defined what your organization will consider cyber-security incidents, and determined which of those incidents need evidence collection, it’s time to look inward. During the response to an incident, a great deal of communication needs to occur. Communication for awareness -- whether to kickstart action by team members or to receive approval before taking defensive or offensive actions -- are all required.

To implement this effectively, it is important to identify how your business is organized and how your IT support is structured. Does the geographic location of an incident impact who is responsible for responding or approving response actions? If so, who are these people?

What happens if the server involved is an e-mail server or hosts a business-critical application? Are the administrators responsible for these critical services part of the response process? Who is responsible for responding and approving response actions?

War Games
Build scenarios taking into account all of the information on incident types and your business structure. For example, what steps should be taken if Office A becomes infected with a rapidly propagating worm? Who should be contacted? What quarantine actions should be taken? Should HQ take action to protect other offices? What can or cannot be done with or without approval by whom? For this, define particular threat levels and classify the actions that need to be taken under different situations in advance. This will give you the upper hand.

Documentation
What type of documentation must be provided by those involved? If trouble tickets need to be created, who should create them and when?

Documentation is critical. Without it, you will be unable to properly analyze your organization’s response. More importantly, an incident can also wreak havoc on your organization’s configuration management plan, as network changes are often made quickly with little documentation. In addition, new federal guidelines, in both the federal (FISMA) and commercial (Sarbanes-Oxley) arena, require detailed documentation and auditing of all actions taken and their respective impact to an organization.

When the Smoke Clears
Do not forget about system restoration. Your organization’s backup and recovery plans should be closely integrated into your incident response plan. Who is responsible for restoring the systems once the incident has been contained and eradicated? In some cases, cleanup is quick and easy. In others, a system may need to be completely rebuilt and backups restored.

Hindsight
Once the response is over, analysis helps you tweak your plan. Besides identifying why and how the incident occurred, analyze how well your organization has responded. Was the incident quickly identified and communicated? Was the response targeted, accurate and effective? Was all the required documentation properly created?

With the help of proper technology the response process can be strengthened and have a staged rollout from semi-automatic to full automation. Tools are now coming out that can be predefined to automatically respond to cyber breaches. With proper planning and tools, there is no reason for response to be a full-time job.

About the Author:
Axel Tillmann is vice president of ENIRA Technologies (www.enira.com), a provider of intelligent network solutions. He can be reached at (888) 277-7638.

Go Back

© IMPIRE Communications, LLC All Rights Reserved.  

Website designed & managed by Oculus Networks