Requirements for Enterprise-Wide Scaling Intrusion Detection Products

A Criteria Catalog for IT Executives, IDS Users and Vendors

(Version: 2002-06-19 rev 3)

Abstract: This text defines criteria that are substantial for Intrusion Detection Systems to be chosen for enterprise-wide deployment. It is supposed to be used for planning and evaluation purposes and could also be used as a list of questions that you should ask your IDS vendor.

2002 Detmar Liesen

counter.spy@gmx.de

-1-

DISCLAIMER: THIS TEXT MAY BE COPIED AND DISTRIBUTED FOR EDUCATIONAL AND NON- COMMERCIAL PURPOSES ONLY. ANY ALTERATION THAT IS NOT EXPLICITLY ALLOWED BY THE AUTHOR IS STRICTLY PROHIBITED. THE AUTHOR IS BY NO MEANS RESPONSIBLE FOR ANY DAMAGE OR LOSS OF PROFIT THAT MIGHT OCCUR BY FOLLOWING THE RECOMMENDATIONS OF THIS DOCUMENT.

If you have questions or suggestions please contact me via email: counter.spy@gmx.de

2002 Detmar Liesen

counter.spy@gmx.de

-2-

Contents

1. Introduction ........................................................................................... 4 2. System....................................................................................................... 5

2.1. Functionality................................................................................................. 5 2.2. Level of importance...................................................................................... 5 2.3. Definition of a generic concept for enterprise-wide IDS deployment.......... 7 2.3.1. Short-term deployment .......................................................................... 8 2.3.2. Mid-term deployment ............................................................................ 8 2.3.3. Long-term deployment .......................................................................... 8

3. Criteria Definitions ....................................................................... 10

3.1. Criteria for Installation, Configuration and Management .......................... 10 3.1.1. Must Criteria........................................................................................ 10 3.1.2. Shall Criteria........................................................................................ 11 3.1.3. Should Criteria..................................................................................... 12 3.2. Criteria for Detection Technology.............................................................. 12 3.2.1. Must Criteria........................................................................................ 12 3.2.2. Shall Criteria........................................................................................ 13 3.2.3. Should Criteria..................................................................................... 13 3.3. Criteria for Response - Mechanisms, Reporting and Forensic Analysis .... 13 3.3.1. Must Criteria........................................................................................ 13 3.3.2. Shall Criteria........................................................................................ 14 3.3.3. Should Criteria..................................................................................... 16 3.4. Criteria for the Security of IDSs................................................................. 16 3.4.1. Must Criteria........................................................................................ 16 3.4.2. Shall Criteria........................................................................................ 18 3.4.3. Should Criteria..................................................................................... 18

IDS Literature .......................................................................................... 19 Credits ............................................................................................................ 30 The Author.................................................................................................. 31

2002 Detmar Liesen

counter.spy@gmx.de

-3-

1. Introduction
The text was developed within the scope of a pilot project for IDS deployment within the network of a worldwide operating company. The project proceeded in three basic steps: 1.) All available information about capabilities of modern Intrusion Detection Systems was gathered, which resulted in a list of features and requirements without any special order of priorities or practical aspects. 2.) Three widely used Intrusion Detection Systems were evaluated in a testing environment. The tests comprised general installation issues, ease of management and configuration, presentation of events, and help on interpreting those events. These tests were by no means a benchmark, but a test on how the systems would be manageable within a large network with limited personnel resources, e.g. if the underlying architecture fulfills certain criterial, what management features are provided etc. Security of the IDS components themselves also was an important issue. 3.) An IDS was placed outside a productive internet firewall in order to collect real-life data and to evaluate how many false positives occur and how those can be identified and reduced. One of the results of these efforts is this criteria catalog, which is ordered by priorities. Note: To my knowledge, no system currently exists that fulfils all the criteria not even those criteria that are considered compulsory. Now you could argue: what good is a must criterion that is not fulfilled by any system? The answer is: I have tried to find out what capabilities and features are most important for enterprise-wide deployment, not what is currently provided by the systems. In my opinion, the criteria in this text do reflect the practical needs of those who will have to work with ID Systems everyday efficiently, and effectively.

2002 Detmar Liesen

counter.spy@gmx.de

-4-

2. System
The aim of the paper is to compile relevant criteria and features and to group those criteria. You can use this catalog for vendor questionnaires and for your own evaluations. The concept is supposed to apply to most larger and medium-size companies who plan to deploy IDSs. The criteria are structured as follows:

2.1. Functionality
Installation, configuration, management o Ease of installation o Quality of the user interface (lucidity, intuitiveness) o Scalability o Updating capabilities, update automation o Customization ( policies, signatures) o Help/support Detection technology o Methods of attack detection and breadth of attack detection o Performance (i.e. speed, dropping no packets) o Accuracy (i.e. few false positives and even fewer false negatives) Intrusion Response, reporting and forensic analysis o Countermeasures o Reporting and event presentation o Event correlation, aid at analyzing events Security o Method of authentication and communication between the various IDS components. o Resistance against attacks that are aimed at the IDS itself, e.g. flooding, DoS and others. o Stealth, i.e. providing potential hackers with as little information as possible

2.2. Level of importance

Must Criteria: Shall Criteria: Attributes or features that are compulsory. Attributes or features that are considered important and thus are decisive for the choice of a certain IDS product (differentiators).

Should Criteria: Attributes or features that are more than nice to have, but are not necessarily decisive in order to be chosen.

2002 Detmar Liesen

counter.spy@gmx.de

-5-

Evaluation of IDS products has to take into account the purpose of the product, i.e. some products have been designed to secure large corporate networks in their entirety, some have been designed for smaller networks or as complementary devices for an existing security infrastructure. This criteria catalog describes the requirements for an enterprise-wide scaling product. References: Footnotes in brackets, such as [Graham01] indicate where additional information can be obtained. The references can be found in the section IDS Literature. Technical Terms: An event or incident is an occurrence on the network that is assumed to be relevant. Host Agents or Host Intrusion Detection Systems monitor system logfiles, file integrity and sometimes also include kernel-level protection (system- and API call surveillance). Network Node IDSs (NNIDS), sometimes also called stack based IDSs monitor all the data packets that are sent to the host they reside on and those packets that are transmitted by that host. Thus NNIDS are also host based IDSs. Network IDSs (NIDS) monitor the network segments which they are connected to in promiscuous mode, i.e. all packets on the wire are analyzed. Inline IDSs (IIDSs) forward packets after having analyzed the packets for intrusions. Those systems are sometimes also referred to as Gateway IDS (GIDS). A demilitarized zone (DMZ) is the place where your public servers and proxies should be located. Access to the servers in that zone is secured by firewalls, both from the internet and the internal LAN. Access from the internet to the DMZ servers is not as restricted as access from the internet to the internal LAN in general. A signature is a unique data-pattern that can be used to identify an attack.

2002 Detmar Liesen

counter.spy@gmx.de

-6-

2.3. Definition of a generic concept for enterprise-wide IDS deployment

The following part suggests a general concept as a starting point for medium and big size enterprises. This concept defines short-term, mid-term and long-term deployment of IDSs. It is assumed that a security policy identifying and prioritizing network assets and their relative business impact has already been defined.1 To know what you actually want to achieve with IDS, in terms of required scope of deployment and system scalability, is vital for choosing the right system. E.g. you should know if you only want to monitor public servers, internal servers or also clients. Although clients are not mentioned in the concept, there are tendencies in the market to include client surveillance in an enterprise-wide IDS concept for complete coverage. The author assumes that every medium sized network and certainly every large network has a two- or more-staged firewall system with one or more DMZs for public servers and proxies.

See Common Criteria according to ISO/IEC 15408

2002 Detmar Liesen

counter.spy@gmx.de

-7-

2.3.1. Short-term deployment

Deployment of a network IDS (NIDS) outside the perimeter-firewall as an attack detector (early warning system). Deployment of a NIDS inside the perimeter-firewall for detecting attacks that pass the firewall (i.e. for the main purpose of any IDS detecting intrusions) Deployment of HIDS agents and/or stack based Host IDSs (NNIDSs) on DMZ servers and on servers with highest security demands, e.g. ecommerce backends.

2.3.2. Mid-term deployment

NIDS surveillance of all other points where data leave or enter the borders of the corporate sovereign territory, i.e. where subsidiaries and parts of the corporate LAN are connected via leased lines or where dial up services provide remote access (e.g. RAS). NIDS and HIDS deployment on internal servers with high security demands, e.g. Enterprise Resource Planning (ERP) systems and other important servers.

2.3.3. Long-term deployment

HIDS/NNIDS agents on all server systems which are vital for corporate communication and access to corporate data, e.g. MS Exchange servers, domain controllers, file servers and data-warehouses. NIDS surveillance at core switches for maximum coverage at reasonable cost.

Of course this is only a rough concept and the long-term deployment goal will be costly to achieve. But security needs continuity, thus it is important, that an enterprise gets the chance to back the right horse, so that a system is scalable for future requirements and that an architecture be implemented that is not necessarily thrown overboard if the IDS company is acquiered by another - a goal that seems nearly impossible to achieve right now, if we are taking into account the recent consolidation activities in the market. An IDS has to provide the flexibility needed in an ever growing and changing environment. There is no end state for deploying IDS. In a corporate security enhancement process, systems have to be adapted and modified continually to reflect network growth and changes. It should be further taken into account, that the impact of vulnerabilities due to product-specific weaknesses (e.g. software bugs) can be lessened by deployment of complementary systems that employ a different technology and/or originate from a different provider/vendor. Therefore, combined deployment of a company-wide-scaling, easy-to-manage product with another product of lower price is strongly recommended. For the complementary solution an open source variant is recommended.

2002 Detmar Liesen

counter.spy@gmx.de

-8-

Enterprise-wide scaling products should actually provide the interfaces for integration of third party IDSs in the architecture. Some products already include such features, but due to the lack of de-facto standards for IDS data-exchange (IETF/IDWG2 is working on it), those capabilities are very basic. In certain circumstances, a third party solution which can manage IDSs of multiple vendors may be worthy of consideration. For a company-wide scaling product product, a multi-tiered architecture is assumed, that at least comprises three tiers - sensor tier, proxy tier and management tier. The system should be modular and flexible, so that the user is able to decide in which direction connections shall be initiated. This is important when considering outsourcing the IDS management to a managed security provider (MSP) without granting the provider access thru firewalls. Complementary products will not have to fulfill all of those criteria, but they can of course also be evaluated accordingly.

Intrusion Detection Working Group

2002 Detmar Liesen

counter.spy@gmx.de

-9-

3. Criteria Definitions
The conceptual criteria have already been addressed above, here we list the detailed technical criteria.

3.1. Criteria for Installation, Configuration and Management

3.1.1. Must Criteria
An intuitive graphical user interface (GUI) is required Automated installation routines for all core-components must be provided for all supported platforms. This means also that all additional software that is required in order to get the system up and running must be provided by the installation medium itself or be part of the standard distribution of the supported platform. It is undesirable for the administrator to gather dozens of modules from various websites, checking version dependencies, before he is able to install the system and get it running. This is undesirable from the maintenance standpoint, as well. Centralized reinstallation, configuration and updating must be possible. In a distributed network, an IDS administrator cannot physically access each sensor and server, and he probably does not have administrative terminal access to all servers. Thus, most management operations must be able to be executed via a central IDS management console. Free definition of security policies and alert filters is necessary, as well as the existence of predefined policies which can be easily customized. o A policy defines what is allowed and what is not (services, ip addresses etc.) o An alert filter is used in order to exclude certain events from being displayed. That does not mean these events are not being detected any more, it merely means their display is quieted. Events that are being filtered on one console could be displayed on another console or be stored somewhere else. It must be possible to define custom signatures. For this feature the following minimum requirements should be fulfilled: o Definition of source- and destination- IP addresses or address ranges must be possible o Definition of TCP/UDP source- and destination- ports and ICMP type/code o Definition of any combination of IP header flags and options o Definition of any combination of TCP header flags and options o Definition of the payload data that shall be searched (hex or ascii) o Definition of the starting point for the payload search (offset) and the search depth Alerts, header data and payload data must be automatically stored in a central event database. The system should support multiple management consoles for splitting or grouping tasks between multiple analysts and for redundancy. 2002 Detmar Liesen counter.spy@gmx.de - 10 -

 A hierarchical design to the architecture is necessary to provide the scalability and growth that is required in an enterprise environment.

3.1.2. Shall Criteria

HIDS shall provide means for predefinition of the setup and configuration options, so that an unattended setup is possible (It is extremely desirable to have an installation process where the software may be installed on all servers as part of a server build or ghost image, but the software activation be licensed.). Distribution and de-installation of HIDS are apt to happen more frequently than for NIDS. The IDS customer should keep flexibility on where to deploy HIDS, so the licensing shall also take this into account. Limiting licence keys to single hostnames or IP addresses is not suitable for IDS deployment in an environment that grows and changes dynamically as happens in real-life. Automated download of signatures and software updates from the vendors website shall be an option that is integrated into the management GUI. Definition of policy groups or security domains shall be possible. Distribution of signature libraries and policies shall be possible on a per host basis, as well as on a per group basis, so that the group signatures and policies do not have to be pushed to each sensor individually. Storage of event data in a database shall be tiered for optimized performance and to economize on storage volume. Therefore the system shall store full packet information for a predefined time and then remove the data from the event database and store only the following, reduced information in another database: o Date and time o Event name o Protocol (TCP/UDP/ICMP) o Source IP / destination IP o Source ports and destination ports or ICMP type and code The management GUI shall include tools and functions for database administration and maintenance, so that no database specialist is necessary and the IDS analyst is able to concentrate on the job instead of archiving data manually. The HIDS and NNIDS agents shall be available for most operating systems: o MS Windows 2000 Server / Advanced Server, NT 4, XP, .NET Server o Linux (RedHat, Debian, SuSE etc) o *BSD o Sun Solaris o HP-UX o IBM-AIX, VAX-VMS, True64 Easy generation and maintenance of private and public keys or certificates for authentication purposes shall be provided.

2002 Detmar Liesen

counter.spy@gmx.de

- 11 -

3.1.3. Should Criteria

Control of all components thru a command line interface is desirable, even if the main interface for management is the GUI. Some frequently repeated tasks can be done more efficiently from the shell or be automated via cronjobs and scripts. Integration of an additional vulnerability assessment tool or tools for event correlation with Nessus reports would be great. It is desired that there be specialized policies or setups for port 80 (HTTP), port 25 (SMTP) and other common services. Maybe it would be reasonable to autodetect running services with each startup of the server and load the appropriate policies and signature-libraries.

3.2. Criteria for Detection Technology

3.2.1. Must Criteria
Stateful Inspection (tracking connection state) requires o Fragment- and packet stream reassembly: Fragmented IP packets are reassembled correctly, even if fragments are sent out of order or with overlapping fragment offsets TCP segments that are sent out of order or with overlapping data are also correctly reassembled o The system has to be able to determine what packets belong to which session, so that unsolicited traffic can be detected (stateless attacks). Something equivalent must also be performed for stateless protocols, such as UDP and ICMP, i.e. the system is able to detect if such a packet fits into the context of the previous traffic. An ICMP echo-reply is detected as suspicious if no echo-request has been seen before. UDP packets that flow to a machine unidirectionally are also considered suspicious. Stateful Protocol Analysis3 for the most common application protocols requires o traffic normalization (prevents most evasion and insertion4 techniques) o protocol decodes o detection of protocol violations (e.g. generic buffer overflows, unusual requests etc) The system must detect attacks in real-time, so that automated responses are possible (even if it is not recommended in general to use such automated responses).

3 4

[Frederick1]-[Frederick4] [PN98], [RFP]

2002 Detmar Liesen

counter.spy@gmx.de

- 12 -

3.2.2. Shall Criteria

In order to mitigate the problem of ever growing signature databases, the product shall be capable of performing full 7 layer protocol analysis5, or at least some sort of anomaly detection. This is most important for stack based host IDSs (NNDISs) because on productive servers, the IDS must have little impact on the servers performance. The more signatures are in the signature database, the greater becomes the impact on the servers performance. Even if protocol analysis requires more CPU cycles for a basic installation, on a long term the hunger for CPU and memory resources increases more quickly for signature based IDSs. Import or integration of signatures of a free, open signature format shall be possible. Host based systems shall provide file-integrity checks (file tampering detection), e.g. by calculating MD5 checksums for important files that shall not be altered.

3.2.3. Should Criteria

Host based systems should also provide kernel level protection, i.e. detecting and stopping malicious system- and API- calls.

3.3. Criteria for Response - Mechanisms, Reporting and Forensic Analysis

3.3.1. Must Criteria
The following response features must be provided by any enterprisewide scaling IDS that claims to be state-of-the-art: o SNMP traps, email alerts, pager messages, syslog messages o Realtime alerting messages on a central IDS monitor console In-depth backtracking in realtime or batchmode from the central console. The backtracking feature has to provide: o DNS name resolution o NetBios name resolution o IP addresses o MAC addresses The system has to be capable of logging suspicious TCP sessions completely, starting with the packet that triggered an alert. Stateless connections have no information about when a session is over, so the system has to be configurable to simply log a certain number of following packets with the same transport quad information (IP src/dst; UDP src/dst ports).

[Graham01]

2002 Detmar Liesen

counter.spy@gmx.de

- 13 -

 The system has to provide in-depth drill-down capabilities, i.e. based on a comprehensive short message the user can dig into two or more levels of more detailed information. This information must be presented in a clear manner and include: o Source- and destination IP addresses o IP header data (flags and options) o Protocol (TCP/UDP/ICMP) o Numeric source and destination ports or ICMP type/code o Application protocol (HTTP, SMTP, TELNET, FTP) in text format o TCP header data (flags, options, sequence numbers) o Protocol decodes (as far as reasonably possible) o Payload (storage and display optional) The systems GUI has to provide interactive searching and analysis of data from event databases for forensic analysis, e.g. comparing an alert to all other alerts that were generated by that source previously. This is very important for immediate correlation and later analysis. Thus, it must be possible to define the following search and comparison criteria for information retrieval: o Period of time or the exact time of the event o Name of the event o Source and destination IP addresses o Protocol (TCP/UDP/ICMP) o Source and destination ports o Priority of the event

3.3.2. Shall Criteria

The system shall provide the capability of stopping attacks automatically through TCP reset (NIDS) or active blocking (HIDS/NNIDS), although the author does not recommend usage of such features in general. Automatic configuration of router access lists shall also be possible. The system should also provide an interface for triggering custom defined programs, scripts or other actions on certain events. The system shall also provide capabilities to let the security staff interactively perform the above mentioned actions: TCP reset, blocking and ACL update. This provides the personnel more control over response mechanisms, so that automated blocking can be deactivated and misconfiguration due to bad blocking rules is minimized. Of course, this will not be realtime. In order to give the security staff more time for a well-reflected response (which can also be to do nothing at all but watching and logging) HIDSs and Inline ID systems shall provide capabilities of slowing down suspicious connections. This could be a pre-stage before the security administrator finally decides to kill the connection or to decide that a false alert has been raised and the throttle can be released. All the above mentioned countermeasures shall be able to be activated or deactivated on a per rule (signature) basis.

2002 Detmar Liesen

counter.spy@gmx.de

- 14 -

 The monitoring console GUI shall be designed in such a way, that even during high activity periods, individual events can still be selected and analyzed. It has been found during tests, that some systems refresh the screen too often during such periods so that the context menu disappeared before an item could be selected. Either the system shall provide a freeze function for that purpose or (preferably) it should simply increment a counter for events of the same type. Interoperability with other infrastructure components, such as routers, firewalls (for reconfiguration) and network management consoles has been demanded by many IDS customers in the past. The authors opinion on this is that, being state-of-the art, this shall be provided by any decent enterprise-wide scaling IDS, but it has been proven that in real-life this is not as important as considered in the past. An IDS should not control the firewall and a network management administrator (infrastructure department) is not a security specialist in most cases. Also, most network management systems are not really designed to provide good intrusion analysis capabilities. The system shall provide support for correlation of data from several IDSs (NIDS, NNIDS and HIDS). This correlation should be done dynamically to minimize the chance of stale information which defeats this functionality. This means in detail: o Portscans: which ports did the attacker scan and what method did he use? Which open ports did he actually hit and detect? o Aggregation and correlation6 of sporadic events from different sources, for detection of extremely slow portscans and sweeps which probably used spoofed addresses o Comparison of the type of attack with the services that are provided by the targeted system and software versions/known vulnerabilities for being able to determine, if the attack could be successful. o Comparing analysis of events that are detected outside a firewall and inside a firewall. That way you can determine if the source of attacks that are detected on the inside has tried other attacks that were blocked by the firewall. This helps making a profile of the hacker. If you are seeing various portscans and scripted attacks outside and only some of them have actually passed the firewall, you can consider this a script kiddy with minor skills or automated worm activity (but do not underestimate the danger!). If the attack you detected on the inside was a dangerous one and outside you can see nothing more, you can consider this originating from a hacker who knows what he has to do in order to bypass the firewall without much noise.

[SHM]

2002 Detmar Liesen

counter.spy@gmx.de

- 15 -

3.3.3. Should Criteria

Sending alerts via SMS (short message service) If the HIDS/NNIDS provides no file-integrity checks itself, it should provide an interface for Tripwire or similar tools. The system should provide printable reports of various degrees of detail, e.g. charts and graphs of high level information for executives o Number of attacks vs. type of attacks o number of attacks vs. priority/severity o time and date vs number of attacks In adddition, more detailed reports for security staff and administrators o Event names o Detailed event descriptions o IP address data o TCP/UDP port numbers or ICMP type/code Generation of trending-analysis reports

3.4. Criteria for the Security of IDSs

3.4.1. Must Criteria
Communication between the IDS components (sensors, middle tier and management) must be encrypted. Strong authentication (via key exchange or challenge) is required The method of communication must not provide any information about type and version of the IDS in use, be it explicit (e.g. clear-text messages) or implicit (e.g. unique behaviour or patterns). Thus, it can be prevented, that a hacker exploits product/version -specific vulnerabilities or draws a map of the network parts that host IDS components. Network IDSs must behave stealthy, i.e. transmission of data via the sniffing interface is prohibited, unless it is configured intentionally (TCP resets could be transmitted by this interface, which is not recommended by the author). In order to achieve stealth, at least one of the following setups must be possible: o Configuration of the NIC (network interface card) without any IP address o Disabling TCP/IP for the NIC o Unbinding the NIC completely from the IP stack This is only possible, if the product provides its own capture drivers or if it has got an interface for the libpcap (winpcap) drivers.

2002 Detmar Liesen

counter.spy@gmx.de

- 16 -

 Using active response mechanisms, such as dynamic firewall reconfiguration or TCP reset by the NIDS and active blocking by the HIDS/NNIDS is not recommended by the author, unless you know exactly what the possible consequences are and you decide that it is worth taking the risk for your individual deployment goals (you will have to check this for each signature that utilizes active response). However, if you are considering to use such responses, the following criteria have to be met: o Blocking has to work in such a way, that packets are silently dropped, without letting the hacker know what happened. o The protecting mechanism is only allowed to block those packets, that belong to the attack themselves, i.e. the packets that have been identified to be an attack or part of an attack. Such packets have to be identified via their signature. The following packets that belong to the attack but cannot be identified by a signature (because sometimes, only the first packets have a distinctive signature) have to be identified by IP address, port numbers (or ICMP type/code) and sequence numbers (for TCP). Relying solely on the IP address does not suffice and could be an invitation to DoS attacks. The author was able to DoS a NNIDSprotected server by simply flooding it with spoofed packets, generated by snot, a testing tool for snort (although the vulnerable IDS was not Snort). The IDS blocked all spoofed IP addresses for half an hour by default. o Legitimate traffic must not be affected in any way. o TCP reset packets must not only spoof the IP addresses and TCP sequence numbers, but also the MAC addresses (for some operating system, this might not be possible). Otherwise a hacker could easily identify where the reset packet has come from, provided that he is on the same subnet (internal hacker), and focus his mind on this system. It should be considered that TCP reset packets can be easily ignored by the attacker if he uses a software package that filters such packets. Thus, the reset feature has to reset both client and server. Evaluations by the author yielded that TCP reset packets of one IDS contain the customer ID by default. If such features are provided by the system, it must be possible to switch this off. However, IDSs shall not have such features activated per default in the first place.

2002 Detmar Liesen

counter.spy@gmx.de

- 17 -

3.4.2. Shall Criteria

If a component fails, it shall be restarted automatically and the management application shall notify the administrator that a problem has occurred. If communication between the components is interrupted, an alert shall be raised.

3.4.3. Should Criteria

It is desirable that the IDS automatically ask the administrator to renew keys and certificates after a preconfigured time interval (some months). It is desirable that the IDS provides help for hardening the operating system during install-time.

Finally, as a rule of thumb, an IDS shall not have any potentially dangerous features activated by default.

2002 Detmar Liesen

counter.spy@gmx.de

- 18 -

IDS Literature
books: [Cox01] authors: Windows 2000 Security Handbook Phil Cox, Tom Sheldon

organisation: Security Experts ISBN: 0-07-212433-4 Osborne/McGraw-Hill [Northcutt] IDS: Intrusion Detection-Systeme Spurensuche im Internet (german edition of IDS an analysts handbook) Stephen Northcutt Judy Novak

Authors:

organisation: SANS GIAC mitp ISBN: date: [Stevens1] author: 3-8266-0727-9 2001 TCP/IP Illustrated Volume 1 The Protocols W. Richard Stevens Addison Wesley ISBN: 0201633469

2002 Detmar Liesen

counter.spy@gmx.de

- 19 -

[Stoll]

Kuckucksei (german edition of cuckoos egg) Clifford Stoll Fischer

Authors:

ISBN: magazines: [NC1701]

3-596-13984-8

Die den Dieb einfangen

organisation: Network Computing / Real-World-Lab edition : [RB01] authors: 17 / 2001 Wenn der Virenscanner nicht mehr reicht Jrg Rensmann, Markus Bauer PC Professionell edition : 05 2001

presentations: [Graham00] Authors: Carnivore - Detailed analysis Robert Graham (CTO NetworkICE) Toorcon `00 San Diego Link: http://www.robertgraham.com/slides/00toorcon.ppt

[Graham01] authors:

SideStep IDS evasion vs. protocol-analysis Robert Graham (CTO NetworkICE, now ISS) 01-march-30 CanSecWest/CORE1

link:

http://www.robertgraham.com/slides/0103cansec.ppt

2002 Detmar Liesen

counter.spy@gmx.de

- 20 -

[Roesch01]

Snort bh-usa-01-Marty-Roesch.ppt Martin Roesch

authors:

organisation: Sourcefire.com date: 2001

other publications: [HK98] Grundlagen, Forderungen und Marktbersicht fr Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS) debis IT Security Services Rabinstrae 8 D-53111 Bonn authors: Dok-Ref: version: date: link: Dr. Josef von Helden, Dr. Stefan Karsch IDS-10-03 1.4 19.10.98 http://www.bsi.de

[NP99] authors:

Experience with EMERALD to DATE Peter G. Neumann and Phillip A. Porras

organisation: Computer Science Laboratory SRI International 1st USENIX Workshop on Intrusion Detection and Network Monitoring date: pages: April 1999 7380

2002 Detmar Liesen

counter.spy@gmx.de

- 21 -

[PN98]

Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection Thomas H. Ptacek Timothy N. Newsham

authors:

organisation: Secure Networks, Inc. date: link: January, 1998 unter anderem erhltlich unter: http://www.snort.org

[NSS00]

Intrusion Detection & Vulnerability Assessment Group Test (Edition 1) An NSS Group Report first published December 2000 The NSS Group; Oakwood House, Wennington, Cambridgeshire PE28 2LX England www.nss.co.uk Intrusion Detection Systems Group Test (Edition 2) An NSS Group Report First published December 2000 (Edition 1) Revised December 2001 (Edition 2 V1.0) The NSS Group; Oakwood House, Wennington, Cambridgeshire PE28 2LX England www.nss.co.uk

date:

link: [NSS01]

date:

link:

[LaPadula00]

CyberSecurity Monitoring Tools and Projects A Compendium of Commercial and Government Tools And Government Research Projects Leonard J. LaPadula MITRE, Center for Integrated Intelligence Systems, Bedford, Massachusetts

authors:

date: link:

August 2000 www.mitre.org

2002 Detmar Liesen

counter.spy@gmx.de

- 22 -

[Poppi02] authors: link:

Snort Statistics HOWTO Sandro Poppi http://www.lug-burghausen.org/projects/Snort-Statistics/SnortStatistics-HOWTO.pdf

[RFP] authors: link: [Vigilinx]

A look at whiskers anti-IDS tactics Rain Forest Puppy; rfp@wiretrip.net http://www.wiretrip.net/rfp/ Security Monitoring Realities and Futures A White Paper from Vigilinx http://www.vigilinx.com

link:

[Ranum01] authors:

Experiences Benchmarking Intrusion Detection Systems Marcus J. Ranum (CTO NFR Security, Inc.) NFR Security

date: link: [Cheung99]

December 2001 http://www.nfr.com The Design of GrIDS: A Graph-Based Intrusion Detection System Steven Cheung, Rick Crawford, Mark Dilger, Jeremy Frank, Jim Hoagland, Karl Levitt, Jeff Rowe, Stuart Staniford-Chen, Raymond Yip, Dan Zerkle

authors:

organisation: Departement of Computer Science, University of California at Davis, CA 95616 date: January 26, 1999

2002 Detmar Liesen

counter.spy@gmx.de

- 23 -

[Axelsson00]

Intrusion Detection Systems: A Survey and Taxonomy Stefan Axelsson

authors:

organisation: Departement of Computer Engineering Chalmers University of Technology Gteborg, Sweden date: [RLM] authors: 14 March 2000 Intrusion Detection with Neural Networks Jake Ryan, Departement of Computer Sciences, University of Texas at Austin; Meng-Jang Lin, Departement of Electrical and Computer Engineering, University of Texas at Austin; Risto Miikkulainen, Departement of Computer Sciences, University of Texas at Austin; Intelligent Agents for Intrusion Detection Guy G. Helmer, Johnny S. K. Wong, Vasant Honavar, Les Miller

[HHM] authors:

organisation: Iowa State University, Ames, Iowa 50011 [Forensics] Intrusion Detection Systems and A View To Its Forensic Applications

organisation: The University of Melbourne, Departement of Computer Science, Parkville 3052, Australia [NBCW] authors: An Intrusion Detection System to Mobile Phone Networks Mirela Sechi Annoni Notare, Federal University of Santa Catarina, Brazil Azzedine Boukerche, University of North Texas Fernando Augusto da Silve Cruz, Federal University of Santa Catarina, Brazil Carlos Becker Westphall, Federal University of Santa Catarina, Brazil

2002 Detmar Liesen

counter.spy@gmx.de

- 24 -

[deCastro]

Artificial Immune Systems: Theory and Applications Leandro Nunes de Castro

authors:

organisation: State University of Campinas UNICAMP School of Computer and Electrical Engineering FEEC VI-Brazilian Symposium on Neural Networks [CS94] authors: Defending a Computer System using Autonomous Agents Mark Crosbie, Gene Spafford

organisation: COAST Laboratory, Dept. of Computer Sciences, Purdue University, West Lafayette IN 47907-1398 date: [MT00] authors: 11 March, 1994 Benchmarking Anomaly-Based Detection Systems Roy A. Maxion, Kymie M.C. Tan

organisation: Dept. of Computer Science, Carnegie Mellon University, 5000 Forbes Avenue Pittsburgh, PA 15213 USA 1st International Conference on Dependable Systems & Networks: New York June 2000 [Frank] Artificial Intelligence and Intrusion Detection: Current and Future Direction Jeremy Frank

authors:

organisation: Division of Computer Science, University of California at Davis, Davis, CA. 95616 [Paxson] Bro: A System for Detecting Network Intruders in Real_Time Vern Paxson

authors:

organisation: Lawrence Berkeley National Laboratory, Berkeley, CA and AT&T Center for Internet Research at ICSI, Berkeley, CA

2002 Detmar Liesen

counter.spy@gmx.de

- 25 -

[JLA] authors:

A Fault Tolerance Approach to Survivability Sushil Jajodia, Peng Liu, Paul Ammann

organisation: Center for Secure Information Systems, George Mason University, Fairfax, VA 22030-4444 [HF98] Immunizing Computer Networks: Getting All the Machines in Your Network to Fight the Hacker Disease Steven A. Hofmeyr, Stephanie Forrest

authors:

organisation: Dept. of Computer Science, University of New Mexico, Albuquerque date: [KB] November 2, 1998 The Human Immune System and Network Intrusion Detection Jungwon Kim and Peter Bentley

authors:

organisation: Dept. of Computer Science, University Collge London Gower Street, London, UK [HF] authors: Immunology as Information Processing Stephanie Forrest Steven A. Hofmeyr Mobile Agents In Intrusion Detection And Response W. Jansen, P.Mell, T. Karygiannis, D. Marks

[JMKM00] authors:

organisation: National Institute for Standards and Technology Gaithersburg, MD 20815 12th Annual Canadian Information Technology Security Symposium, Ottawa, Canada, June 2000

[Bass]

Intrusion Detection Systems & Multisensor Data Fusion: Creating Cyberspace Situational Awareness Tim Bass

authors:

2002 Detmar Liesen

counter.spy@gmx.de

- 26 -

[Cannady] authors:

Artificial Neural Networks for Misuse Detection James Cannady

organisation: School of Computer and Information Sciences, Nova Southeastern University, Fort Lauderdale, FL 33314 [Axelsson99] authors: Research in Intrusion-Detection Systems: A Survey Stefan Axelsson

organisation: Dept. of Computer Engineering, Chalmers University of Technology Gteborg, Sweden date: revised: [Bschkes] authors: December 15, 1998 August 19, 1999 Angriffserkennung in Kommunikationsnetzen Diplom-Informatiker Roland Bschkes Von der Fakultt fr Mathematik und Naturwissenschaften der Rheinisch-Westflischen Technischen Hochschule Aachen zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften genehmigte Dissertation. date: [Allan02] authors: Mai 2001 Intrusion Detection Systems (IDS): Perspective Ant Allan

organisation: Gartner Research date: 4 January 2002

[FV02]

An Analysis of Fast String Matching Applied to Content-Based Forwarding and Intrusion Detection Mike Fisk, George Varghese IEEE INFOCOM 2002

authors:

2002 Detmar Liesen

counter.spy@gmx.de

- 27 -

[SHM] authors:

Practical Automated Detection of Stealthy Portscans Stuart Staniford, James A. Hoagland, Joseph M. McAlerney

organisation: Silicondefense, 513 2nd Street, Eureka, CA 95501

[FV01] authors:

Fast Content-Based Packet Handling for Intrusion Detection Mike Fisk (mfisk@lanl.gov), George Varghese (varghese@cs.ucsd.edu)

organisation: Computing, Communications, and Networking Division, Los Alamos National Laboratory Department of Computer Science and Engineering, University of California San Diego UCSD Technical Report CS2001-0670, May 2001 [Roesch] Snort - Lightweight Intrusion Detection for Networks lisapaper Martin Roesch

authors:

organisation: Snort.org [Laing00] How To Guide-Implementing a Network Based Intrusion Detection System Brian Laing (brian@laing.org)

authors:

organisation: Internet Security Systems (ISS) date: [Yarochkin00] authors: 2000 Snortnet A Distributed Intrusion Detection System Fyodor Yarochkin

organisation: Kyrgyz Russian Slavic University, Bishkek, Kyrgyzstan date: June 26, 2000 Network Intrusion Detection Signatures, Part One Karen Kent Frederick

[Frederick1] authors:

organisation: NFR Security date: December 19, 2001

2002 Detmar Liesen

counter.spy@gmx.de

- 28 -

[Frederick2] authors:

Network Intrusion Detection Signatures, Part Two Karen Kent Frederick

organisation: NFR Security date: [Frederick3] authors: January 22, 2002 Network Intrusion Detection Signatures, Part 3 Karen Kent Frederick

organisation: NFR Security date: February 19, 2002

[Frederick4] authors:

Network Intrusion Detection Signatures, Part Four Karen Kent Frederick

organisation: NFR Security date: March 5, 2002

[MMM] authors:

A denial-of-service resistant intrusion detection architecture Peter Mell, Donald Marks, Mark McLarnon

organisation: Computer Security Division, National Institute of Standards and Technology Computer Networks 34 (2000) 641-658 [Overill] Reacting to Cyberintrusions: Technical, Legal and Ethical Issues Richard E. Overill

authors:

organisation: Department of Computer Science and International Centre for Security Analysis, Kings College London

2002 Detmar Liesen

counter.spy@gmx.de

- 29 -

[Staniford] authors:

Intrusion Correlation A Sketch of the problem Stuart Staniford

organisation: Silicon Defense date: November, 05, 2001

Credits
Many thanks to the snort community and the dragon community, where I have learned quite a bit and whose members have helped a great deal answering and discussing various questions. The ISSForum and focus-ids forum (securityfocus.com) are a great source of information as well. Thanks go also to all IDS vendors/developers who provide free download of product papers and documentation, as well as evaluation software. Special thanks to My boss (for providing the opportunity to write a diploma thesis on IDS) Sandro Poppi (for some really cool discussions about IDS and help on various questions) Erek Adams (for his efforts on the snort-users mailinglist) Martin Roesch (for creating and improving snort) Chris Green (for his mailinglist- and development- efforts) Robert Graham (for sharing his knowledge with the public) NSS (for providing free evaluation- and benchmark reports) Bob Walder of NSS (for discussing the future of NSS Group tests, regarding gigabit ethernet and NIDS in switched environments) Andrew Talisker (for one of the most complete lists of commercial and non-commercial IDSs) All persons who reviewed this paper o Sandro Poppi (for reading and commenting the first, german edition) o My father and my sister (for correcting typos) o Maria Teigeiro (corrections and enhancements) o Linda from Australia

There are a lot more people who could be named here, because of their commitment in the communities.

2002 Detmar Liesen

counter.spy@gmx.de

- 30 -

The Author

tux@earth# whoami Detmar Liesen

o worked as an industrial mechanic, assembling special machines for industry automation (measurement and calibration of thermal and magnetic circuit breakers) o gave up job for studying electric and electronic engineering at the Rheinische Fachhochschule Koeln at Cologne, Germany o focus on communication technologies after three semesters o focused on IT security during the last year of studies (vulnerability assessment, firewall, IDS) o gathering practical experience in networking and IT security at a german company with over 11.000 employees and more than 80 subsidiaries worldwide. o February 15th: begin of diploma thesis on Conception for Deployment of Intrusion Detection Systems in a Corporate Network for the same company o Mai 15th: finish of diploma thesis o July 15th: diploma colloquium o future plans: working as an IDS administrator and intrusion analyst, becoming an expert for intrusion analysis and incident handling, developing and implementing enterprise-wide security concepts

2002 Detmar Liesen

counter.spy@gmx.de

- 31 -