Networking

Establish a policy for investigating and documenting network intrusions

An important and often-overlooked element of network security is a well-defined intrusion response policy. Follow these tips to create an effective policy that your IT department can implement for handling network intrusions.


Putting devices and software in place to protect networks from viruses and intrusions is the first and sometimes the easiest part of securing a network. But many admins overlook the next and more difficult step in the overall security process: establishing a policy for handling vulnerabilities, threats, and especially intrusions—attempted or successful.

In our Technical Q&A forums, TechRepublic member TomW recently asked for advice on what to do upon discovering a network intrusion: “Are there any templates or guidelines that would be useful to develop a policy/procedure(s) for what to do if and when an intrusion or intrusion attempt has been detected?”

PC/LAN administrator Grant Fleming responded that net admins should write up an intrusion response policy, and he directed TomW to the SANS Institute and the CERT Coordination Center Web sites, which both offer detailed information on monitoring for and responding to network intrusions.

IDS monitoring and general policies
Before you can respond to a network intrusion, you must first determine whether your system has been compromised and verify that the attack was real. One CERT Coordination Center article stresses that your policy must address intrusion detection in your overall security policy and define what you consider an intrusion. CERT says that the policy could include the following as the types of network attacks:
  • Unauthorized access attempts
  • Unauthorized access to or disclosure of information
  • Any acts that interrupt or result in a denial of service
  • Unauthorized data storage or transmission
  • Unauthorized hardware and software modifications

In the SANS article “What Do You Do After You Deploy the IDS?”, Chris Morris offered the following general steps to follow in response to an intrusion:
  • Investigate the nature of the incident: What happened and how did it happen?
  • Determine how you can prevent future intrusions by the same means.
  • Determine the extent and nature of the damage.
  • Repair the damage.
  • If necessary, update or change procedures to better deal with this type of intrusion.
  • You may also want to identify or at least attempt to identify the attacker.

Tiered response policy
Because of the variability in the form and seriousness of attacks, some of these steps may not be necessary. Morris recommends establishing a tiered response plan that escalates according to the seriousness of the attack. You should identify different levels of attacks and determine how to respond to them.

A low-level threat might be a single instance of a port scan or an unauthorized Telnet. In response, you should record the IP address and domain of the intruder and watch for future attempts from the user.

The next level comprises more serious threats. Blatant attempts to obtain passwords or to access restricted areas would be considered overt attacks. Your response to this level of intrusion should escalate a notch. You must investigate these attacks thoroughly to document the method of attack and to prevent them from happening again.

At the top level of a tiered policy, you will be responding to attacks that are much more serious and potentially damaging, so your responses must go further as well. Depending on the nature of the damage of these attacks, you may consider legal action against the intruder. Attacks at this level include multipronged attacks, DoS attacks, or other deliberate breaches of security and the compromising of systems and/or data.

In addition to establishing policies for what actions to take in response to attacks, CERT also emphasizes the importance of determining the roles of those involved. It says that you should “document the roles, responsibilities, and authority of system administrators, security personnel, and users regarding the use and administration of all assets when they participate in detecting signs of suspicious behavior, including intrusions.”

Record the events
Regardless of the actions you take in response to an incident or against the attacker, you should thoroughly document all details about the event, as well as your response to it. The information you gather serves two purposes:
  • The knowledge can help prevent future attacks.
  • If you elect to pursue legal action, your documentation will serve as evidence in the case, so it must be thorough and accurate.

Member dlafrombois said that if you plan to pursue any kind of legal action in response to an attack, you must thoroughly document all aspects of the attack and your investigation of it prior to handing the information over to the authorities. Once the information is in the hands of law enforcement, dlafrombois said, you can no longer collect information relating to the case.

A key piece of the documentation process is a daily log of the actions you take to investigate the intrusion, to prevent future attacks, and to notify others of the incident. Keep the log organized and in a safe place. Obviously, you do not want attackers you’re investigating to stumble across your documentation of their crimes, so you should make sure that it’s out of reach of anyone who might breach your network security.

Detailed information about the vulnerability that an intruder exploited is essential for preventing future attacks. It’s difficult to prevent a break-in if you don’t know how it happened; your investigation of the circumstances surrounding the incident should be thoroughly documented. This information can then serve as a foundation for a security policy governing preventive steps to secure your network.

CERT recommends appointing someone to act as a point of contact between your organization and law enforcement and other agencies to ensure that you are properly documenting incidents in the event that legal action becomes necessary. Your information gathering and documentation of incidents must thus be as thorough as possible to help you better secure your network and to provide accurate and valuable evidence should legal action become appropriate.

Policy framework
Your overall policy should encompass the following considerations:
  • Intrusion monitoring
  • Attack definition
  • Incident response plan

You probably have the first item in place already. The second consideration will be easy to address, but you will need to spend some time on the third one. Your response plan should include the following elements:
  • A tiered-action plan based on incident severity
  • Documentation of plans and actions
  • Notification of the appropriate persons (internal and external)
  • Intrusion investigation
  • Evidence gathering
  • Damage repair and control
  • Legal action (in some cases)

Consider these points carefully in building a solid plan with clear guidelines that IT staff can follow to act appropriately if an intrusion is detected.

It’s important that every attack be treated consistently according to the standards established in your plan. This will ensure that you take the necessary steps to secure your network and gather evidence should legal action be appropriate, and it will also give you peace of mind to know, that no matter what happens, you’ve covered all the bases.

Editor's Picks