Evaluation Criteria

---

In the following few sections, we will discuss various criteria that enable you to choose and evaluate the intrusion detection system that best meets your requirements [Jackson1-99]. I would like to note immediately that all requirements to the intrusion detection system can be classified into 3 groups - mandatory, desirable, and optional. Since there is no system that can satisfy all the requirements provided below, we recommend that you choose the one that meets mandatory requirements, regardless of the large number of optional requirements met. It is impossible to determine the necessity of satisfying specific criterion beforehand - your choice must depend on a wide range of conditions. As was shown earlier in this chapter, it also depends on the type of your company. The complete list of all evaluation criteria, along with their priorities for various users, will be provided in the end of this section. Certainly, this list is not indisputable truth, and can be changed according to your specific requirements.

All evaluation criteria can be classified into the following groups:

• Intrusion detection

• Responses to attacks

• Management

• Performance

• Self-protection

• Installation and configuration

• Additional capabilities

• Manufacturer/vendor

These groups form the basis for testing and evaluating intrusion detection systems.

The Point of Installation

The first criterion is the possible network location at which to install an intrusion detection system. As was mentioned in Chapter 6, there are two main locations for installing intrusion detection systems - on a network segment and on a specific host. Depending on the resource that needs protection (see Table 9.1), you should select either a network-level intrusion detection system or a host-level intrusion detection system operating at the OS, DBMS, or application level. For example, if you need to ensure file server security, integrity control systems must have priority. For application servers, systems for controlling log files are of primary importance. Note that in this case, the chosen system must control both system logs (EventLog or Syslog) and other log files. To secure web servers, you might choose two intrusion detection systems, based on the server location. For example, if your web server resides in a demilitarized zone along with other hosts (SMTP, FTP, and DNS servers), then the whole DMZ is controlled by a network-level intrusion detection system. At the same time, a specific web server can be controlled by the event log management system. If only one web server is installed in the DMZ, it makes sense to use an integrated solution, joining event log control and intrusion detection (such as RealSecure Server Sensor).

If it is necessary to protect both network and system resources, it would be best to choose an intrusion detection system that has both network and system components. The RealSecure Protection System family of products - which enables you to detect attacks at the network level (RealSecure Network Sensor), at the server level (RealSecure Server Sensor), and on workstations (RealSecure Desktop Protector) - is an example of such solution. Another representative of these types of products is a solution from Symantec, which supplies NetProwler network-level IDS and Intruder Alert (for controlling log files). Cisco Systems also provides solutions, including Cisco IDS and the Cisco IDS Host Sensor. However, at the moment of this writing, systems from the last two manufacturers could not be controlled from a single management console.

Information Sources and Methods of Analysis

Information sources (network traffic, log files, user activities, and so on), along with methods of analysis (misuse and anomaly detection), allow you to draw conclusions as to the existence of an active attack. They were covered in detail in Chapter 4.

Processing Time

The next important criterion influencing IDS selection is the time it takes for the system to actually processes data obtained from the specified sources of information.

Batch Processing

Security scanners, classical intrusion detection systems operating at levels higher than the network level, and integrity control systems operate according to this principle. When using batch-oriented (or interval-oriented) approaches, the auditing mechanisms of the OS, DBMS, and applications (or integrity control mechanisms) log information on each event in the appropriate log files, and the intrusion detection system periodically analyzes these logs to detect cases of misuse, anomalous activity, or checksum discrepancy. The advantages and drawbacks of tools working in batch mode are outlined in Table 9.2.

Table 9.2. Advantages and Drawbacks of Intrusion Detection Systems Operating in Batch Mode

Advantages	Drawbacks
Batch processing systems are suitable for networks where there is a relatively low risk of suffering from various attacks. Most frequently, users of such networks are interested in explaining problems rather than in an immediate response to suspicious events. Consequently, a batch-oriented analysis can be combined with another investigation process (such as identifying the attack source) in order to locate the individual responsible for the incident and start the appropriate inquiry process.	Users will rarely receive warnings and alerts on active attacks, since events are registered in the log files only after they actually occur. Thus there is practically no possibility of active incident registration in real-time mode for minimizing the damage caused by an attack.
Schemes of batch-oriented analysis result in a lower workload on the systems in comparison to a real-time analysis. This is especially true when the intervals are short and, consequently, the amounts of collected data are relatively small.	Information gathering in batch-oriented analysis requires quite a large amount of free disk space in the system performing analysis. This space is required to store the records of all events that take place during the interval between two starts of the batch processing system.
The batch-oriented approach to information gathering and analysis is preferable for organizations where human and system resources allocated for ensuring information security are limited. It is quite probable that organizations where there is no specially assigned employee(s) responsible for information security (or there is no way to have 24-hour monitoring) will find that real-time security alerts generated by intrusion detection systems are not really so necessary.	This method is inefficient when the auditing subsystem does not register all events (or some events are omitted in the course of logging).
Most contemporary methods related to gathering information on computer crime were developed based on the manual analysis of information gathered in batch mode.

Working in Real-Time Mode

In this context, "real-time mode" means that the intrusion detection process is done relatively quickly, and the security administrator can manage to nip the attack in the bud. Systems operating in real-time mode provide a wider range of security warnings than systems operating in batch mode. Besides this, they give you the ability to foresee variants of automatic responses to detected attacks. Typical responses vary widely - from an ordinary security notification, to the termination of the connection to the attack source, or reconfiguring network equipment aimed at preventing any attempts at repeated attacks from a specific address. All systems of this type have their strong and weak points (Table 9.3).

Table 9.3. Advantages and Drawbacks of Intrusion Detection Systems Operating in Real-Time Mode

Advantages	Drawbacks
Depending on the analysis rate, attacks can be detected rather quickly, which enables the security personnel to stop them just in time. Quite often, attacks are detected before they achieve their goals.	Such systems require specially assigned security personnel to constantly monitor the messages generated by the IDS.
Intrusion detection systems of this type provide quite a wide range of possible variants of responses to detected attacks.

Architecture

As I mentioned in Chapter 6, all existing intrusion detection systems - both network-and host-level - are based on the "agent-manager" scheme. Configurations in which both console and sensor run on the same computer are quite rare. This is characteristic of outdated and obsolete intrusion detection systems, such as SessionWall-3, or freeware systems such as Snort. A distributed architecture in the intrusion detection system provides for good scalability in the corporate network, including the installation of sensors in remote affiliates and offices. However, it would be a mistake to think that you should always choose distributed systems. In small businesses, for example, you can do just fine with an autonomous agent, and a distributed architecture is not required.

Supported Platforms

This evaluation criterion does not need detailed consideration, since the requirement of supporting the hardware and software platforms, network protocols, etc. that have been adopted in your organization is obvious.

Intrusion Detection

This group includes the following criteria:

• Number of detected attacks

• Updates to attack signatures

• Capabilities of creating custom attack signatures

• Monitoring additional events

• Notifications on false negatives

• Processing fragmented traffic

• Reference material on each attack

• Extended capabilities of customizing attack signatures

The Number of Attacks That Can Be Detected

It is strongly recommended that you never use the number of attacks that can be detected as the main factor when choosing an intrusion detection system. This parameter is much too subjective. To illustrate this statement, let us consider the following situation. Suppose that we have a computer that is vulnerable to infection by viruses and we must choose between two antiviral tools - Kaspersky Antivirus and AntiDIR. The first system detects about forty thousands viruses (as of the time of writing). However, it is not freeware. The second program is free, but is only able to detect one virus - DIR. The choice might seem obvious - Kaspersky Antivirus. However, things are not that simple in practice. For example, if you can determine for sure that the protected computer can only be infected with a DIR virus, then there is no reason to opt for Kaspersky Antivirus. In this case, AntiDIR is obviously preferable. First of all, it is freeware. Second, it works faster when detecting and eliminating the DIR virus, since it is optimized specifically for this purpose. Despite the fact that Kaspersky Antivirus finds and eliminates thousands of other viruses along with DIR, here its capabilities are pointless. A similar analysis can also be done for intrusion detection systems. If your network is based on the Windows platform and you have no hosts running other operating systems, you do not need an IDS that is capable of detecting attacks on UNIX hosts. These functional capabilities are redundant, and will probably never be used. Because of this, you should not rely on the number of attacks that can be detected as the only criterion when choosing an intrusion detection system. You should also note that IDS manufacturers use different approaches to evaluating the number of attacks that can be detected. Without naming specific vendors, I would like to provide one illustrative example. Three years ago, 25 NIS checks in one of the security scanners available on the market at that time were equivalent to a single check implemented in another scanner. Currently, with the appearance of the CVE database, the situation has improved, but you should still bear this fact in mind.

Signature Updating

Since attacks, just as vulnerabilities, are being constantly updated, it is important to update the intrusion detection database in order to detect attacks efficiently. This is just as important as updating antiviral software or installing patches, hotfixes, and Service Packs for operating systems. The same applies to the intrusion detection system. Only when regular and timely updates are performed will the system be able to provide the desired level of network security. Ideally, there should be no delay between the publishing of information on a particular attack by the various hacking information sources available and the inclusion of this signature into the attack database. Better yet, if the developers update their system before information on new vulnerabilities becomes common knowledge, they can stay one step ahead of the intruders. In practice, however, this does not always work so smoothly and seamlessly. It is the task of the manufacturer (or vendor) and user of the intrusion detection system to make this interval as small as possible. By the way, I would like to say that you should not rely completely on the vendor's ads and statements like "the system is able of detecting new and unknown attacks." Remember that system developers (who probably would be glad to provide you with honest and unbiased information on their product) are not the ones who are actually selling the IDS. On the contrary, this job is delegated to sales representatives, whose task is to sell as much as they can.

Despite the fact that the number of vulnerabilities or attacks detected by the intrusion detection system ca not serve as a criterion, all aspects related to the updating of the vulnerability database are extremely important, and directly influence the IDS's efficiency. It would seem that once a mechanism for adding custom attack signatures has been put in place, updating and correcting the IDS database are less important. However, as statistics show (for example, those published on the WhiteHats server, http://whitehats.com), this is not the case. As it turns out, over 52.31% of IDS users do not know how to create custom signatures. Another 34.23% of the user community does not even know that there are ready-to-use attack and vulnerability signature databases available for download from the Internet as freeware. Thus, over 86.54% of users do not create customized rules, even when their intrusion detection system provides such a mechanism.

Frequency of Updates

The first parameter that should be taken into account when evaluating the signature updating subsystem is the frequency of updates. The more frequent is the updating process (no less than once per month), the more secure are your resources, and the higher is the probability of your system being able to thwart new attacks invented by intruders.

Update Method

The method used to update your signature database is a second important factor for consideration. It is particularly important in distributed networks, where there are a large number of remote affiliates and a lack of qualified personnel. In this case, the question of updating in a timely manner not only the signature database, but also the sensor kernel, is of primary importance.

There are several types of updates available for intrusion detection systems (Fig. 9.3), which are briefly described below.

• Via diskette or CD-ROM. This method is the simplest to implement, but at the same time is the most inconvenient. Here, either the entire sensor or some of its components (such as the signature database) must be rebuilt. The Cisco Secure IDS operates according to this principle.

• Via e-mail. Updates are performed via the SMTP protocol (usually, only the signatures database is updated).

• Using an FTP or HTTP server. In this case, the component update must be downloaded from an FTP or, more frequently, HTTP server. In the latter case, either the HTTP or HTTPS protocol is used, HTTPS allowing for the establishment of a secure connection between the server and the component to be updated. This approach is used in the RealSecure intrusion detection system.

Fig. 9.3. Mechanisms for updating intrusion detection systems

Updates can be provided by both the IDS developer and the vendor. Large companies might support their own update servers, on which they publish all new releases of system components. From this server, the data are further distributed to sensors installed in the client's corporate networks (Fig. 9.4). This is especially convenient for companies where Internet access from some hosts is not allowed.

Fig. 9.4. Update center in a corporate network

The ways of obtaining the latest signatures desribed above can be set up using either manual or automatic mode. In the first case, the security administrator (or intrusion detection system operator) visits an HTTPS or FTP server from which he or she downloads the required modules (or orders them on a CD). Then the administrator updates the selected components of the intrusion detection system manually. The chief drawback of this method is the possibility that the administrator will forget to perform the update, which might result in a discrepancy between the current attack database version and the situation in the hacking community. Furthermore, if an administrator waits for the CD containing the updates to be delivered, this itself creates a delay. Also, difficulties related to delivery might arise if customs interrupts the CD shipment. Using the second approach, updates are carried out automatically via the Internet. A specialized module, which starts up according to a predefined schedule or in response to a command issued from the update center, downloads the updated version of the required component and installs it.

Secure Updates

There is little need to stress the fact that all updates - even those obtained from the manufacturer - must be duly protected. This can be done by transmitting the data via a secure channel, by using data integrity control with specialized algorithms (such as MD5), etc.

Companies Spread the Nimda Internet Worm 

In June 2002, Microsoft reported that it had detected the Nimda Internet worm in the distribution set of Visual Studio .NET. According to the information provided by Microsoft, the problem concerns exclusively Korean distribution sets of various Visual Studio .NET versions, as well as the Visual Basic .NET, Visual C++ .NET, and Visual C# .NET development environments. The worm is contained in one of the compressed help files of the Application Center Test component.

A similar situation has arisen with GameSpy.com - the popular gaming site that gave quite an unpleasant surprise to its users. Gaming fans that downloaded the GameSpy Arcade 1.09 program from that site got the Nimda worm along with it.

U.S State Department Spreads Viruses 

On May 21, 2002, the U.S. State Department admitted the fact of the presence of a computer virus that was spreading within the State Department and had infected computers of a large number of mass media and government organizations. The virus in question was one of the Klez versions, spreading via the Internet in the form of e-mail attachments. The virus does not destroy files stored on the computer, but can disrupt the operation of the mailing system in corporate LANs. Hundreds of infected e-mail messages were sent with return address of the State Department PR service. Supposedly, the virus first infected the computer to which e-mail from the State Department is delivered, and thus gained access to the mailing list used in the State Department. After that, the virus sent copies of itself using a fake return address. Virus makers often use such a trick, since people tend not to trust messages received from unknown persons. The State Department sent official apologies to all companies, organizations, and individuals that suffered from this virus attack.

Update Notification

The manufacturer or vendor must inform system users of new releases of or updates to the intrusion detection system. This notification can be sent by various methods (via e-mail, a mailing list, from the web server, at a conference, or by normal mail), depending on the circumstances and on the capabilities of the notifying and notified parties.

Declining Updates

When evaluating intrusion detection systems, users rarely pay attention to the capability of declining updates (or rolling the system back to its previous state).

Although this mechanism seems unimportant at first glance, this is not the case. I will provide a personal example. Until recently, I was using antiviral software that satisfied my requirements on all parameters. However, at some point, the software's virus signature database was complemented by signatures of the programs such as Remote Administrator, BackOrifice, NetBus, etc. This turned into a nightmare. The antiviral software began to warn me constantly of the presence of those programs on my hard disk. Even worse, besides the persistent warnings, the antiviral monitor would not allow me to start these programs, despite the fact that I needed them for teaching purposes. When I attempted to disable the detection of these programs, I discovered that there was not an option allowing me to do so. The ability to roll back to the setup before the database was updated with the signatures of these programs was not there. I ultimately stopped using that specific antiviral software, despite all of the advantages it offered. I would have gladly continued using it if it had simply allowed me to decline the updates.

Creating Custom Events

No matter how frequently the signature database for attacks or vulnerabilities is updated, there is always some delay between the time when a new attack or vulnerability is reported and the arrival of the signature for it. Reducing this delay is one of the most important problems that the department operating the IDS must deal with. One possible method of solving this task is to create custom signatures. There are two ways of doing this - using special attack (vulnerability) description language, or by directly specifying the attack parameters with the use of a specialized subsystem.

Mechanisms for describing custom checks, attacks, vulnerabilities, or other controlled events are very useful for system administrators who are trying to track vulnerabilities described in Bugtraq or other mailing lists. Thanks to this capability, it becomes possible to quickly formulate a new rule and apply it within the network. It should be pointed out, however, that although this capability is very useful, it is rather difficult to use in practice. There are very few organizations (other than government organizations, intelligence services, or organizations specializing in the field of information security) that can afford to hire the group of professionals necessary to perform research work in the field of new checks and detecting new attacks or vulnerabilities (or even a single professional of this qualification level). As for commercial companies, the employees responsible for information security usually have no serious background in programming. Besides this, their duties include quite a wide range of routine tasks (such as control over user activities, specifying access rights and privileges, etc.), and they simply have no time for such creative and difficult work as developing new signatures and rules.

However, if the intrusion detection system provides a vulnerability description language, this can be considered an additional advantage. The following few sections will provide brief descriptions of the most common languages that allow you to describe an attack or vulnerability. More detailed coverage of this topic is provided in [Eckmann1-00]. Unfortunately, these languages are rather exclusive, since signatures written in these languages can not be ported to other systems. The only exception to this is the language used in the Snort IDS, since this language can be understood by several other intrusion detection systems, such as RealSecure Network Sensor.

P-BEST

P-BEST (Production-Based Expert System Toolset) is an expert system providing a specialized language that can be used for describing various security policy violations. This system was developed by Alan Whitehurst, and was used as part of the MIDAS system for detecting attacks on the NCSC Dockmaster network. Later, through a contract with DARPA, this system was further enhanced in the SRI laboratory and incorporated into the IDES and NIDES intrusion detection systems [Lindqvist1-99].

The attack and misuse description language implemented in the P-BEST shell is rather simple and easy to use. This language allows qualified administrators to quickly summarize nearly any type of unauthorized activity. For example, a failed logon attempt can be described in just 9 lines (Listing 9.1).

Listing 9.1. An Example of a Rule in P-BEST for Detecting Failed Logon Attempts

 rule [Bad_Login (#10;*): [+e:event| event_type == login, return_code == BAD_PASSWORD] ==> [+bad_login| username = e.username, hostname = e.hostname] [-|e] [!] printf ("Bad login for user %s from host %s\n", e.username, e.hostname)] ] 

The first line of this code specifies the rule name (Bad_Login), its priority (10), and permission for multiple use (*). The remaining lines describe the failed logon event and the notification mechanism. Furthermore, the rules developed can be easily integrated with the C programming language, which gives P-BEST practically unlimited capabilities. In the over 10 years of its existence, the P-BEST shell has been integrated into a large number of the most popular intrusion detection systems, including the EMERALD system, which detects misuse and attacks on various operating systems, such as Multics and UNIX clones (SunOS, Solaris, FreeBSD, and Linux).

N-Code

The N-Code interpreted language was developed for the NFR system. It allows you to define reactions to different types of events that attract the attention of the system or network administrator. Besides attacks, this language can describe the following aspects:

• Intensity of mail traffic

• Network statistics (the number of packets transmitted via ICMP, ARP, and other protocols)

• Attempts to access specific services

Thus, the N-Code language can be used not only for intrusion detection, but also for controlling various aspects of network communications that might be of interest to IT professionals and security specialists [NFR1-99, NFR2-99].

Besides the standard variables, procedures, and lists, the N-Code language includes special built-in data structures that fully describe network packet formats for different protocols. For example, you can access the source of an IP packet directly by specifying a single parameter - ip.src. All processing, including Ethernet frame parsing and selection of the Source Address field from the IP packet header, is performed by the interpreter module implemented as part of the NFR system. This allows you to specify a compact set of rules for detecting specific events. Listings 9.2-9.4 provide typical examples.

Listing 9.2. An Example of a Rule for Detecting a WinNuke Attack Written in N-Code

 filter oob tcp (client, dport: 139) { $urgpointer=long (ip.blob, 16); #Offset == OOB if ($urgpointer == 3) record system.time, ip.src, ip.dst to the_recorder; } 

Listing 9.3. An Example of a Rule for Detecting a Land Attack Written in N-Code

 filter pptp ip () { if (ip.src == ip.dest ) { record system.time, eth.src, ip.src, eth.dst, ip.dest to land_recrdr; } } 

Listing 9.4. An Example of a Rule for Detecting Attempts of Xmas Scanning Written in N-Code

 filter xmas ip () { if (tcp.hdr) { $dabyte = byte (ip.blob, 13); # If all SFAURP bits are set, this can only be a malicious packet if (! ($dabyte ^ 63 )) { record system.time, ip.src, tcp.sport, ip.dest, tcp.dport, "UAPRSF" to xmas_recorder; return; } } } 

Attack Signature Definition

The Attack Signature Definition (ASD) mechanism utilized by the NetProwler intrusion detection system is used to create attack signatures that are not in the existing database. This process comprises the following 4 steps:

1. Generation and gathering of data. All attacks that can be detected by the NetProwler system can be classified into the following two categories: connection-oriented (implemented via the TCP protocol) and connectionless (for UDP and ICMP). At this stage, traffic is generated, which is then analyzed and stored in a text file for further attack detection.

2. Data analysis. At this stage, the system identifies all information that will later enable you to describe the attack signature. Analysis is performed on the basis of the text file saved in the previous stage. Note that the analysis is performed manually, and the specialist who performs it must have the knowledge and skills required to detect signs of an attack in the incoming traffic.

3. Creating an attack signature. When describing an attack signature, you should use the following parameters.

   • Attack type. The following three types of attacks exist: Simple, Counter-based, and Sequential-based. The first type are simple attacks that can be described by a single network packet. The second type is used to describe attacks that operate using several packets during a specified time interval. For example, three failed attempts at remote logon during a 60-second period can be interpreted as an attack of this type. The last type includes the most complicated attacks, which span several network packets, and are directed at several applications (or from several applications) and in a predefined sequence. For example, sequential attempts at authentication using such services as Telnet, Rlogin, and Rsh performed within 180 seconds can be considered to be an attack of this kind.

   • Properties. An extended description of specific attacks. For example, one of the properties can specify that 4 failed attempts at authentication from 4 different hosts do not represent an attack, while 4 failed attempts from the same host does.

   • Operating systems and applications. Those that are vulnerable to this attack.

   • Priority. This parameter enables you to assign a priority to a newly created attack signature - low, medium, or high.

   • Category. Specifies the category of the newly created signature. You should note that categories in this classification are absolutely identical to the categories available in the RealSecure intrusion detection system. They include: "Denial of Service," "preparation for attack," "attempts at unauthorized access," "suspicious activity," "network protocol," and "miscellaneous."

   • Search criteria. Such criteria include various additional signs that characterize an attack, such as keywords or regular expressions.

4. Testing and debugging the signature.

In the course of describing signatures, it is possible to use different predefined variables that can significantly simplify the tasks of a security administrator (for example, IP_SRC_ADDRESS or ICMP_TYPE). When working with these variables, you can apply arithmetic, logical, or other variables such as "AND," "OR," "NOT," ">=," "!=," "+," "/," etc. Listing 9.5 illustrates the use of predefined variables for describing the Land attack signature.

Listing 9.5. Fragment of the Rule DESCRIBING the Land Attack Using Predefined Variables

 ((IP_SRC_ADDRESS == IP_DEST_ADDRESS) AND (IP_SRC_PORT == IP_DEST_PORT)) 

RUSSEL

The RUSSEL language (Rule-Based Sequence Evaluation Language) is intended for describing rules that give you the ability to track unauthorized actions in log files. It is used in the ASAX system (Advanced Security Audit-trail Analysis on UniX), which supports the following two operating systems - SINIX and BS2000 from SIEMENS [Habra1-92]. This language has much in common with the P-BEST language. After a short training course, you should be able to create rules for detecting security policy violations in local or corporate networks quickly and easily (Listing 9.6).

Listing 9.6. An Example of a Rule Created Using the RUSSEL Language for Detection of Failed Login Attempts During the Specified Time Period

 rule Failed_login (maxtimes, duration : integer) # This rule detects the first failed attempt and calls the add-on rule begin if evt='login' and res='failure' and is_unsecure (terminal) -> Trigger off for next Count_rule1 (maxtimes-1, timestp+duration) fi ; Trigger off for next Failed_login (maxtimes, duration) end rule Count_rule1 (countdown, expiration : integer) # This rule counts the number of failed attempts # It remains in force until the predefined interval expires # or when the countdown variable reaches zero if evt='login' and res='failure' and is_unsecure (terminal) and timestp < expiration -> if countdown >1 -> Trigger off for next Count_rule1 (countdown-1, expiration) ; countdown =1 -> SendMessage ("too many failed logins") fi ; timestp =?expiration -> Skip; true -> Trigger off for next Count_rule1 (countdown, expiration) fi 

SNP-L Scripting Systems

The SNP-L Scripting System is a language that very closely resembles C. This language is used in the SecureNet PRO intrusion detection system, and is intended for attack descriptions. One of the distinguishing features of the SNP-L language is the presence of a so-called "sandbox," which has much in common with similar technology implemented in the Java programming language. All attack scenarios are executed in the "sandbox," which protects the computer on which the intrusion detection system is installed from script failures or from other undesirable effects [Intrusion1-00].

SecureLogic

The SecureLogic language, created on the basis of the Tcl language, is used in the RealSecure Server Sensor system for more precise customization of the signatures of detected attacks. Furthermore, SecureLogic provides the capability of a more detailed analysis of a situation resulting from the detection of a specific event. For example, using a SecureLogic script, it is possible to analyze an administrative logon in the protected system (see Listing 9.7). If the user name is contained in the list of allowed names, the system does not implement any response action and does not consider the event to be an attack.

Otherwise, the system implements a predefined response action - for example, blocking the user account - and sends a notification of the detected attack to the central console.

Listing 9.7. An Example of a SecureLogic Script

 # List of allowed user names Store _iss_trust_usr_list [list "Luka"] # In this case, Luka is the only user with administrative privileges # in the protected system. When Luka logs on # no response is implemented, since # this activity is normal. # If anyone else logs on with administrative privileges # the sensor reacts to such an event. if { [catch { Retrieve "_iss_trust_user_list" } trust_user_list] } { set trust_usr_list "" } set user [GetData "User"] if { $tcl_platform(platform) == "unix" } foreach i2User $trust_usr_list { if { [string equal $user $i2User] } { # If the user is listed as trusted, the script # returns 0 return 0 } } # Otherwise it returns ti 1 and the sensor # reacts by the predefined action. return 1 

CASL

CASL (Custom Audit Scripting Language, formerly known as the Custom Attack Simulation Language) is both the name for a language and a subsystem implemented as part of the CyberCop Scanner. Both were developed by Network Associates (to be more precise, by Secure Networks) to enhance the capabilities of their Ballista security scanner, which was later renamed CyberCop Scanner. Recently, the CASL subsystem was made a stand-alone product that runs on Windows NT (Fig. 9.5) and Linux. This product is available for downloading from the Network Associates web server.

Fig. 9.5. The CASL attack description system

The CASL language is rather simple and easy to use. At the same time, it allows for the description of any fields of the packet headers for any protocol based on ICMP, IP, TCP, or UDP [CyberCop1-00]. CASL operates with variables, operators, and packets, and has much in common with N-Code. For example, the ip.src parameter in the N-Code language is similar to the ip_source parameter in the CASL language. An example description of hidden TCP scanning written in CASL language is presented in Listing 9.8.

Listing 9.8. An Example of a Description of Hidden TCP Scanning Written in CASL

 #include "tcpip.casl" #include "packets.casl" for (i =1; i <1023; i =i +1) { OurSYN = copy SYN; OurSYN.tcp_source = 10; OurSYN.tcp_destination = i; OurIP = copy TCPIP; OurIP.ip_source = 127.0.0.1; OurIP.ip_destination = 127.0.0.2; OurPacket = [ OurIP, OurSYN ]; ip_output (OurPacket); OurFilter = [ "src host ", 127.0.0.2, " and tcp src port ", i ]; ReadPacket = ip_input (2000, OurFilter) ; if (!ReadPacket) continue; if (size (ReadPacket) < size (IP) + size (TCP)) continue; ReadIP=extract ip from ReadPacket; ReadTCP=extract tcp from ReadPacket; if (ReadTCP.tcp_ack != 1 || ReadTCP.tcp_syn != 1 || ReadTCP.tcp_rst == 1) continue; print ("Port ", i, " is open"); } 

NASL

NASL (Nessus Attack Scripting Language) is the attack description language developed for the Nessus security scanner. It has a lot in common with C. However, as its developers admit, in many respects (for example, in the speed of script execution) it is weaker than other languages, such as Tcl, Python, and Perl. Nonetheless, this language is very efficient when it comes to performing the tasks for which it was specifically created and optimized (see Listings 9.9 and 9.10). Like many other attack-description languages, besides variables, operators, functions, and other elements, NASL can operate with network packets, which significantly simplifies the work of the security administrator [NASL1-00].

Listing 9.9. A Fragment of an NASL Script Describing a Check for Detecting Web Server Vulnerability

 if (is_cgi_installed ("php.cgi")) { display ("CGI-script php.cgi is installed in /CGI-bin\n"); } 

Listing 9.10. A Fragment of the NASL Script Describing the Check to Detect FTP-Server Vulnerability

 soc = open_sock_tcp(21); if (ftp_log_in (socket:soc, user:"ftp", pass:"luka@")) { port = ftp_get_pasv_port (socket:soc); if (port) { soc2 = open_sock_tcp (port); data = string ("RETR /etc/passwd\r\n"); send (socket:soc, data:data); password_file = recv (socket:soc2, length:10000); display (password_file); close (soc2); } close (soc); } 

VDL and VEL

Languages such as VDL (Vulnerability Descriptive Language) or VEL (Vulnerability Exploit Language) are very convenient for those end users that have no experience with languages such as C, Perl, or Tcl. Both VDL and VEL were developed by Cisco Systems, and are used in the Cisco Secure Scanner product. The checks described by these languages are based on simple logical expressions (Listing 9.11), and the user can add required rules in a few seconds. Unfortunately, Cisco no longer supplies this product.

Listing 9.11. An Example of a Rule Written in VDL That Detects the Presence of the Telnet Service

 # Service description section: Telnet service found at the scanned host port 23 using protocol tcp => Service:Remote-Access:my_telnet 

This check describes a rule that determines the presence of the Telnet service at TCP Port 23 of the analyzed host. The next rule is more sophisticated. It identifies the obsolete SuperApp application by the header returned in reply to a request directed to Ports 1234 or 1235 (Listing 9.12).

Listing 9.12. An Example of a Rule Written in VDL That Detects the Presence of the SuperApp Application

 # User-defined check: The SuperApp 1.0 application is started # at the scanned host (scanfor "SuperApp 1.0" on port 1234) || (scanfor "SuperApp 1.0 Ready" on port 1235) => VUL:3:Old-Software:Super-App-Ancient:Vp:10003 

This potential vulnerability (Vp), having its priority set to 3, is included in the category of "outdated (potentially vulnerable) software" (Old-Software), and is known as Supper-App-Ancient (this name is user-defined). The number 10003 is the unique number of the record in the vulnerability database of the Cisco Secure Scanner (Network Security Database, NSDB).

Using the VDL language, it is possible to give three categories of rules that allow for the identification of [Cisco1-99]:

• Network services

• OS type

• Vulnerabilities

  Cisco Systems divides all vulnerabilities into the following two classes.

• Potential - those resulting from header checks and so called nudges of the service or host being analyzed. A potential vulnerability might exist in the system, but active probing checks do not confirm this fact. This type of check is identified by the vp keyword.

• Confirmed - detected vulnerabilities whose existence on the scanned host is confirmed. The vc keyword corresponds to this type of check.

Potential vulnerability checks are implemented via header checks and nudges. Nudges are used for services that do not return headers but react to simple commands, such as sending the HEAD command to obtain the version number of an HTTP server. As soon as this information is obtained, Cisco Secure Scanner enables a special mechanism known as the rules engine, which implements a specific range of rules that confirm or deny the existence of a potential vulnerability. Thus the administrator knows which vulnerabilities are actually present in the system and which require confirmation.

However, it is clear that the built-in language of the Cisco Secure Scanner intended for describing these rules is rather elementary, and can help only in the simplest situations. In more complex situations, when the check can not be written in a form that comprises a single rule, you will need to compose more sophisticated scripts, which can be done using other programming languages, such as Perl, Tcl, or C.

STATL

The STATL language (State Transition Analysis Technique Language) was developed at the University of California (http://www.cs.ucsb.edu/~rsg/STAT/). It provides you with the ability to describe an intrusion in the form of an attack scenario that is a sequence of transitions between the system security states. This method was first used in the USTAT and NetSTAT intrusion detection systems.

Perl, C, and Other Languages

Attempts at enhancing vulnerability description mechanisms, checks, and so on have been being made for a long time, and virtually every developer or vendor has attempted this. The first attempt was undertaken by Vietse Venema and Dan Farmer - the authors of the SATAN security scanner. In this system, the description of new vulnerabilities - or to be more precise, the checks for new vulnerabilities - was designed using the Perl language. This important task required extensive knowledge of the Perl language, the architecture of the TCP/IP protocol stack, and the operating system being scanned. The developers of the WebTrends Security Analyzer system proceeded in the same way (and once again Perl was used). The Perl language, like C, is also used in the Internet Scanner system. The advantages of the Perl and C languages lie in the fact that checks and rules written for one operating system can be transferred to another with practically no changes having to be made.

Monitoring Custom Events

Most intrusion detection systems enhance their functions by adding new capabilities. For example, systems such as RealSecure Network Sensor and Cisco IDS can be customized so as to control e-mail messages by various parameters, from the sender or recipient address or message topic to the keywords encountered in the message body. Finding keywords such as "job," "resume," and so on enables administrators to detect employees searching for new jobs during business hours. The same capability helps detect macro viruses and Internet worms in e-mail traffic.

The next add-on function that extends the range of usage of intrusion detection systems is the control of access to different Internet hosts. Using built-in mechanisms, it is possible to select traffic belonging to HTTP, FTP, and other protocols from among all of the network traffic (Fig. 9.6).

Fig. 9.6. Controlling access to HTTP pages (using the example of the RealSecure Network Sensor system)

Besides the additional capabilities mentioned above, intrusion detection systems can also have functions allowing for the detection of viruses with active contents (Java, ActiveX) added to them. For example, the eTrust IDS provides built-in, fully functional antiviral software, which is just as effective as similar but better-known products. Systems such as RealSecure Network Sensor, Cisco Secure IDS, and others include mechanisms for detecting and locking malignant Java applets and ActiveX controls.

In my opinion, mechanisms such as antiviral protection and content control are basically stand-alone products that can, in turn, be integrated into an intrusion detection system.

False Negative Notifications

Notifying the IDS operator to the fact that the system can not handle an intense workload and is starting to miss events (for example, network frames) is rather important. Without this function, you will not be able to know in time that your system is experiencing problems and can not handle the workload. Unfortunately, this capability is not provided by all manufacturers. Some of the products that implement this feature are NFR NID, NetProwler, and RealSecure Network Sensor.

Processing Fragmented Traffic

In Chapter 6, when discussing the IDS network sensor architecture, I mentioned a module for processing fragmented traffic. I would like to draw your attention to the surprising fact that most intrusion detection tools, especially shareware and freeware (for example, Centrax 2.4 or NetProwler 3.5), lack this function, which results in the potential danger of causing such intrusion detection systems to fail by sending them fragmented traffic. Examples of such attacks were described in Chapter 4. A contemporary network-level intrusion detection system must provide a mechanism for processing fragmented packets.

Reference Information on Each Attack

Obviously, it is very difficult to become an expert on all the existing operating systems and applications used in the corporate networking environment. Learning about the entire variety of attacks that exist is even harder. Therefore, the availability of reference information on each of the detected attacks, describing the mechanisms of its implementation and vulnerable platforms, as well as variants of false positives and false negatives, are yet more important criteria that should be taken into account when choosing an intrusion detection system.

Extended Signature Customization

Even for the most efficient intrusion detection systems, supplied with the most complete signature databases, the need for additional customization of each signature still exists. This might be required, for example, to reduce the number of false positives. Because of this, a high-quality intrusion detection system must provide the required flexibility, allowing it to be customized according to specific user requirements.

Response

An intrusion detection system's reactions in response to detected and identified unauthorized activity can be classified into the following two categories.

• Passive reactions, which imply standard notifications sent to personnel when the IDS detects an attack, misuse, or other anomaly. This category includes: sending notification to the central console of the intrusion detection system, generating controlling SNMP sequences for network-management systems, registering events in the event database, etc.

• Active types of response, which include closing the network connection to the attacking host, blocking the user account used by the intruder to log in, reconfiguring network equipment and security tools, automatic elimination of the vulnerability, etc.

Notification

The first type of reaction that was implemented in intrusion detection systems was administrative alert - notifying the security administrator or intrusion detection system operator. Current intrusion detection tools provide quite a wide range of response types, from sending alerts to the central console of the intrusion detection system, to sending a voice message to the administrator's phone (Fig. 9.7).

Fig. 9.7. Types of IDS responses to an attack

Generally, intrusion detection systems provide two or three types of reactions: sending a notification to the IDS console, generating an e-mail message (via the SMTP protocol), and sending a message to the network management system (via the SNMP protocol) are the chief examples. Some developers provide other types of notification. For example, systems such as NetProwler and eTrust IDS provide alert mechanisms hooked up to the security administrator's pager. In eTrust IDS, each detected event can be further designated by a sound signal, or information on that event can be sent by fax. While the RealSecure system does not provide for sending notification by fax or by pager, it can be integrated with the AlarmPoint system by Singlepoint Systems (http://www.singlepointsys.com). This system is intended for facilitating various scenarios for notification of security administrators via various tools - fax, telephone, pager, cellular phone, e-mail, voice mail, etc.

An interesting though rarely used capability is offered in the RealSecure OS Sensor and the RealSecure Server Sensor. Using it, a notification of unauthorized activity is sent to the intruder rather than to the administrator. According to the developers of the RealSecure system, this informs the intruder of the fact that he or she has been detected and stops the attack. RealSecure utilizes a different type of notification, where information about the detected attack is sent to the console of the firewall. The RealSecure Network Sensor intrusion detection system, which was developed by ISS, uses the Lucent Managed Firewall by Lucent. For RealSecure, released by the Check Point company through an agreement with Internet Security Systems, the Firewall-1 system is the firewall.

Taking into account the fact that mobile communications are becoming more and more popular, it is possible to predict that most advanced intrusion detection systems will soon implement an SMS notification mechanism.

Event Logging

There is no need to write extensively about the logging of detected events here, since this is a mandatory requirement of every intrusion detection system. Two aspects, however, warrant special mention - where the logged events should be written, and with what level of detail. You can select files in various formats to act as a log file, including a text file, a system log (as is the case with Cisco IOS Firewall Feature Set), a text file in a special format (as, for example, in the Snort system), a local MS Access database (as in the Internet Scanner system), or an SQL database (as with the Spitfire or RealSecure systems). For intrusion detection systems, it is desirable to have built-in database mechanisms oriented towards end users rather than towards database experts. Otherwise, a situation might arise in which, for example, the SQL database exceeds its storage limit and needs to be cleared or backed up, which can only be done by an SQL professional who is not currently available.

In all cases, it is necessary to consider the rate of data processing. Several thousands of messages must be saved in the databases per day. Therefore, if communication between the console and the database is inefficient, it will be rather inconvenient, or even impossible, to use the system.

Computer Failures in the NSA and NSWC Caused by Overload 

According to ComputerWorld data, in January 2000, the NSA experienced problems caused by computer failures due to an overload for about 3 days. The NSWC experienced similar problems in 1990.

Information stored in log files can be saved with the standard level of detail or the complete level of detail. In the first case, the type of logged event, date and time of detection, the sensor that detected that specific event, and the source and destination addresses related to the event are registered. Below are some examples of various log files at the brief detail level (Listings 9.13-9.16).

Listing 9.13. A Fragment of the TCPdump Log File

 06:41:24. 067330 stealth.mappem.com.113 > 172.21.32.83.1004: S 4052190291:4052190291 (0) ack 674711610 win 8192 

Listing 9.14. A Fragment of the Apache Web Server Log File Named access_log

 193.56.123.47 - - [04/Apr/1997:16:39:06 -0500] "GET /etc/passwd HTTP/1.0" 404 139 

Listing 9.15. A Fragment of the SecurityEvent Log File of a Windows NT-Based Operating System

 Date Time Source Category Code User Computer 27.11.019:19:38 Security Logon/Logoff 529 SYSTEM NT-IIS 

Listing 9.16. A Fragment of the Cisco IDS 4200 Log File

 4, 1025294, 2001/01/16, 16:58:36, 2001/01/16, 11:58:36, 10008, 11 100, OUT, OUT, 1, 2001, 0, TCP/IP, 10.1.6.1, 10.2.3.5, 0, 0, 0.0.0.0, 

The second type of log file saved involves registering the detailed content of all data fields related to the logged security event. For example, network-level intrusion detection systems register all network packets. Extended logging formats are available with a number of intrusion detection systems, including Snort (Listing 9.17), Cisco IDS 4200, and RealSecure Network Sensor.

Listing 9.17. A Fragment of the Snort Log File

 [**] BACKDOOR Attempt- Subseven [**] 12/26-23:09:42.219109 0:90:27:F:22:A2 -> 0:40:5:F6:34:51 type:Ox800 len:0x4E 216.192.29.30:3216 -> 206.18.108.130:1243 TCP TTL:64 TOS:0xD0 ID:11841 S***** Seq: 0x4908C6 Ack: 0x0 Win: 0x2000 TCP Options => MSS: 536 NOP WS: 0 NOP NOP TS: 0 0 Opt 9 (40): 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 

Do you need to trace packet dumps? Making this decision is important, since this feature consumes a lot of system resources. However, this function is rather useful, and can play an important role in the investigation of a specific incident. The contents of the packet will allow you to reconstruct the whole attack (as opposed to the event tracing mechanism, which does this job automatically). Furthermore, it will help you understand a situation in which there was a false positive (false positives now occur in every intrusion detection system).

Tracing Events

Sometimes, the security administrator needs to track all the actions of the intruder and all the commands that he or she has issued. This is hard to do using log files and reports created based on them. Because of this, some intrusion detection systems implement an event tracing mechanism that allows you to record all events in exactly the same sequence and at exactly the same speed at which the intruder was operating. After that, the administrator can at any time replay the required sequence of events (in real-time, accelerated, or slowed down modes) in order to analyze the intruder's activity. This will allow him or her to assess the intruder's skill, the tools at his or her disposal, and so on, in order to collect the required proof for an internal investigation or for court. An event tracing mechanism is implemented in such intrusion detection systems as RealSecure Network Sensor and SecureNet PRO, as well as several others.

Closing Connections

Closing the connection to the attacking host is one way to interrupt an attack. There are two possible ways of going about this. In a network-level intrusion detection system, the mechanism for terminating the connection is based on session hijacking, with a packet whose RST flag is set sent to both the attack target and the attacker (Fig. 9.8).

Fig. 9.8. Termination of the network connection

This type of response (utilized by intrusion detection systems such as RealSecure Network Sensor and Cisco IDS 4200) has two main limitations: it is available only for events that are made up of several packets, and only for fully established TCP connections. This approach is not effective against attacks that consist of a single packet only (such as WinNuke). It is also not effective in reacting to a SYN Flood attack, since no fully functional TCP connection is established in the course of such an attack.

In host-level intrusion detection systems, the above-mentioned response option is done by locking out the user account that was used to implement the attack. This locking out can be either temporary (for a specified time period only) or permanent. The permanent locking of a user account remains in force until the system administrator unlocks that account. Depending on the privileges used in setting up the intrusion detection system, account locking can be active either within the host representing the attack target only or within the entire domain or network segment.

Reconfiguring Network Equipment

The reconfiguration of the network equipment or firewalls is yet another type of active response to attacks (in Cisco Systems, this concept is known as shunning). If an attack is detected, the intrusion detection system sends a special command containing instructions to change the access control list to the router or the firewall (Fig. 9.9). Later on, all attempts to establish a connection originating from the attacking host will be rejected. As with locking out accounts, ACL changes can be temporary or permanent.

Fig. 9.9. Reconfiguring network equipment

Blocking Traffic

Some intrusion detection systems (RealSecure Server Sensor, for example), complement the set of existing active response methods with a feature allowing you to block network traffic in the same manner as firewalls do [ISS5-00]. This approach allows you to isolate both the traffic and the recipients that might need to access the resources of the protected host. Such an approach thus carries out the functions of a personal firewall as well.

Deception Technique

We already discussed the deception technique in Chapter 6, so there is no need to concentrate any more on it now. I just want to mention that this mechanism is utilized by some intrusion detection systems. For example, the RealSecure Server Sensor system provides the Decoy mechanism, enabling it to emulate various ports and network services.

Eliminating Vulnerabilities

The elimination of detected vulnerabilities is the result of using a security scanner. This can be done either manually or in an automated mode. The first mode is easier to implement, but requires extra time and effort from the security administrator, who must eliminate all detected vulnerabilities manually, on his or her own, in order of priority. Some intrusion detection systems attempt to automate this process by providing administrators with ways of automatically patching detected security holes. Such systems include SFProtect (the IntelliFix mechanism), System Scanner, and Desktop Scanner. In contrast to small networks, where this function is not vital, in large corporate networks where there is a lack of qualified personnel, this mechanism becomes a matter of primary importance.

Counter Attack

I would like to give special attention to this type of response and discuss it separately, because it is the response that causes quite a number of disputes among experts. At first glance, this solution can be easily implemented - just register the intruder's address and implement a counter attack against him or her.

A Counter Attack Attains Its Goal 

As was reported in the press release of the Conxion hosting company (http://www.conxion.com/news/releases_16.asp), during the period from November 30 to December 3, 1999, a political group identifying itself as "E-hippies" attacked the site of World Trade Organization (WTO), hosted by Conxion. The E-hippies attempted to cause the WTO's site to fail by implementing DDoS attacks directed from 3793 various IP addresses. However, the Conxion security engineers managed to redirect all of the traffic back to the E-hippies' site, which was brought down by this bombardment. At the same time, the E-hippies themselves appeared to have interpreted this redirected traffic as hits to their site in support of their activities.

Most specialists (for example, [Schneier1-01] and [Schneier2-01]) consider such actions justified self-protection. From the hacker's point of view, this reaction is also a justified measure that would teach a good lesson to beginner intruders who are just using freeware hacking tools without a proper understanding of what they are actually doing. By the way, there are plenty of tools on the Internet both for implementing DDoS attacks and redirecting them back. The PortSentry intrusion detection system, for example, provides this feature. Furthermore, most intrusion detection systems provide the capability of implementing customized responses, including counter attacks. Some governments have gone even further and are trying to legalize counter attacks.

Legalized DoS Attacks 

On June 25, 2002, the House of Representatives of the U.S. Congress started to discuss a bill on intellectual property, according to which music recording companies and other owners of intellectual property will have the legal right to force the disconnection of users that spread pirated content. In particular, this bill legalizes the redirection of pirate traffic, file locking, DoS attacks against pirate sites, and so on. The only action that is not allowed is the use of various tools for destroying computer systems or data.

DoS Attacks against Nazis 

On April 10, 2001, the German Prime Minister declared that the German Intelligence Service can implement DoS attacks against neo-Nazi sites. A few days later, however, this statement was denounced, and it was declared that the government will find legitimate ways of neutralizing Nazi sites.

This point of view, however, is arguable. Some specialists think that a counterattack is similar to the lynch law, and therefore is not justified. Furthermore, according to the opinion of most specialists, the main problem here is correctly identifying the intruder's actual address (which will be covered in more detail in Chapter 12). In practice, intruders rarely attempt an attack from their real addresses - usually they use various proxies in order to conceal their location. Address spoofing (see Table 2.4) will result in a counterattack targeted against someone else (a company or individual who never did anything to you). If that company or individual suffers damage as a result of your counterattack, they can also file a lawsuit against you. However, there is one subtle feature here. If you redirect the intruder's requests back without changes, this could be seen as a refusal to receive the traffic, which is a normal function of network communications. On the other hand, if you modify these requests or implement your own counterattack, it might be considered breaking the law.

To conclude, I would like to mention that you should not neglect this type of response completely. Provided that some specific conditions are satisfied, it can be considered a viable solution.

Additional Types of Responses

Almost every intrusion detection system allows the user to create custom types of event handling, which provides for a practically unlimited range of various response types. For example, you can allow an event to be recorded not only in the IDS log file, but also in the system log, or start the antiviral software for a specific type of traffic. For example, quite an interesting type of response to distributed attacks such as TrinØØ, TFN, Stacheldraht, Troj_TrinØØ, and Shaft is implemented in the Zombie Zapper system from the Bindview Corporation. Knowing the default passwords for interaction between masters and daemons, Zombie Zapper sends commands to stop attacks against the selected target.

Creating Custom Responses

A well-designed intrusion detection system must allow the system administrator to add to the list of predefined reactions to detected attacks. This will allow him or her to significantly extend the system's effectiveness. For example, the addition of a function that performs administrative notification via a pager would be desirable for most companies that supply administrators with these inexpensive communication devices. Let us consider another example. Most manufacturers utilize so-called proactive variations of response, which allow the reconfiguration of network equipment. However, the list of this equipment is quite short (most often, it is limited to two or three items). The capability to reconfigure devices significantly improves the efficiency of the intrusion detection system. For example, earlier versions of the RealSecure Network Sensor intrusion detection system allowed for the reconfiguration of access control lists for series 7000 routers developed by Cisco Systems. In the current version, this function has been significantly enhanced and improved. Now, using the specialized Expect software tool, it is possible to reconfigure a wide range of network devices. This system (http://expect.nist.gov), which runs on Windows NT-based operating systems and on Unix clones, allows you to write various scripts using a language that is an extension of Tcl (Listing 9.18).

Listing 9.18. An Example of Script Written Using the Expect Language to Reconfigure Cisco Routers

 ## Usage: ## cisco <routerip> <routerpasswd> <configpasswd> <hostip> spawn telnet [lindex $argv 0] # Connecting via Telnet to routerip expect "Password:" # Waiting for Password prompt: send "[lindex $argv 1]\r" # Sending routerpasswd expect "Router>" # Waiting for reply send "enable\r" expect "Password:" send "[lindex $argv 2]\r" # Sending configpasswd expect "Router#" # Waiting for reply send "config\r\r" expect "Router (config)#" # Adding a new rule to the Access Control List send "access-list 101 deny ip host [lindex $argv 3] any\r" expect "Router (config) #" send "exit\r" expect "Router#" send "exit\r" expect eof 

Managing Sensors

Obviously, IDS sensors can be managed both remotely and locally. Local management might be necessary in one of two cases - when there is only one sensor (in a small company) or when remote management is impossible (for example, when communications with the console have been interrupted). In such cases, you can manage the sensor locally from the computer on which it is installed, either using a separate utility (such as Engine Manager in RealSecure Network Sensor) or an embedded management module (such as IDS Device Manager in Cisco IDS). However, local management becomes rather inconvenient if you have two or three sensors, to say nothing about controlling several dozens or hundreds of them. Because of this, remote control is used.

Remote Control

This criterion - remote control capability - is especially important for large geographically distributed networks with a number of sensors. As noted in [Jackson1-99], remote administration can be accomplished using the following two methods:

• From any console. Here, an unlimited number of consoles can be installed in the network. Each of these consoles can control remote sensors for the intrusion detection system. At first glance, this approach is very convenient. However, when operating such system in a real-world environment, you might encounter some problems. For example, intruders may be able to install a false console in the network and send commands to sensors in order to reconfigure them or perform other unauthorized actions.

• From the central console. In this case, only one console (a predefined central console) is capable of managing remote sensors, and any attempts to establish control from other locations are denied. The RealSecure Network Sensor system is based on this principle. During RealSecure's installation, the console and sensor exchange authentication keys. Later on, the RealSecure sensor will accept control commands only from the console for which it has the authentication key. Otherwise, all control commands are rejected.

You should note that console managing remote sensors can be supplied by IDS sensor manufacturers (as in systems such as RealSecure Network Sensor or Net-Prowler), as well as by other companies (for example, the Spitfire system allows you to manage sensors of other IDSs, such as RealSecure and Cisco IDS). Furthermore, there are also intermediate or mixed variations, which will be described below.

When evaluating this mechanism, you need to take yet another aspect into account, which comes onto the scene only during the actual operation and maintenance of the system. Sometimes, the capabilities provided by the developer are insufficient for supporting the remote sensor. For example, you might sometimes need to reboot the sensor or even the computer on which it is installed, view the system event log or CPU usage, etc. Of course, some of these actions can be performed from the management console. However, if you need to reboot the computer on which the sensor is running or view CPU usage statistics, you will need additional software. If you encounter such a situation, you will notice that Unix solutions are much more convenient than similar solutions for the Windows platform. Obviously, it is much easier to open an SSH or Telnet session than it is to start Remote Administrator or other Windows utilities for remote access. Of course, you can start a special service on a remote computer (especially in Windows 2000 or Windows XP) and manage all settings via it. However, if you do so, you are gaining convenience at the expense of the sensor's security.

Number of Management Consoles

In most organizations, IS management functions are distributed among several departments. For example, the IT department controls a limited set of specific network parameters, while the information security department monitors and controls other parameters. The sets of functions performed by these departments should not intersect, and maintaining this requires the presence of at least two management consoles, each of which must be customized for performing a specific set of tasks. In addition, a decentralized management scheme requires the presence of several consoles - both at the headquarters and at remote offices. More detailed coverage of this aspect will be provided in the next chapter.

Number of Managed Agents

If you are not planning to use more than 5-10 sensors, there is no significant difference between management consoles from various manufacturers. However, if this limit is going to be exceeded, you will encounter several problems, from the impossibility of tracing all alerts on the console and the event database filling up, to the failure of the console or the management server. Because of this, this criterion is important only in large networks that have dozens or hundreds of sensors. In small networks, a single console (or management server) can control all the sensors that exist in the network. Some intrusion detection systems can coordinate an unlimited number of sensors (for example, RealSecure SiteProtector), while in other systems the number of sensors is limited. For example, in the NetProwler system, the management server (NetProwler Manager) to which remote sensors are connected (NetProwler Agent), can manage no more than 20 agents [NetProwler1-00].

Hierarchical Management

In large networks implementing a mixed management scheme, the headquarters (or central office) might control the activities of the remote affiliates, despite the fact that the main management is done from the regional information security departments. In other cases, it might be necessary to instruct the IDS sensor to transmit all messages during business hours to the local console installed in the regional office. At other times, during non-business hours, these messages would be transmitted to another console, monitored 24 hours a day by the IDS operator. In both cases, a hierarchical management scheme might be required, allowing the system to switch between two consoles automatically, without user intervention. Cisco IDS is one example of such a scheme.

Group Operations

This criterion becomes very important when it is necessary to manage a large number of sensors. In large, geographically distributed networks, it is very inconvenient to perform the following operations on a per-sensor basis:

• Updating the attack signature database

• Applying templates

• Starting and stopping the sensors

Because of this, your IDS must be able to perform these operations for groups of sensors.

Managing Events

Specifying Priorities

The same attack can have different consequences for different hosts within a corporate network. For example, a host running Solaris 2.5.1 is vulnerable to the Ping of Death attack, while a host running Windows NT is not [ISS4-00]. We can also give another example - the presence of a modem. If the modem is connected to the computer, according to all the information security requirements, the situation is considered normal, and does not require the security administrator's attention. On the other hand, if the modem is connected in such a way as to bypass the firewall, it must be removed immediately. Yet another example relates to the Telnet service. This service must be present on the router, but is absolutely unnecessary on most workstations. Because of these reasons, the IDS must provide the ability to specify priorities for detected attacks and vulnerabilities. Priorities can be specified both statically (as was shown above) and dynamically (this topic will be covered in more detail later). At the moment of writing this, all intrusion detection systems - with the exception of the RealSecure Protection System family - were only capable of assigning static priorities. With the release of RealSecure SiteProtector, security administrators obtained the ability to delegate the comparison of the log files created by the IDS and the security scanner to the Fusion Security Module included with RealSecure SiteProtector.

Another aspect of assigning priorities is found in the qualitative and quantitative characteristics of the detected vulnerabilities and attacks. There are two points of view on this problem - the generally accepted one and the non-standard one. Using qualitative characteristics (weights) in intrusion detection systems is nothing more than theory, since quantitative parameters (low, average, and high risk) are easier to interpret by the end user. Let us consider the following example: what sounds more possible - "high-risk vulnerability" or "vulnerability with a weight of 4"? In my opinion, the first concept better reflects the idea of intrusion detection systems. Because of this, quantitative characteristics are so widely used in contemporary intrusion detection systems. Experts that back the non-standard point of view are usually those working in various research organizations or in companies that do not work much with intrusion detection technologies on a practical level. As for qualitative characteristics, they also lack a unified classification, since each manufacturer uses its own approach. Still, most manufacturers tend to use three main categories of attacks - high risk/average risk/low risk. This approach, for example, is utilized in RealSecure Network Sensor, SecureNet PRO, Cisco IDS, eTrust IDS, etc. However, there are other classifications, such as information/warning/attack/error, used in NFR NID, information/suspicious/serious/critical implemented in RealSecure Desktop Protector, suspicious/probing/attack/error/breach/virus used in Dragon, etc.

Event Correlation

When considering the aspect of priorities, we mentioned that you have the ability to assign priorities dynamically. Why is this needed and why is not the static method sufficient? Suppose that there is a Guest user account on the computer. Under normal conditions, this vulnerability has a high priority. In practice, however, the priority of this vulnerability must change from high (if this user account is enabled) to low (if the Guest account is disabled). In this case, the priority can only be calculated during the process of security scanning, which means that it must be assigned dynamically.

Let us consider a more difficult example. Suppose that the intrusion detection system detects a Ping of Death attack (which normally has the highest priority), thus forcing the security administrator to react to this event immediately. Now suppose that the corporate network contains only Windows hosts. If this is the case, this attack will not cause any damage (although it still must be registered). What should you do in this situation? In order to figure out if the detected attack is dangerous, you must know if the attacked host is vulnerable to this attack. This can be accomplished manually, and this operation is usually done when creating the network map. However, as I mentioned earlier, administrators do not seem to care enough to perform this step in most organizations. This is where the automatic event correlation mechanism comes to the rescue. This mechanism provides you with the ability to analyze the log files of the intrusion detection system and security scanner without user intervention. Based on this information, the correlation mechanism draws a conclusion as to whether the attacked system is vulnerable. If the attacked host does not contain this vulnerability, the attack priority is dynamically lowered, thus changing the predefined responses for this attack, and vice versa. On the other hand, if an attack having low priority can still damage the attacked host, the correlation mechanism increases its priority, and additional responses are applied. The Fusion Security Module supplied with RealSecure SiteProtector operates based on this principle. As of yet, other intrusion detection systems have not implemented similar mechanisms. However, most leading manufacturers have declared that they are working on it. For example, after Symantec purchased the MountainWave company, it stated that it was going to implement the CyberWolf technology, which would enable you to correlate information from different security tools and to automatically react to the detected attacks.

Besides the correlation of data from scanners and intrusion detection systems, it is often necessary to use data collected by other security tools, such as firewalls. This goal can be achieved using specially designed correlation tools, which we will describe later.

There is yet another aspect related to correlation (one that is quite often neglected) - the time after which information on the attack or vulnerability becomes obsolete. For example, the WinNuke attack is currently rather rare. Why is this the case? Naturally, the main reason for this is the fact that the vulnerability exploited by this attack has long been known to almost everyone. This vulnerability has now been eliminated in most systems. Therefore, implementing such an attack is simply a waste of time and effort. Usually, intruders try to exploit the information on security holes immediately after they are reported, but before the appropriate patches are released. Therefore, the risk imposed by attacks and vulnerabilities decreases with time. It is desirable that the correlation module take this aspect into account and decrease the priority of a specific attack or vulnerability after a certain time interval expires.

As I mentioned in Chapter 1, one of the main drawbacks of traditional security tools, including firewalls, is the fact that they only block attacks, without providing the possibility of preventing them. If these tools could eliminate the vulnerabilities that result in the attacks, the level of security of the corporate network would be improved significantly. The possibility of reconfiguring firewalls helps to block specific attacks, but it can not prevent the intruder from resuming these attempts. It was this situation that led Internet Security Systems to create a new technology known as SmIDS (Smarter IDS) [ISS3-00]. This technology is the first example of the integration of intrusion detection systems and security scanners. Note that this integration is mutual. For example, when it detects an attack, the RealSecure network sensor issues a command to start the Internet Scanner security analyzer to investigate the attacked host. If it detects a vulnerability on this host, and this vulnerability allows for the implementation of the registered attack, the sensor notifies the security administrator or eliminates this vulnerability automatically (Fig. 9.10).

Fig. 9.10. The SmlDS technology (first implementation)

Alternatively, Internet Scanner scans specified hosts and, after detecting a vulnerability, immediately sends a command to the RealSecure network sensor in order to modify its settings. Network sensor accepts this command and initiates the procedure to detect attacks that may be implemented by exploiting the detected vulnerability (Fig. 9.11).

Fig. 9.11. The SmlDS technology (second implementation)

Trend Analysis

Trend analysis and the forecasting of changes of the security level of the corporate network are closely related to event correlation. Unfortunately, IDS manufacturers have only taken the first steps in this area, and can not really be proud of any serious achievements. However, some security scanners even now are capable of comparing the security status (the number of vulnerabilities of a specific risk level) on the same host or group of hosts at various time intervals. This enables experts to determine what influence specific security measures have on the overall security level of the corporate network.

Displaying Events

Event visualization is quite a sophisticated area, in which it is rather difficult to determine any evaluation criteria. Visualization is a method of representing data collected from the IDS sensors, and each user must determine which method of representing data is best for his or her purposes. It should be mentioned that a data visualization tool is a mandatory component of contemporary intrusion detection systems, especially in large distributed networks. This tool usually allows you to display data using various methods, from table views (like in the Internet Scanner system) and hierarchical tree-like structures (like the ones used in RealSecure Workgroup Manager), to graphical maps (like the ones used in CyberCop Scanner and Cisco IDS). Some systems do not provide such tools, and are limited to data logging and sending administrative alerts via e-mail to the central console. The popular Snort system is an example of such a system.

When choosing and testing the IDS, pay special attention to the method used to notify the administrator of possible attacks. This parameter is rather important, and it is hard to evaluate without testing the system under the conditions of your network. For a more precise evaluation, it is also good to implement stress tests, since they will demonstrate the convenience and ease of use of the system. For example, if there are not many events, you might not notice that in order to analyze a single event, you must click the mouse button 3 times. Consider, however, a situation where there are 5,000 such messages. Furthermore, some systems display events on the console as they are detected. For example, if the sensor has registered 100 attempts of remote scanning in an hour, the console will display 100 rows. But what if there are 10,000 events instead of 100? Even worse, what if these events were all registered during a small time interval, and came from 10 sensors? With an incorrectly designed console, you will get lost in such amounts of information. The only thing that you will be able to do is to watch the fleeting messages in dismay. If this is the case, the manufacturer of the system is to blame, since they were the ones who were supposed to perform the stress test and check the ergonomic parameters of the product under peak workload conditions. Various mechanisms for keeping the operator's attention at the proper level need to be implemented. As noted in [Shipley2-99], most IDS manufacturers do not test their products in large networks, since their interfaces and data visualization functions are very far from perfect. Intrusion detection systems designed with ergonomic requirements in mind (such as RealSecure SiteProtector or Dragon) do not display all events one after another. Rather, they simply specify the number of events of a specific type. As for the Cisco IDS console, it provides a special option known as freeze updates, allowing the administrator to temporarily stop the scrolling of a constantly updating event list. Besides this, the IDS must differentiate between various methods of issuing security alerts, including the following:

• Sound notification. It is best to have the capabilities of differentiating sound notifications for each detected attack. Otherwise, if there is only one customization parameter (enable/disable), the administrator will have to listen to a continuous beeping. Within several minutes these sounds will be perceived as background noise, and after an hour the operator will cease to pay any attention to it at all.

• Graphic notifications in the form of various icons.

Since events from all managed sensors are displayed in real-time mode, there can be a whole lot of them (probably several hundreds of thousands per day). This significantly complicates noticing and analyzing them. Moreover, most such events are due to false positives, and do not provide any significant information on the attacks. Thus, event filtering and sorting is a rather important characteristic of an intrusion detection system (and this is especially true for large networks). Filtering and sorting functions provide the capability of displaying only events of specific interest on the console (all events are still registered in the database). The operator must have the ability to customize this display according to his or her particular needs. Such a function, indispensable in large networks, is implemented in Cisco Secure Policy Manager. The developers of RealSecure SiteProtector have gone even further - they have integrated this function with a mechanism for grouping protected resources. This draws the operator's attention to really critical and serious attacks and vulnerabilities detected for a specific group of resources. In Chapter 11, we will consider the integrated operation of these two mechanisms (see Fig. 11.8). The function of displaying the events that occurred while the administrator was out (for example, at lunch or at night) will also always be rather useful.

Data visualization has one more aspect. The system console can be used to display data not only in real-time mode, but also when analyzing the data accumulated in the database. For example, Cisco Secure Policy Manager and RealSecure WorkGroup Manager are oriented towards working in real-time mode, while RealSecure SiteProtector is oriented towards analysis of accumulated information.

Grouping Protected Resources

In order to simplify the life of the security administrator, IDS must provide the ability to group all protected resources of the corporate network based on various factors:

• Geographic location (for example, resources of the headquarters and remote affiliates)

• Network topology (DMZ resources and internal network resources)

• Business tasks (resources of the commercial department, accounting resources, resources of the research department, etc.).

• Service (databases, UNIX servers, web servers, workstations, etc.).

Such a grouping allows us to focus our attention on the resources that are currently required, without distracting ourselves with irrelevant data. This significantly improves the efficiency of administrative work, especially when the console displays vast amounts of data.

When evaluating the system by this criterion, do not forget to determine how the information on all controlled hosts is registered. The best intrusion detection systems can provide a learning mode, in which the IDS collects information by investigating network packet headers. The same task can also be implemented by exporting data from network management systems, security scanners, firewalls, etc.

Central Management Console

The availability of a unified central management console is very important for large companies that need to create a complex and sophisticated information security system that combines several security tools. One of the best examples of such a system is the CheckPoint solution. Unfortunately, at the moment, there is no unified management console that can integrate all security tools. Because of this, this requirement relates only to intrusion detection systems and security scanners that must be managed from a single console. And if this goal can not be always achieved when using security tools from different manufacturers, this requirement is mandatory for tools provided by the same manufacturer. Unfortunately, however, not all manufacturers provide a unified management console.

Quite an interesting situation exists for the IDS solutions provided by Symantec. This company, after purchasing L-3, Axent Technologies, and Recourse, now supplies the following tools:

• The NetRecon network-level intrusion detection system

• The Enterprise Security Manager (ESM) host-level security scanner

• The NetProwler network-level intrusion detection system

• The Intruder Alert OS-level intrusion detection system

• The ManHunt intrusion detection system

• The ManTrap deception system

However, this long list lacks the products that were originally developed by Symantec. The first four systems were released by Axent, while NetProwler was originally developed by the Internet Tools company, and was initially was supplied under the name ID-Trak. The last two items on this list are solutions from Recourse. At the moment of writing this, these 6 systems did not have any central "control point" (although some steps in this direction have been taken), and you have to use 6 different management consoles. A similar situation exists with other manufacturers that promote solutions purchased along with smaller companies.

Report Generation

Like the data visualization subsystem, the report generation subsystem is a very important component of any IDS. The lack of this component complicates the process of determining the attacks that are registered most frequently and the hosts that most often become targets of intruder attacks. Based on the information created by the reporting subsystem, the administrator plans all further activity - changes in security policy, elimination of vulnerabilities, reconfiguration of network equipment, preparation of reports for management, etc. An advanced report generating subsystem must have the following properties:

• The availability of both text and graphic information in reports, which can satisfy practically all requirements for creating meaningful and illustrative reports.

• The capability of including into the reports information on the detected attack or vulnerability along with the operating systems vulnerable to it, cases of false positives, methods of elimination, links to manufacturer sites, and additional reference information. Recently, specifying the correspondence between the detected problem and its related information in the CVE database has become a rule.

• The possibility of selecting only the required data from the entire set of accumulated information according to specified criteria (time interval, attack or vulnerability name, risk level, operating system, type of attack or vulnerability, and so on).

• Functions of data sorting according to various parameters (by name, by date, by risk level, by the source or destination address, etc.)

• The possibility of creating reports for different categories of specialists. At the least, we need to choose three such categories: the upper-level management of the company, managers, and technical personnel. Reports of the first category should not include any technical information on the detected vulnerabilities or attacks. Such reports must contain only a description of the general status of the corporate network security. Reports that fall into the second category can contain more detailed technical information, for example, a description of the detected vulnerabilities or attacks, however, without specifying the steps required to eliminate them. The same category also includes a so-called trend analysis, showing the trends in the changes in the security level of specific hosts within the corporate network. The third class contains technical reports that include detailed information on each detected problem, recommendations for their elimination, and to references for additional information sources. This type of report is produced by the Internet Scanner and Cisco Secure Scanner.

• Export capabilities. Besides printing the reports on printers and saving them as files, some intrusion detection systems can export reports into formats of other applications, such as Lotus Notes or MS Exchange.

• Support of various report formats. Usually, intrusion detection systems are limited to two or three formats when creating reports: HTML, CSV, and the native format of the IDS. However, depending on the operating system under which the IDS runs, and on the installed applications and other parameters, the intrusion detection system might create reports in other formats, such as Microsoft Word, Microsoft Excel, ODBC, and DIF (Data Interchange Format), etc.

• The possibility of creating report templates. Quite often, the existing templates are insufficient, such as when your organization has adopted a custom report template (with the company logo, report author, date and time of creation, sensitivity level, and so on). In this case, the intrusion detection system you choose must have a mechanism for creating custom report templates. These mechanisms are provided by Internet Scanner, RealSecure, Cisco Secure Scanner, etc. The function for creating custom templates is implemented differently in different systems. For example, Internet Security Systems products use third-party software for this purpose - the Crystal Report system from Seagate. Cisco Systems uses built-in functions of the operating system, i.e., report templates are normal HTML files [Cisco1-99].

Time Synchronization

This criterion is rather important for international corporations and companies with a large number of affiliates around the world. If this requirement is met, the events are displayed on the console using the common unified time system. The confusion caused by viewing events from sensors installed in different time zones significantly complicates and slows down event analysis and attack response. The necessity of information correlation (especially when dealing with distributed attacks) requires that you perform time synchronization for all sensors, or display all events on the central console using a single reference point.

Automating Routine Tasks

When employees responsible for the intrusion detection system can not pay sufficient attention to it, it is best to automate the process of the IDS's operation. Automation is especially important for security scanners, whose efficiency depends on the frequency of their use. However, administrators quite often forget to or just are not able to start the scanner in due time, which results in discrepancies between the actual and supposed states of security of the corporate network. Thus, the most important aspect in such situations is the possibility of the IDS's automation, which can be implemented using built-in mechanisms (like in the Enterprise Security Manager system), or by starting IDS components from the command line.

Automatic updating of the signature database is a mandatory requirement for any intrusion detection system. If this capability is not provided, the attack and signature database will not be maintained in its most up-to-date status.

Ease of Use and Customization Capabilities

Such criteria as "ease of use" or "intuitive and user-friendly interface" are rather subjective characteristics very closely related to the visualization of registered data, which we covered earlier in this chapter. It might be said that almost each person has his or her own idea as to what "ease of use" means. For example, one security professional may have no problem working with the command line, manually entering all commands, and changing the configuration files, while other users just can not do without a graphic console and a mouse. The chosen system must be convenient for the end-user, rather than for its vendor or a third-party consultant. This requirement is the most important, and you must properly evaluate its convenience and ease of use during the testing procedures. According to the opinions of most experts [Shipley1-00], this parameter is one of the most important these days. It does not much matter how many signatures are stored in the IDS database or how fast the system identifies them. If the system provides an excessive amount of information to the operator, and it is impossible to make efficient use of this information, such a system is practically useless. On the other hand, if the console hides most of the important information from an operator who has to spend time and effort to retrieve the required information from the database, this also is not good. To form your own opinion as to the requirements for convenient and ergonomic user interfaces, consider the screenshots shown in Figs. 9.12-9.14.

Fig. 9.12. Managing the RealSecure intrusion detection system from the command line

Fig. 9.13. Managing RealSecure using the RealSecure Workgroup Manager graphic console

Fig. 9.14. Managing Specter using a graphic console

Templates

Let us suppose that you need to analyze the security status of the three segments of your corporate network. The first segment is located at a significant distance from headquarters, and the number of hosts within it is unknown. The second segment is the "demilitarized zone," containing Web, FTP, SMTP, and DNS servers. The third segment is localized within headquarters' network and contains database servers. This task can be solved by starting all the checks for each of the analyzed devices. First of all, however, it is necessary to determine the list of analyzed equipment, i.e., to perform a network inventory. Then, you must classify all the scanned devices by OS type and the software that they are running. This will allow you to reduce the required number of checks and speed up the security scan. Templates that describe the required procedures for each category of devices are intended for just this purpose. The best implementation of this scheme belongs to Internet Security Systems, who have introduced the concept of so-called security levels, which significantly simplifies management of the information security infrastructure. This concept is based on the principles listed below.

• It is impossible to ensure security without knowing the network topology, protected resources, and information flows.

• For most devices of the corporate network (workstations, for example), there is no need to implement expensive and labor-intensive measures to ensure security.

• The most critical devices need serious protection at all levels of the information infrastructure.

• Malicious insiders are the most dangerous.

• The security infrastructure must be implemented on all levels.

At the first step, you will have to analyze the existing network devices, workstations, servers, and so on. This will enable you to find an answer to the question of "What needs protecting?" This analysis is one of the components of the process of creating a network map. At the next level (ensuring minimal security) you need to prevent external attacks on the protected host. A medium security level includes protection against insiders that are able to implement various attacks and misuses. The highest security level is intended for the most critical hosts within the corporate network - in particular, against failures or against Denial of Services that occur because of them [ISS8-00].

Thus, at the lowest level, it is necessary to identify and classify absolutely all devices of the corporate network (including ones located in remote affiliates). For these devices, you will need to implement a minimal security level. Minimum security is usually ensured for workstations. At the next security level, the range of devices protected against external attack narrows. This list includes internal servers, network equipment, and other important devices on which the corporate network operation depends (application servers, DMZ devices, network equipment). Finally, the strongest security is intended for hosts that form the core of the whole corporate network (servers for accounting, billing, payroll systems, perimeter devices).

This concept is practically implemented in seven levels, used in all ISS products. The first five levels are applicable for the Internet Scanner system that performs remote security scanning. The levels from the second to the seventh are implemented in the Database Scanner system, which also performs remote analysis. However, since this system is used to analyze specific devices (DBMS), the inventory and classification stage (level 1) is not used in the Database Scanner. The System Scanner product is intended for detecting internal vulnerabilities that exist on the analyzed host, and therefore this system uses levels 3 to 7. This structuring allows you to identify and select the devices for which security requirements are different.

A similar task arises for other categories of intrusion detection systems. For example, depending on the location of the intrusion detection system (DMZ, Unix segment, and so on) and on the tasks delegated to it (detection of attacks, control over Internet access, etc.), it might be necessary to include specific signatures or implement specific response types. Templates provide you with the capability of replicating them.

Protection against Unauthorized Access

Despite the fact that an intrusion detection system is a protection tool itself, it also needs protection against unauthorized access, since, should it fail to operate, the whole network is exposed to the risk of intrusion.

Integrity Control

Since unauthorized modification of IDS components can result in it being compromised and, consequently, rendering it impossible to use the data gathered by the IDS as a reliable source of information on the actions of the intruders, it is necessary to provide the intrusion detection system with the ability to control the integrity of all of its components. If this is impossible, you should at least specify the control checksum values for all files included with the system in the documentation or in a separate file. This will enable you to check their integrity using third-party tools, such as Tripwire, or the OS's built-in tools (mainly Unix utilities).

Stealth Mode

Stealth mode makes the intrusion detection system invisible in the network. This is activated by installing two network adapters into the computer on which the network sensor is installed. One of these adapters will function in promiscuous mode, without TCP/IP stack support. Thus, this network adapter will not have an IP address, but will monitor all network traffic within the controlled segment. This adapter is connected to the switch, hub, splitter, etc. The second adapter must be bound to the TCP/IP stack and used to loopback to the management console, sending notifications via e-mail, SNMP control sequences, and the implementation of other types of responses (Fig. 9.15).

Fig. 9.15. Stealth mode

The invisibility of the intrusion detection system enables the improvement of protection levels in the network segment in which the intrusion detection system is installed, protects it from attacks by intruders, and prevents these intruders from compromising the IDS.

Controlling Access to IDS Components

Since the intrusion detection system is one of the most important components of the information security infrastructure, it is necessary to limit the list of individuals who have access to system components and to the data collected by the IDS. Unauthorized access to these components can result in configuration changes or in important information, such as the vulnerabilities of the corporate network, being revealed.

Access control can be implemented using different approaches. For example, in the NetProwler system, requests for the user ID and password are carried out several times - when starting the management console, when connecting to the management server, and when connecting NetProwler agents (sensors) to the management server. In the RealSecure SiteProtector system, this mechanism is implemented differently - it allows you to specify the roles of IDS users, such as operator, administrator, analyst, etc. Each of the user roles has its own field of activity. In Internet Scanner, this mechanism is somewhat simpler - it can only be installed and started by a user belonging to the Administrators group. Requests from all other users are blocked.

Protecting Connections between the Console and Sensors

If you need to control your intrusion detection system remotely, or if you have to control an intrusion detection system located in a remote office, then it is necessary to use strict authentication and strong encryption to prevent the IDS components from being compromised. For authentication, apply single-use passwords or cryptographic protocols. These are more reliable than a simple request for an identifier or password, which is quite often transmitted as plain text. For example, when running the RealSecure system, before initiating interaction between the console and sensor, it is necessary to exchange authentication keys. If you do not do this, the console will not be able to connect to and manage the sensor. If this kind of protection is lacking, the intruder might be able to install a false sensor and transmit falsified data to the console, thus deceiving the security administrator and wreaking havoc on the logged data. The creation of a false console is even more dangerous, as it can intercept control over remote sensors and change their configuration, as well as, for example, disable the detection of specific events or the function charged with sending administrative alerts when certain events are detected.

All of the data transmitted between the console and sensors (including updates to the vulnerabilities and attack signatures databases) must be encrypted and subject to data integrity control. This will help to prevent unauthorized access to this data and its modifications.

Control over the IDS Components Activity

The intrusion detection system is one of the most critical components of the information security infrastructure. Because of this, it must be protected from various external influences and interruption of the communication between the management console and the sensors. Although the sensors continue operating even if this connection is interrupted (see Chapter 6), you need to ensure mechanisms for detecting such violations and protecting the IDS against them.

In a geographically distributed network, where IDS sensors are installed far from the management console, it is necessary to provide the capability of controlling their activities. The failure of a particular sensor, the interruption of the connection to any sensor, and other errors of this type must be registered immediately and reported to the intrusion detection system operator. Such mechanisms are implemented in most intrusion detection systems, including RealSecure and Cisco IDS.

One such mechanism uses TCP (or another similar protocol), which allows you to establish a virtual connection between the sensor and the console (or management server). If this virtual connection is interrupted or terminated, it will immediately become obvious. Cisco has developed a rather interesting UDP-oriented Post Office protocol for its Cisco IDS product. Using this protocol, each component of the Cisco IDS is specified by a unique address, comprising three parts: "Organization," "Host," and "Application." This addressing scheme serves as the basis for the point-to-point protocol, which ensures up to 255 alternate routes between Cisco IDS components. As soon as the system detects that the connection between the sensor and management console (or between two consoles) has been interrupted, it automatically switches to an alternate route, etc. If the interrupted connection is restored (using the HeartBeat mechanism) the system switches back to the restored connection. All missed packets are sent anew. The Post Office protocol is used for implementing hierarchical management in the Cisco IDS 4200 [NetRanger1-99].

Fault Tolerance, Availability, and Reliability

In mission-critical applications, for which it is necessary to ensure high availability and fault tolerance, it is possible to utilize intrusion detection systems that implement backup, standby, and clustering mechanisms. There are three types of standby mechanisms. Hot standby provides the ability to automatically switch between the main and the backup intrusion detection system. Using hot standby minimizes the possible downtime of the intrusion detection system. Warm standby requires small configuration changes before switching between the main and backup intrusion detection systems. Cold standby requires significant configuration changes. Both intrusion detection system sensors (Fig. 9.16) and their consoles (Fig. 9.17) are subject to backup.

Fig. 9.16. IDS console backup

Fig. 9.17. IDS sensor backup

Backup consoles are used in Cisco Secure IDS and System Scanner, while the RealSecure for Nokia system is an example of sensor backup. As its name implies, this IDS was created by the cooperation of Internet Security Systems and Nokia. Here, two or more sensors can be joined into a cluster, thus improving the reliability of the intrusion detection system in networks with high requirements regarding availability.

Another example of sensor backup is demonstrated in the Cisco Secure Integrated Software, which is built into the Cisco Systems network equipment. Since backup capabilities (such as using the Hot Standby Routing Protocol (HSRP) are included in most products from Cisco, this function is also automatically implemented in the intrusion detection system (although in a somewhat limited mode).

Besides employing backup devices, other methods that often are not related to a specific intrusion detection system can be used. Such mechanisms include a fault tolerance level, which is present either at the software level (Compaq solutions) or at the hardware level (solutions from Intel, 3Com, etc.).

Compaq's Advanced Network Error Correction Support for Windows NT mechanism provides network-level fault tolerance for network adapters, cables, and hubs [Compaq1-98]. Compaq's Advanced Network Control Utility and NetFlex-3 Device Driver Controller are used to configure coupled network adapters on Compaq Proliant servers. These configuration changes are carried out at the following levels:

• Network adapter

• Cable

• Hub

This mechanism, designed for RealSecure Network Sensor and supplied with Compaq servers, functions according to the following principle: one of the network interfaces is designated as the primary interface, while the other is designated as secondary. When the driver detects the failure of one of the cards, it automatically switches to the other card. This can occur due to the following reasons:

• Cable failure

• User-initiated switching

• NIC performance degradation

• Other hardware problems

3Com provides fault tolerance in its network adapters using a custom approach. The company has developed the DynamicAccess technology, which is integrated into server NICs such as 3Com EtherLink Server NIC 3C980, 3C980B-TX, and 3C980C-TC. These adapters provide mechanisms that improve the reliability of the network sensor.

• Self-Healing Drivers. These ensure the reliable operation of the network sensor by monitoring network connection performance and other parameters. When necessary, these drivers perform corrective actions. Situations leading to failures include access collisions and carrier loss. Corrective actions include driver reloading, checking connection integrity, and switching to another adapter.

• Resilient Server Link. This provides the capability of restoring the connection in the event of network adapter failure and redistributing the traffic between the adapters that remain in operation. This procedure is absolutely seamless and transparent to the user. As long as this task is performed quickly enough, it ensures continuous network operation.

Intel has introduced the AFT (Adapter Fault Tolerance) technology, which incorporates functions similar to those in the DynamicAccess technology. This technology is used in the Intel PRO/100 and Intel PRO/100+ families of adapters.

Integration with Other Tools

Not every intrusion detection system is the primary tool for network protection, and even the primary security system might play a minor role in the general communications infrastructure. Quite often, security departments are subordinate to IT departments. In organizations where this is the case, a network management system is adopted as the corporate standard (HP OpenView is one example). These corporations usually try to integrate all other tools (including security tools) with this system. Therefore, when choosing an intrusion detection system, it is necessary to take into account its ability to be integrated with network management systems and other products used within your organization.

Network Management Systems

As I mentioned above, some intrusion detection systems can be integrated with network management systems. For example, in Cisco IDS, coordination with other components is performed via a console (Cisco IDS Director), which is the plug-in module of the HP OpenView system (for managing Cisco IDS, it is also possible to use Cisco Secure Policy Manager and Cisco IDS Device Manager). Besides using plug-in modules, integration can be done using the SNMP protocol. This capability is provided by practically every commercial intrusion detection system - for example, in RealSecure Network Sensor, NetProwler, etc.

Other Management Systems

Besides using the above-mentioned systems, management can be carried out using other products. For example, Cisco Secure IDS Sensor can be managed by the Cisco Secure Policy Manager (instead of Cisco Secure IDS Director), which also has priority over Cisco Secure PIX Firewall, Access Control Lists (ACL) for Cisco routers, Cisco VPN tools, and Cisco Secure Integrated Software [Schaer1-00]. The only thing that complicates this situation is the availability of two CSPM versions with the prefixes i and f, which are responsible for managing intrusion detection systems and firewalls, and ACL and VPN, respectively.

Another example of a management system is the Spitfire system developed by the Mitre Corporation in response to an order from the 609th information warfare force of the U.S. Air Force Electronic Systems Center and Hanscom AFB [Spitfire1-99]. Other users of this system are NAVAL and Army Land Information Warfare Activity. Despite the fact that Spitfire is not a commercial product and is available only to U.S. government organizations, I would like to provide a brief description of this system. The system is designed to gather data on attacks and cases of misuse from two intrusion detection systems adopted by the U.S. Department of Defense - RealSecure and Cisco Secure IDS (NetRanger). Special MITRE Alarm Loader agents are installed on computers running RealSecure WorkGroup Manager or Cisco Secure IDS Director management consoles. These agents are responsible for converting and transmitting records from RealSecure and Cisco Secure IDS log files to an Oracle database (Fig. 9.18).

Fig. 9.18. Architecture of the Spitfire system

The Spitfire management console is created using PowerBuilder. It is responsible for rendering an analysis of data from RealSecure and Cisco Secure IDS network sensors (Fig. 9.19), as well as for managing and controlling these sensors. All management is performed using the IP*Works system developed by devSoft. The Spitfire system supports operating systems such as Windows NT and Windows 95/98.

Fig. 9.19. Graphic user interface of the Spitfire system

Another example of a product that can manage intrusion detection systems is the well known Firewall-1 (VPN-1) firewall from Check Point, which was designed with the OPSEC initiative in mind. This initiative allows developers to integrate different security products. For example, intrusion detection systems such as RealSecure Network Sensor, NetProwler, eTrust IDS, and Anzen Flight Jacket can reconfigure CheckPoint Firewall-1 via the SAM protocol.

Protection Tools

Quite often, intrusion detection systems are united with other protection tools installed in the corporate network. This provides the ability to create a unified complex center to provide information security for the organization. Most often, intrusion detection systems (especially network-level IDSs) work together with firewalls. For example, RealSecure Network Sensor can reconfigure the Check Point Firewall-1, NetProwler can integrate with Raptor, eTrust IDS can configure Check Point Firewall-1 and eTrust Firewall, and Snort can alter rules created on the IPCHAINS screen. Besides firewalls, intrusion detection systems can also be integrated with other protection tools. For example, Cisco Secure IDS can change access control lists (ACL) on Cisco routers.

Correlation Systems

Intrusion detection systems and security scanners create detailed reports on potential points of weakness in the information security system, and are able to react to attacks in real-time mode. Firewalls allow only specific types of traffic to pass. All information registered by these tools is vitally important, since it enables security administrators to develop an efficient security policy and evaluate the capabilities of a policy to be implemented.

Unfortunately, the gathering, correlation, comparison, and analysis of all of the data from numerous independent sources is time-consuming, and requires skilled personnel. This is due to the fact that different types of products are not compatible or related to each other and are unable to create a generalized "snapshot" of the network's security status or reconfigure network security tools in response to an attack or a change in network configuration. Even more important, they can not use the data they generate to implement efficient changes in the security system by dynamically changing the settings of the attacked hosts or performing a security analysis in order to make sure that there are no other systems vulnerable to the detected attack.

To unite the data from different security tools, including intrusion detection systems, it is possible to employ various correlation systems, which allow for the collection of data from security scanners, intrusion detection systems, firewalls, and other security tools located at different points of a distributed corporate network. This approach provides you with an overview of the security status of the network as a whole. Using this system, security personnel can concentrate their attention on the main problems related to the vulnerabilities found at the most critical segments and hosts of the corporate network.

The list of such systems includes:

• SAFEsuite Decisions from Internet Security Systems. This system is oriented towards ISS security products.

• netForensics from the company of the same name (http://www.netforensics.com).

  This system is oriented towards security tools provided by Cisco Systems.

• Private I from Open Systems (http://www.opensystems.com).

• Security Manager from Intellitactics (http://www.itactics.com).

• SPECTRUM Security Manager from Aprisma Management Technologies (http://www.aprisma.com).

All these systems support a wide range of security tools. However, they all have one significant drawback - they are all unable to change the settings of the supported systems according to the analysis results. The only exception is the RealSecure SiteProtector system, which not only analyzes the data received from different security tools, but can also manage their settings.

When choosing one of the above systems, bear in mind that they also need to updated, just like the security tools that they support. Furthermore, the correlation system must update its knowledge base with information on new attacks and vulnerabilities each time an IDS or security scanner update is released; otherwise it will be unable to analyze unknown events. Note that most advertising materials never mention this fact, only specifying that the product supports various intrusion detection systems, firewalls, proxy servers, and so on.

Performance

Most manufacturers will try to assure you that their systems are capable of handling 100 Mbit/sec traffic, or even "operate at the speed of the physical channel." The real situation, however, is not quite as remarkable (I will cover this aspect in more detail in Chapters 10 and 12). However, I would like to mention that this criterion is not that important for organizations that plan to use an intrusion detection system at the network perimeter, since the total inbound traffic does not even come anywhere near that speed. On the other hand, internal traffic not only reaches this value, but quite often exceeds it.

The Influence on the Performance of the Network or Host

The IDS's influence on the performance of a controlled host or network is a criterion that is rather difficult to describe. First, the chosen IDS must not significantly degrade the performance of the controlled system. The reason for this is obvious. When selecting and testing an intrusion detection system, you should first estimate the maximum workload on the system to be controlled in order to preview the behavior of the chosen tool under these conditions. It should be mentioned that this criterion is applicable mainly to host-level intrusion detection systems, since these systems are the ones for which performance degradation is a matter of primary importance. As a rule, an IDS decreases the performance of a protected host by 1-5%. However, with an incorrect configuration, this parameter can grow to up to 20% or even more. On the other hand, the IDS/9000 system developed for detecting attacks on hosts running the HP UX OS decreases the performance of protected host by less than 1%.

Installation and Configuration

Normally, this group of criteria is not tested carefully for the chosen IDS. However, this is a big mistake. In a large network, unskilled installation can drive even the most friendly and good-natured administrator crazy. In part, this topic is covered in Chapter 11. Here I will just point out some specific aspects that need special attention:

• Remote installation. Check to see if the chosen system implements a mechanism that allows you to perform remote installation without the presence of the security administrator. Certainly, the installation process does not always run smoothly, and sometimes it might need the administrator's intervention. Sometimes, however, this capability might be necessary (especially if you need to install the IDS on hundreds and hundreds of workstations).

• Automatic installation. This criterion is also very important to systems installed on a specific host. After installing an IDS once and saving all system prompts and your answers in a special file, you will be able to replicate this file along with the system distribution, and thus significantly simplify the process of installing the system on a computer with an identical configuration.

• Access control. As I already mentioned, the IDS itself must be protected from attacks. Because of this, it is desirable to create the appropriate IDS user accounts and specify the appropriate access rights during installation.

• Predefined configuration. In order to reduce the time required for deploying the system and bringing it into operation, you should have a mechanism for creating a predefined configuration. Depending on the system, this mechanism can be implemented in different ways. For example, when installing integrity control systems, it is advisable to create checksums for all protected files (naturally, before doing so, you have to make sure that the host is not infected by a virus or compromised by Trojans or Internet worms). Quite an interesting mechanism is implemented in the NetProwler system, which scans the hosts of the controlled segment and determines their operating systems. When this operation is complete, the system enables only those signatures that are applicable to the detected operating systems. The availability of standard templates on the basis of which the administrator can create custom templates for a protected host or network segment is also a benefit.

• Distribution of authentication keys. When dealing with an IDS based on a client/server architecture, you need to solve the problem of the distribution of authentication and encryption keys. This problem must be solved while installing the IDS components.

If the IDS requires additional software (such as Internet Explorer, virtual Java machine, databases, etc.), this additional software must be included into the distribution set. If this condition is not met, you might encounter problems during installation. A most frustrating situation is one in which it becomes evident during installation that this additional software costs quite a bit.

Availability of API and SDK

The availability of an application programming interface (API or SDK) is an additional criterion that becomes important if your company has qualified programmers who integrate purchased tools with custom software, or if the company needs to perform this integration for a customer. In the latter case, you can use API to implement the management of the IDS sensors from the custom management system. Usually, IDS manufacturers rarely implement such an API, since this requires additional expenses that thus might not bring the expected profit. Therefore, only a limited number of manufacturers provide a built-in API or SDK. However, you should not confuse the above-mentioned SDK and API with a similar term introduced by the WebTrends Corporations in its WebTrends Security Analyzer product. This company provides the so-called POST initiative (Platform for Open Security Testing) SDK, which is intended for writing custom vulnerability checks [WebTrends1-00, WebTrends1-98].

Technical Support

Even if you choose the most efficient intrusion detection system, from time to time you might need technical support from the manufacturer or vendor. The technical support service might include consulting services by phone or e-mail, software updates, maintenance work at the customer's location, and informational support, training, technical seminars, and so on. High-quality technical support is very important, since quite often several days elapse before obtaining an answer to a request sent. Often, the fact that the client's request has been received is not even confirmed, and therefore the customer does not know what to think when there is no answer for two or three days. These questions might be vitally important to the operation of the whole network. Although it is rather difficult to cover all the criteria for evaluating the quality of the technical support, I will briefly describe the most common ones.

Support Levels

Manufacturers usually offer from two to five support levels, which differ in the range of services provided, response times, etc. The first level includes only software updates as new versions are released (this level is provided by the Check Point company). The services provided at the second level (which some companies include in their first-level support services) also include technical support services. These are also provided at the next level, but there the response times are much shorter. For example, you generally have to wait from 12 to 24 hours for a response at the second support level, while the wait at the third level is from 6 to 12 hours, at the fourth it normally does not exceed 6 hours, and responses at the fifth level generally come within 1 hour.

Support Method

Methods of supporting IDS users also can differ, starting with the usual methods of corresponding via e-mail or phone, and progressing to on-line chats and tracing incidents via the Web. Depending on the support level and the cost, the support service provider might delegate a support specialist to work with the customer on an individual basis. A rather good source of information is the so-called knowledge base, which stores descriptions and solutions to common problems encountered by other customers.

Business Hours

The business hours of the technical support service are the most important parameter of technical support. There are two possibilities - 5×8 (business hours only) or 7×24 (twenty-four hours). The first is the most common, since it is easier to implement. However, in such a case, time delays are inevitable, especially if the customer and service provider are located in different time zones. If there is 7 × 24 support, this problem does not arise.

Mailing Lists

Mailing lists are an additional element of technical support, which simplify the job of IDS users. The creation and posting of the mail can be performed either by the manufacturer or the IDS vendor. In the first case, this usually is done in the form of a mailing that contains general news, information on upcoming releases, etc. Manufacturers may also generate mailing lists, answers to most frequently asked questions, and answers from technical support services or from other users that have encountered similar problems and managed to solve them themselves. Such lists can also be published in the form of a Web conference on the company's web server. The vendor can also operate a localized mailing list that is oriented toward foreign customers.

Attack Database

Attack or vulnerability signature databases are compiled and published on the Internet by practically every vendor that offers intrusion detection systems. These databases enable users to become acquainted with the late breaking news and technological advances both in the field of hacking technologies and in the field of data protection. Examples of this type of database are those supported by ISS (the X-Force group - http://xforce.iss.net), Symantec (the SWAT group), and Cisco Systems.

Training

We have covered training in great detail, so we will not repeat it here. Just be aware that most system developers and vendors offer at least some training on the basics of operating and using their systems.

Cost

Cost is, perhaps, one of the most important criteria that needs to be taken into account when selecting an intrusion detection system. Quite often, organizations choose a cheaper solution rather than one of the more efficient ones available. Clearly, this is not the best practice, but price must be taken into account. Because of this, most manufacturers offer special programs aimed at potential customers. The most common methods of this marketing approach (without mentioning the vendors that apply these methods) are listed below.

• Arranging payment for the chosen system on an installment plan.

• Discounts for customers purchasing several tools from the same manufacturer.

• Special prices for educational institutions.

• Discounts for customers switching over from a competitor's product.

Flexibility

Even the most efficient intrusion detection system can not satisfy absolutely all user requirements. Because of this, a high-quality IDS product must provide flexibility, to allow users to customize it according to their specific requirements. There are several chief mechanisms that determine an IDS system's flexibility.

Other Criteria

Quite often, we think about intrusion detection systems in a very narrow sense. Most times, people think that intrusion detection systems are only for protecting corporate resources. In practice, however, this is not so. Intrusion detection systems are vitally important components of a corporate network. If this component fails, the whole network is at risk. Because of this, when creating (or choosing) an intrusion detection system, it is necessary to consider all aspects that are characteristic for all critical systems.

Assigning Priorities to Criteria

Most of the above-described criteria can be included into the following table, describing their importance (on a scale of 1 to 3) for various categories of users (Table 9.4).

Table 9.4. Priorities of IDS Selection Criteria for Different Categories of Users

Criterion	Small businesses	Large companies	International corporations	ISPs	Service providers	Government organizations
Attack database updates	3	3	3	3	3	3
Update method	1	3	3	2	3	3
Creating custom events	1	2	2	3	3	2
Monitoring of custom events	3	2	1	1	1	1
False negative notifications	2	2	2	3	3	2
Creating custom responses	1	2	2	2	3	1
Remote control	1	3	3	2	3	3
Unlimited number of managed sensors	1	2	3	2	3	3
Hierarchical management	1	2	3	1	1	2
Group operations over the sensors	1	2	3	2	2	2
Event correlation	1	2	3	1	3	3
Dynamic priority changes	1	2	3	1	3	3
Trend analysis	1	2	3	1	3	3
Event representation	3	3	3	2	3	2
Grouping of protected resources	1	2	3	1	3	2
Centralized management console	1	2	3	3	3	3
Time synchronization	1	1	3	1	3	3
Automation	1	2	3	1	2	2
Template support	1	2	3	1	3	3
Protection against unauthorized access	1	2	3	3	3	3
Fault tolerance	1	3	3	3	3	2
Integration	1	2	3	3	3	2
Installation	1	2	3	1	1	3
Training availability	2	3	3	1	2	2

---