Establish a policy for investigating
and documenting network intrusions
Ray Geroski
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:
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:
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:
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:
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:
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.
Copyright ©1995-
2003 CNET Networks, Inc. All Rights Reserved.
Visit us at www.TechRepublic.com