January 3, 2001
Your company has finally decided to implement an intrusion detection system (IDS). You have listened to vendor after vendor describe his wares in detail and explain why their system will work best in your environment. You have chosen your IDS based on price, support, ease of use, installation and best company t-shirt design. You have tested your new IDS successfully and have now deployed it into the production environment. The question is: what now?
Hopefully before you have deployed your IDS into your environment, you took the time to develop a solid IDS monitoring policy and procedure. These documents are written to answer that "what now" question. You must determine how you are going to monitor your systems, who will monitor them, what will you do when you get an alert and who is going to fix the vulnerability. Additionally, you must determine the level of response that you will enable once an intrusion has been detected. The ideas outlined in this paper should be useful for network, host-based and so-called hybrid intrusion detection systems and for the development of response procedures.
The goal of an IDS is to positively identify real attacks while negatively identifying so-called false positives (an event, incorrectly identified by the IDS as being an intrusion when none has occurred). Therefore, the IDS will have to be monitored. To monitor the IDS effectively, you will need to develop effective plans in the following areas:
Why bother detecting an attack in the first place, if you know you are not going to do anything about it? Good question. You are going to have to develop a well-documented incident handling procedure if you are going to utilize the information that you have captured during monitoring. The incident handling procedures must be understood, accessible and rehearsed. It may be of value to develop an outline of goals and objectives similar to the following in how your company will handle an incident:
Level 1 One instance of potentially unfriendly activity (finger, unauthorized telnet, port scan, etc.).
Level 2 One instance of clear attempt to obtain unauthorized information or access (download password files, access restricted areas, etc.) or a second Level 1 attack.
Level 3 Serious attempt to breach security (multi-pronged attack, denial of service attempt, etc.) or a second Level 2 attack.
Of course, all potential, suspected, or known information security incidents should be reported to the company Information Security Incident Response Team (SIRT) or designated security individual(s). These personnel will be identified in the procedure document for handling incidents. The SIRT will assign personnel who will assemble all needed resources to handle the reported incident. The incident coordinator will make decisions as to the interpretation of policy, standards and procedures when applied to the incident.
Law enforcement and investigative agencies will be notified, as needed and required, by the SIRT. In the event of an incident that has legal consequences, it is important to establish contact with investigative agencies (e.g., the FBI in the U.S.) as soon as possible. Local law enforcement should also be informed as appropriate. Legal counsel should be notified of an incident as soon as it is reported. At a minimum, legal counsel should be involved to protect the legal and financial interests of your company.
All information security incidents must be documented. This documentation provides a reference to be used in case of other similar incidents. System and network log files, network message traffic, user files, results produced by intrusion detection tools, analysis results, system administrator console logs and notes, and backup tapes that capture the before-intrusion and after-intrusion states of the affected system must be carefully collected, labeled, cataloged, and securely stored at each stage of intrusion analysis.
Evidence and activity logs should be protected before, during and following the incident. To ensure that evidence will be acceptable to the legal community, collecting evidence should be done following predefined procedures.
The incident handling process will provide some escalation mechanisms. In order to define such a mechanism, the SIRT should create an internal classification scheme for incidents. Associated with each level of incident will be the appropriate procedures. The following is an example of level of incidents with corresponding definitions:
An Intrusion Detection System is a tool that is part of a good security architecture and Multi-Layered Defense Strategy. However, once the IDS is deployed onto the network the system must be monitored and alerts responded to. Documented monitoring guidelines and alert criteria must be developed so you can respond effectively to an incident. Response actions should be developed for incident handling procedures.
Bace, Rebecca. "An Introduction to Intrusion Detection and Assessment".
Carnegie Mellon, CERT Coordination Center, "Establish policies and procedures for responding to intrusions".
Carnegie Mellon, CERT Coordination Center, "Prepare to Respond to Intrusions".
Carnegie Mellon, CERT Coordination Center, "Responding to Intrusions". July 30, 1999
Carnegie Mellon, CERT Coordination Center, "State of the Practice of Intrusion Detection Technologies". Nov. 16, 2000
FAQ: Network Intrusion Detection Systems. Version 0.8.3, March 21, 2000
Ranum, Marcus J. "Intrusion Detection: Challenges and Myths". 1998
Sondra Schneider, Erik Schetina and Donald Stahl. "Life After IDS". Sept. 1999