General Problems


Let's consider the above problems in more detail, along with some others.

Updating the Signature Database

A lack of signatures for the most recently discovered vulnerabilities results in an increase in the risk of network penetration. The manufacturer (or vendor) must regularly update the signature database for attacks and vulnerabilities in order to ensure that its product is maintained in the most up-to-date state and meets all the requirements of a contemporary IDS. The less the period of time between the first report on a newly discovered attack or vulnerability and the appearance of a signature or check for it, the more efficient is the intrusion detection system (Fig. 12.1). The competitive potential of the manufacturer depends on the rate and quality of updates for the signatures that identify the newest attacker tools.

click to expand
Fig. 12.1. The interval between a report of a new attack and the release of a signature for it

Heterogeneous Networks

The working environment that exists in contemporary heterogeneous networks complicates the normal operation of intrusion detection systems. This relates to the fact that in most operating systems, there are OS-specific data format standards or agreements. The IDS must collect, aggregate, summarize, and analyze this data. Furthermore, data on the attacks are quite often distributed to hundreds of hosts. One of the goals of intrusion detection systems is collecting data from different operating systems (Unix clones, Windows NT, Windows 2000 and Windows 9x, MacOS, OS/2, NetWare, etc.) in various network environments (Ethernet, FDDI, ATM, and so on). As of now, this task is still relatively difficult.

Unified Security Management

Unified security management is another problem of similar origin. It is possible to apply different policies to different IDS sensors. Furthermore, organizations can use different types of intrusion detection systems (for example, security scanners and classical intrusion detection systems), which significantly complicates the task of correlating their data. The incompatibility of the data collected from different intrusion detection systems from different vendors represents an even more serious problem.

Hopefully, the latter problem will be solved after the adoption of a data format standard for exchanging data between different intrusion detection systems. Such a standard is being developed in the IETF by the IDWG workgroup (which will be discussed later). Currently, however, each manufacturer uses proprietary methods to solve data compatibility problems. In Chapter 9, we mentioned such systems as Spitfire and SAFEsuite Decisions, which provide capabilities of analyzing data from different IDSs on a single console. For example, Spitfire supports such systems as RealSecure Network Sensor and Cisco IDS, while SAFEsuite Decisions, besides native support of RealSecure, ensures the integration of any other intrusion detection system using SDK.

The problem of joining heterogeneous security tools on a single console can also be solved only in certain cases. To do this, you can use SAFEsuite Decisions or netForensics. In addition, I should also mention the Dragon Server product, developed by the Network Security Wizards company and later purchased by Enterasys Networks. This system is very similar to the ISS solution, since it includes two components—the Dragon Sensor network intrusion detection system, and the Dragon Squire host-level IDS (Fig. 12.2). The latter product can act as Syslog and SNMP servers, and is able to receive and analyze data from the following security tools:

  • Firewalls:

    • Check Point Firewall-1

    • Cisco PIX Firewall

    • Raptor

    • NetScreen

    • Ipfilter

    • IPCHAINS

  • Apache web servers

  • Sendmail and Qmail

  • Secure Shell

  • Bind (DNS)

click to expand
Fig. 12.2. Dragon Server

OS Vulnerability

Speaking about securing and trusting intrusion detection systems is a problematic area likely to cause conflict if you can not guarantee that the operating system under which the IDS will run is secure. Even if the intrusion detection system is implemented flawlessly (which in itself is hardly possible), a single security hole in the OS implementation can reduce all its advantages to zero.

Attack on NetProwler 

On June 21, 2000, hackers detected a new vulnerability in the NetProwler intrusion detection system from Symantec. Exploiting this vulnerability resulted in a system failure. The attack was implemented by means of sending fragmented packets to a host controlled by NetProwler. Since the operating system processed such packets incorrectly, the NetProwler IDS failed, since it was receiving these packets from the OS driver.

One possible method of eliminating this drawback is the development of reliable and bug-free operating systems. Currently, however, this goal is very difficult to achieve, since most organizations must use available software (which rarely includes reliable, bulletproof, and trusted operating systems). The second approach implies the use of specialized combinations of hardware and software. As a rule, the operating systems for such solutions are stripped of all unnecessary or redundant functions. However, this approach is only available for network-level intrusion detection systems for which the availability of a dedicated computer is one of the basic requirements.

Lack of a Mathematical Foundation

Since intrusion detection technologies still lack a solid mathematical foundation, there is no possibility of developing efficient methods of detecting attacks and efficiently counteracting them. For the moment, only the anomaly detection methods that are frequently used in commercial systems have a more or less solid theoretical basis. All the other existing intrusion detection methods are based either on the achievements of related fields of scientific knowledge or on the developer's personal opinion. The existing tools and mechanisms have no scientific basis, which keeps you from proving the efficiency of suggested solutions. The situation has recently begun to improve, but the results are still far from perfect.

False Positives

The problem of false negatives and false positives is a rather serious and important one. Most likely, it arises due to the lack of a mathematical foundation for intrusion detection technology. Quite a good example illustrating this situation was provided in Chapter 4 —it was a case of locking the user account after three failed attempts of supplying the correct password. It is not too hard to figure out that the intruder can simply try to guess the password twice each time instead of three times. Proceeding in such a way, the limit of three failed attempts will never be reached, and thus the specified threshold value will never be exceeded. Because of this, the intrusion detection system will not notice this activity. Using the WIZ command in the Sendmail program is yet another example. Historically, this command was used for debugging purposes. However, using it incorrectly allows you to obtain unlimited access to the computer on which the Sendmail program is running. Now this command is used rather rarely when performing authorized actions, and therefore its usage is automatically considered an attack attempt.

False Negatives

Most intrusion detection systems tend to depend on the data sources of an attack. For example, some tools analyze the OS's log files (SysEvent.evt, SecEvent.evt, and AppEvent.evt for Windows 2000 or syslog for Unix). However, most attacks can be implemented in such a way as to generate no events that can be logged by the operating system. Some viruses work in exactly this way. To log as many events as possible, you must either enable the full set of the OS's auditing capabilities (which has a negative impact on system performance) or modify the OS itself.

Advances in the Field of Attack Tools

As was shown in Fig. 2.12, the tools used by attackers have become significantly more sophisticated during the last few years. Intruders use various scanners that can do hidden scanning, use decoy mode and Trojans, etc. This is confirmed by Pentagon experts, who have calculated that attack implementation tools are significantly improved approximately 1-2 times per year. There is quite a serious problem with tools that can be used both for malicious and authorized activities. The list of such tools includes remote administration tools such as NetBus or Remote Administrator, as well as instruments for detecting network adapters in promiscuous mode—for example, AntiSniff, IFStatus, or PromiScan. These tools can also be used both for detecting network adapters operating in promiscuous mode (in order to find unauthorized network sniffers) and for detecting intrusion detection systems (in order to develop a method of bypassing them).

Mobile Code

In this book, the term "mobile code" is used to designate the Java and ActiveX technologies, as well as scripting languages such as JavaScript, Jscript, and VBScript. Mobile code can be used as both an attack implementation tool and as an attack target. In the first case, the danger originates from he fact that the code is downloaded to the user's workstation, where it runs as a normal program (which means that it can access system resources). In the second case, the main goal of an attacker is modification of the mobile code, which serves as a preliminary step before attacking the protected computer. Attacks on mobile code as a tool for performing specific functions are not currently widespread. Mainly, this relates to the fact that as of yet, such code is not used to perform any critical operations, such as financial transactions. However, there are already some examples of banking systems using Java technologies for communication with clients.

According to [Infosec1-01] data, 28% of companies have to face the problem of a lack of security in mobile code, and thus are exposed to a risk of attacks exploiting this feature. To accomplish an attack, mobile code can be implemented in the following forms:

  • A virus that infects the operating system and destroys data stored on local disks. Usually, such a virus constantly modifies its code, thus complicating the procedures of detecting and eliminating it

  • An agent intercepting passwords, credit card numbers, etc.

  • A program that copies confidential files containing business and financial information

  • A module causing Denial of Service.

Such programs can mimic animated banners, interactive games, sound files, etc. Although it is impossible to cover in detail all the aspects of mobile code protection in a single chapter, let's consider several examples that illustrate its influence on the operation of the host on which it is launched. This is the attack that is the simplest to perform. Therefore, any Internet user can be exposed to this risk. Such attacks are usually implemented using the following techniques:

  • Creating high-priority processes performing unauthorized actions

  • Generating a large number of windows

  • "Capturing" a large amount of memory and important system classes

  • Loading the CPU and causing it to enter an endless loop

In [McGraw1-97], there are several interesting examples illustrating the use of mobile code for malicious goals. Particularly interesting is the JavaScript example, which can cause the failure of the host on which it is launched. Notice that a few years have elapsed since this script was written!

Listing 12.1. An Example Illustrating the Malicious Usage of JavaScript

start example
   <HTML>   <HEAD>   <TITLE>Demonstration of Denial of Service attack</TITLE>   </HEAD>   <BODY>   <CENTER>   <H1>Demonstration of Denial of Service attack</H1>   <HR>Hi! How are you?<BR>   <HR>   </CENTER>   <SCRIPT>   while (1) { alert ("All that glitters is not gold!'')}   </SCRIPT>   </HTML> 
end example

As you can see, this script is very easy to implement—it has only one line of code (between the <SCRIPT> and </SCRIPT> tags) that starts an endless loop opening a window containing the following message: "All that glitters is not gold!", which can not be closed. To stop this loop, you have to kill the browser process using Task Manager (in Windows 2000).

The normal approach when detecting mobile code includes scanning all incoming traffic on ports 80 and 443, used by HTTP and HTTPS protocols, to detect suspicious elements (tags, for example). However, this is not sufficient to stop the mobile code, since ActiveX controls and Java applets can be obtained using other methods. For example, let's suppose that the applet (which usually has the CLASS extension) mimics an image file (and has the GIF or JPG filename extension). If the intrusion detection system interprets this file as an image file, it will be passed into the network, loaded into the browser cache, and cause the browser to fail, since the loaded file is not an image. This, however, is not what's important, since the mobile code is already on the computer. Later it can be activated, which will cause serious problems with system security. Another example is the use of a non-standard port for web server operation.

One possible way of protecting, for example, Java applets, is scanning all the traffic within the protected segment in order to detect the presence of specific code fragments. This detection is performed by means of searching for a number identifying byte-code, which in hexadecimal form might look like "CA FE BA BE." However, this approach is rarely used by manufacturers of security tools, since the traffic is usually too intense to filter it over each port to find specific text fragments.

Non-Traditional Channels of Attack Implementation

Strangely enough, most users, experts, and manufacturers believe that hackers use only traditional methods to implement attacks. However, hackers are always one step ahead of the developers of security tools. They are constantly inventing newer methods of attacks, such as Trojans and Internet worms that propagate via unusual channels rarely controlled by intrusion detection systems, such as ICQ, IRC, Flash, Napster, and so on. Besides this, experts do not deny the fact that attacks have been implemented that exploit security holes in various games, such as CounterStrike.

Insufficient Qualification of Personnel

This problem was already discussed in Chapter 7. However, I would like to cover it in more detail because of its importance. The qualification of the personnel operating and maintaining the intrusion detection system is one of the basic parameters that should be taken into account when evaluating the efficiency of the intrusion detection infrastructure. There are lots of examples in which the insufficient skill of an IDS operator resulted in extra time, productivity, and financial losses.

False Alert 

The IDS console displays a warning concerning the detection of an ICMP Flood attack. This attack implies the sending of a large number of ICMP queries to one of the most important hosts of the corporate network. The operator initiates the response procedure and alerts everyone. After an investigation, it becomes clear that a management system is installed on the attacked host, which periodically sends ECHO REQUEST messages in order to check the activity of managed hosts. In response, this system received a large number of ECHO REPLY packets during a limited time period. The IDS interpreted these reply packets as unauthorized activity (Fig. 12.3).

click to expand
Fig. 12.3. Specific features of the management system operation

It should be noted, however, that a false sense of security is far worse than an actual lack of security. When you know that you have no protection, you are always alert, expecting your opponent to attack anytime and anywhere. On the other hand, if the company (especially a large one) has purchased some security tool (and this especially relates to a situation in which the security tool is expensive and actively promoted), the unskilled use of such a system and a lack of understanding of the danger represented by your virtual opponents can result in some rather sad consequences.

Ford Does Not Know When It Was Hacked 

In the spring of 2002, Ford Motors sent warnings to thirteen thousand of its clients, informing them that some information on credit towards purchasing a car had been stolen. The leakage of information took place as a result of cracking the web server of the Ford Credit department. The stolen information contained social security numbers and data on bank transactions of the users. Ford Credit employees could not determine the precise date of the theft—it was assumed that the intruders got access to the information somewhere during the period from April 2001 to February 2002. The fact was detected a year after the supposed attack. Employees of the company identified it by chance, when they noticed that intruders had used database software that differed from the software used in Ford Credit.

Problems with Intrusion Detection

As I already mentioned in Chapter 2, the following hierarchy exists in intrusion detection: security event, attack, and incident. Intrusion detection systems operate at the first and second levels of this hierarchy. The third (topmost) level lies beyond the consideration of intrusion detection systems. Although contemporary IDS products implement some mechanisms for identifying intruders (such as the Track Back mechanism in the ManHunt system from Recourse Technologies purchased by Symantec, or the prototype of the Attack Tracker from ISS), this problem has yet to be solved. Intrusion detection systems operate either with accounts within which the attack is implemented, or with addresses registered as the ones from which the attack originated. As I said before, the intruder can easily spoof these addresses, which complicates the detection of the actual address from which the unauthorized activity originated.

Attacks on the Intrusion Detection System

Intruders are constantly improving their skills, including skills in the field of attacking intrusion detection systems. For example, attackers implement more and more sophisticated methods for penetration and use improved attack methods, starting with automated tools for attack implementation and ending with the tools for hidden scanning.

The first thing that intruders usually attempt to do is identify the location of the intrusion detection system in the corporate network. This can be achieved by detecting a network adapter operating in promiscuous mode (for example, utilities like AntiSniff or IFStatus can be used for this purpose), or by analyzing the open ports used by the intrusion detection system for interacting with its components.

Attack on SessionWall-3 

On June 7, 2000, a new document was published (http://www.phate.net/docs/security/sw3paper.txt) describing various ways of attacking the SessionWall-3 system (currently known as eTrust IDS). This system can be easily detected and identified using simple ICMP packets (a most serious vulnerability, which is not acceptable for any intrusion detection system). All other intrusion detection systems, such as RealSecure Network Sensor or Cisco IDS, can operate in so-called Stealth mode, which prevents intruders from detecting the IDS and, consequently, from attacking it.

Besides this example, there are other ones.

Attack on the Snort IDS 

On June 17, 2000, a new vulnerability was detected in the Snort 1.6 intrusion detection system. This vulnerability resulted in a system failure after using the remote OS fingerprinting mechanism in the nmap scanner (nmap - so) directed against a host with the installed Snort system.

Another Attack on SessionWall-3 

On June 7, 2000, a new vulnerability in SessionWall-3 was revealed. The administrator's password in the SessionWall-3 intrusion detection system, allowing you to get access to the system, is stored in the system registry under the following key: HKEY_LOCAL_MACHINE\Software\ComputerAssociates\SessionWall\1.0\Security. The password is stored as a text string to which the XOR operation is applied. Naturally, this allows the intruder to get the source password and change all its settings without much effort.

Attacks on BlackICE 

On June, 21, 2000, several vulnerabilities were detected in the BlackICE intrusion detection system from NetworkICE. First, the vulnerability in NetworkICE ICEcap console allowed intruders that managed to get authenticated to enter fictious information into the system. ICEcap Manager is the HTTP service that listens to port 8081 and collects data from various BlackICE IDS sensors. Second, ICEcap Manager contains the built-in "iceman" user account, which by default uses a blank password. Thus, using this account, the intruder can access the BlackICE console and introduce unauthorized modifications into the configuration of the remote sensors.

Lack of Agreement between Manufacturers

The next problem relates to IDS manufacturers rather than to intrusion detection systems. IDS manufacturers still can not find a common language and agree to cooperate. For example, it would be wonderful if intrusion detection systems from different manufacturers could integrate with one another and coordinate their work. Right now, however, this is an unattainable dream. This is due to the fact that most manufacturers are reluctant to reveal their "know-how," and do not want to share their achievements and clients with other companies. This certainly does not bring any profit to end-users. This situation will not change until a common standard (such as IDWG) is developed and adopted. Currently, some steps have been taken towards standardization. They will be covered in Chapter 14.

Continuous Mergers and Acquisitions

The security tools market (and, particularly, the IDS market) is a very promising and dynamically evolving area of investment. In the near future, it should yield significant profit. For example, in contrast to 1998, when the total amount of the IDS market in U.S. was $136,000,000 (which exceeded the same parameter for the previous year by 137%), in 2004 this parameter is expected to reach a value of $1,227,000,000 [Kolodgy1-01]. Furthermore, in 1998, the proportion of security scanners to classical intrusion detection tools was given as 67% to 33%, while in 2004 this relationship is expected to become 54% to 46% (Table 12.1).

Table 12.1. Growth of IDS Sales

Security tools

1998

1999

2000

2001

2002

2003

2004


Security scanners (millions of dollars)

91

166.6

252.2

359.3

469.0

562.3

657.2

Growth (%)

141

83

51

42

31

20

17

Market (%)

67

59

52

51

51

52

54

Classical intrusion detection systems (millions of dollars)

45.3

115.7

234.2

350.8

443.5

519.1

570.1

Growth (%)

123

155

102

50

26

17

10

Market (%)

33

41

48

49

49

48

46

Total amount (millions of dollars)

136.3

282.3

486.4

710.1

912.5

1081.4

1227.3

Growth (%)

135

107

72

46

29

19

14

Because of this, several famous contracts were signed on the IDS market during the past few years, which are briefly outlined in Table 12.2.

Table 12.2. Mergers and Acquisitions on the IDS Market

Company

Intrusion detection systems

Comment


Cisco Systems

WheelGroup ($)

 

Microsoft

ISS (A)

Microsoft has licensed from ISS the RealSecure technology for ISA Server

Nortel Networks (Bay Networks)

ISS (A)

 

Lucent

ISS (A)

The Lucent company licensed from ISS its RealSecure intrusion detection system and now supplies it under the Lucent RealSecure trademark

Enterasys

Network Security Wizards ($)

 

Hewlett Packard

Security Force ($)

 

SAIC

Bellcore ($)

 

Intrusion.com (formerly ODS Networks)

ISS (A)

SAIC ($)

RSA Security

($) MimeStar ($)

The Intrusion.com company licensed from ISS the intrusion detection technology used in RealSecure Network Sensor and built it into its security appliances. Intrusion. com purchased its CMDS intrusion detection system (later renamed Kane Security Enterprise) from SAIC, and from RSA Security it licensed its Kane Security Monitor intrusion detection system and the Kane Security Analyst security scanner.

Nokia

ISS (A)

ISS incorporated Nokia security appliances.

Network Associates, Inc.

Secure Networks

Inc. ($)

TIS ($)

ISS (A)

Traxess ($)

As a result of an agreement reached by Network Associates and ISS, the latter has integrated its McAfee antiviral software into RealSecure Network Sensor, and NAI has integrated its network intrusion detection system into its Sniffer protocol analyzer.

Check Point Software

ISS (A)

The Check Point company has licensed from ISS its RealSecure IDS, and up until mid 2001, was releasing it under the Check Point RealSecure trademark.

Internet Security Systems

DBSecure ($)

March Information Systems ($)

Netrex ($)

NetworkICE ($)

vCIS ($)

 

RSA Security (formerly Security Dynamics and RSA)

Intrusion Detection ($)

 

BindView Corporation

Netect ($)

 

Axent Technologies

Internet Tools ($)

 

Symantec

Axent ($)

L-3 ($)

SecurityFocus ($)

Recourse Technologies ($)

 

MEMCO Software

Abirnet ($)

 

PLATINUM

MEMCO ($)

 

Computer Associates

PLATINUM ($)

Security-7 ($)

 

NFR

Anzen ($)

 

Where:

$ — the company was purchased; A—an agreement to cooperate.

Let's consider the motives of these contracts. Provided that we ignore higher revenues (which, of course, is self-evident), the motives can be classified into two groups. Note that the agreements were bi-directional:

  • Extending the range of supplied solutions

  • Building the purchased technologies into the supplied proprietary solutions

Despite the above-mentioned benefits, the perspectives of the mergers and acquisitions above are not as promising as they might seem at first glance. First, not all products and solutions acquired as a result of mergers are really necessary to the purchasing company. As a result, redundant or unnecessary solutions are simply discarded, or the companies just cease to support them. Second, the quality of the technical support for purchased products is often very far from perfect. A third (unnecessary) layer often appears between the developer and end-user. The purchased product often has a low priority for the firm that purchased it. For example, the sales of the Cisco IDS and Cisco Secure Scanner in 1998 made up only 0.1% of the total sales amount for other Cisco solutions. At the same time, for ISS, this parameter nears 100%. By the way, as for Cisco Secure Scanner, this product completed its life cycle in the summer of 2002—Cisco has ceased to sell it, and, starting in 2003, will not support it any longer. Third, customers must face a situation in which a single company supplies a wide range of solutions developed by other manufacturers, which are poorly integrated with one another. Although most companies take steps towards improving this situation, this work is still very far from being complete. Let us consider some typical examples.

Network Associates

Network Associates, Inc. (NAI) is an example of a company providing a whole range of information security tools to its customers. The corporation was founded as a result of the merging of two well-known companies—Network General and McAfee Associates. Starting in 1997, the newly founded corporation has purchased several other companies that previously held leading positions in the IS market, including:

  • Pretty Good Privacy—developer of the popular PGP encryption tools family. By the way, beginning on March 1, 2002, development and sales of the PGP product family were stopped.

  • Trusted Information Systems—developer of the TIS Gauntlet firewall and the Stalker IDS family: Stalker, Proxy Stalker, and WebStalker.

  • Secure Networks—developer of the Ballista security scanner, which is now supplied under the CyberCop Scanner trademark.

  • Dr. Solomon—a company specializing in the field of antiviral software.

The Network General company (whose best-known product is the Sniffer program) has licensed intrusion detection technology from the WheelGroup company, and on the basis of it, developed the CyberCop Network 1.0 network-level intrusion detection system. However, after Cisco Systems purchased WheelGroup, this license was suspended. Still, NAI has taken a fancy to the CyberCop product name, and it has become the trademark for all IDS solutions supplied by the company. Besides CyberCop Scanner, Network Associates supplies the CyberCop Monitor host-level intrusion detection system and the CyberCop Sting deception toolkit. CyberCop Monitor also has quite an interesting background. Initially, NAI was selling the CyberCop Server system for log-file analysis, which was based on the Stalker product family (the technologies implemented in this product family were originally developed by the Haystack company and later purchased by Trusted Information Systems). At the same time, NAI supplied the CyberCop Monitor product. Later, both systems were combined within the framework of CyberCop Monitor.

What could possibly result from NAI's activity other than a wide range of IS solutions? First of all, some of the products developed by the purchased companies are now lost to end-users. For example, the PC Firewall product, announced by McAfee before merging with Network General, was quite a promising development project, to say nothing about such a popular encryption system as PGP (also purchased by NAI and also no longer released or supported). To summarize, end-users have not really gotten much benefit from NAI's purchase of all the above-mentioned companies, except for the fact that now all currently supported products can be purchased from the same vendor. What's even worse, the products supplied by NAI are not integrated with one another, which, from the end-user's point of view, significantly reduces or even brings to naught the efficiency of the plusses.

For example, such activity has caused Network Associate's stock to drop significantly, and much of the upper management to leave. In 2001, the General Manager, President, and Chief Financial Officer left the company, and the turnover for the 4th quarter of 2000 was three times lower than the previous year ($65 million in 2000 as compared to $218 million in 1999).

Furthermore, ISS and NAI have signed a cooperation agreement, within the framework of which, ISS gains the possibility of integrating RealSecure Network Sensor with the McAfee Antivirus, while NAI integrates RealSecure Network Sensor with Sniffer.

Hewlett Packard

Quite recently, Hewlett-Packard has also begun to pay significant attention to network security. As a rule, all of its efforts in this area relate either to extending the functionality of its HP OpenView network management system or to supplying combined solutions to corporate customers. Usually, all such solutions include information security tools from third-party companies.

One example illustrating the extension of HP OpenView's functionalities is the combined solution that integrates it with the Cisco PIX Firewall. As of now, this practice has proved to be rather fruitful and efficient. First, technical support for each product supplied by Hewlett Packard is delivered by the manufacturer of that product, and the range of solutions is practically as wide as the one provided by Network Associates.

However, Hewlett-Packard has also purchased several smaller manufacturers. For example, on August 2, 1999, it absorbed Security Force, Inc.—the developer of the SFProtect security scanner. Besides security analysis technology, Hewlett-Packard has also started to pay attention to intrusion detection (for example, IDS/9000) [Anderson1-99].

Internet Security Systems

Internet Security Systems has also widened the range of the solutions it offers by purchasing such companies as March Information Systems, DBSecure, and NetworkICE. Taking these events into account, ISS currently provides a whole range of security scanning tools, starting with network-level (Internet Scanner) and OS-level (System Scanner) tools and ending with DBMS-level scanners (Database Scanner). The intrusion detection tools supplied by this company also cover practically all levels—from RealSecure Network Sensor (network monitoring) and RealSecure Server Sensor (server monitoring) to RealSecure Desktop Protector (workstation monitoring) and RealSecure Web Protection for IIS (web server monitoring). In addition, ISS was the first company to begin to supply security scanners for wireless networks—the Wireless Scanner product. Finally, in contrast to all the other brands in the field of network intrusion detection, ISS also supplies a so-called inline IDS—the RealSecure Guard system—which, in contrast to other solutions, filters all network traffic rather than listening just to traffic within the network segment using the promiscuous mode of the network adapter. Thus, this system is similar to a firewall installed between protected and public networks.

Quite recently, ISS purchased another small company—vCIS—which has developed a behavior control technology that ISS plans to incorporate into its host-level intrusion detection systems.

Intrusion.com

The Intrusion.com company, previously known as ODS Networks, is also making large strides forward. For example, it has recently purchased such intrusion detection systems as:

  • CMDS from the SAIC company, which in turn purchased it along with the Bellcore company.

  • Kane Security Analyst and Kane Security Monitor from RSA Security. RSA Security (earlier known as Security Dynamics Technologies) in turn purchased these systems after purchasing the Intrusion Detection company.

  • SecureNET PRO developed by MimeSTAR.

Symantec

Until recently, Symantec did not engage in purchasing other companies, its main field of activity being antiviral and system software. However, during the last two years, Symantec has also purchased several companies that specialize in aspects of information security. Axent, which in turn had purchased two smaller companies—Raptor and Internet Tools, known for their firewall and NetProwler intrusion detection system, respectively—was the first company on this list. Later, Symantec purchased the L-3 company, along with its two security scanners—Expert and Retriever. Unfortunately, neither of these systems was included into the range of tools offered by Symantec. One of the advantages of the Expert system was its capability of creating a graphic network map that specified all the detected vulnerabilities for all scanned hosts. The user interface provided by this system was very much like MS Visio's.

After purchasing L-3, there was a "calm," after which, in July of 2002, Symantec declared that it was purchasing three companies simultaneously—SecurityFocus, Riptech, and Recourse. The first company on this list is famous for its portal (http://www.securityfocus.com), as well as for its DeepSight analysis and correlation tools. The second and third are known for their intrusion detection and deception systems—ManHunt and ManTrap, respectively.

Some time earlier, Symantec purchased the MountainWave company, known for its CyberWolf technology that is used for collecting, analyzing, and correlating data received from heterogeneous security tools. Taking into account the purchasing MountainWave and SecurityFocus, as well as the efforts made by most manufacturers to develop event correlation tools, one can draw the conclusion that Symantec has decided to take one of the leading positions in this area of the market.

Hopefully, Symantec will not repeat the errors of Network Associates, and will not discard most of their purchased solutions (although such trends are already noticeable). For example, L-3's solutions are not offered any longer, and the MountainWave portal, which published late-breaking news in the field of information security and was used by most security specialists, has been closed.

What's Next

Thus, the intrusion detection market is swiftly changing. But are these changes beneficial? Right now, it is rather hard to tell for sure, since the situation has not stabilized yet. On the one hand, progress is evident. Intrusion detection systems are being constantly extended and enhanced thanks to integration with other security tools. Furthermore, the integration of these tools into network management systems, such as HP OpenView, provides administrators with flexible capabilities of managing all security mechanisms from a single point.

On the other hand, there are also some negative trends, both objective and subjective. In contrast to the quality of technical support, which could improve with time, the situation with integration of the purchased products and technologies is somewhat different. In some cases, companies purchasing third-party tools manage to combine several technologies and efficiently integrate the purchased products, while in other cases such attempts fail. For example, at the time of writing, there is no central management for the NetProwler and Intruder Alert intrusion detection systems, both of which are supplied by Symantec.

As a result of these mergers, small businesses might be cut off from the information security market. As might be predicted, only those businesses that have developed either new and promising technologies (which are not currently widespread, and consequently have not been purchased by larger corporations) or high-quality products ensuring a high security level unattainable by the so-called "standard" solutions will retain their market positions. This, in turn, will result in a situation in which end-users will have to choose between large and poorly integrated products containing a set of dissimilar and often incompatible mechanisms, or a set of incompatible products. Mainly, this relates to companies that have purchased new technologies in order to widen the range of services supplied to customers (the most illustrative example is Network Associates).

Therefore, although large companies certainly benefit from such bargains, the advantages provided to the end-user are arguable. On the one hand, the consumer can now purchase security tools from a single vendor, but on the other hand, he or she is paying money for incompatible solutions and poor technical support.

Active Response

Despite new perspectives, the capabilities of automatically reconfiguring network equipment or security tools, as well as the possibility of automatically terminating network connections, must be handled with care. These mechanisms, besides serving the goals of company's employees and security personnel, can be exploited by intruders. For example, if the intruder implements an attack on one of the protected hosts, and, when doing so, spoofs his or her actual address with the address of an authorized host, the intrusion detection system can lock access from that host to protected resources (Fig. 12.4).

click to expand
Fig. 12.4. The potential danger of reconfiguring network equipment

The second risk relates to the automatic termination of the connection with the attacking host. In this case, the intruder can also substitute the address of the host to or from which he or she wants to lock access for the actual address (Fig. 12.5).

click to expand
Fig. 12.5. The potential danger of automatically terminating network connections

All these specific features related to active responses are due to the fact that the current IP version does not provide the capability of unambiguously determining the source address of the attack. Therefore, intruders can easily change their actual addresses to any of the available 232. Because of this, these types of responses are recommended for use only within internal networks, or provided that the possibility of address spoofing is eliminated.

Recovery from Attack

Intrusion detection systems can help you detect an existing vulnerability before intruders can exploit it, and can help you identify an attack in the course of its implementation. They can also help you trace attacks that have already been implemented using the traces left by intruders in the attacked system. However, what can you do if the protected host has failed or was compromised as a result of an implemented attack? When dealing with vulnerabilities, the situation is more or less clear—this flaw can be automatically eliminated using the mechanisms implemented in a security scanner. Such mechanisms exist in most security scanners, including System Scanner, STAT, or SFProtect. The situation with attacks is much more complicated. For the moment, intrusion detection systems have no efficient mechanisms that allow you to restore attacked systems to their initial state. This problem is partially solved by integrity control systems, which, having detected unauthorized modifications introduced into a protected file, replace that file with its standard copy. This principle has been implemented in the AutoRestore mechanism of the CyberCop Monitor system, for example. Besides this, there are specialized tools intended only for restoring attacked systems. For example, the WebAgain system designed by LockStep Systems automatically detects all unauthorized changes introduced to web servers, and restores the entire contents of the server without user intervention. Another example is the ERD Commander 2002 system from Winternals Software, which restores a damaged Windows 2000 server after attacks or hardware failures. This system has even been licensed by Microsoft.

What You Should Do In Case of Attack

Earlier in this book, I provided an example in which an unskilled IDS operator was unable to distinguish an actual intrusion from normal network activity. Another example can be illustrated by a case in which the IDS registers the Email WIZ attack, which enables the intruder to get administrative privileges on the host where the Sendmail program is running. The operator initiates the procedure of incident investigation, activates all required tools, and notifies everyone who needs to know about the incident. However, if the operator knew that this attack causes damage only to outdated versions of Sendmail, there would have been no alarm raised. Another characteristic case is the Tribe Flood Network (TFN) attack. It can be implemented only against hosts running Unix. If your network is built exclusively on a Windows platform, then the arrival of the TFN event message indicates a false positive event. Consequently, an intrusion detection system must contain the appropriate manuals and guides describing the specific features of all specific attacks, including false positives. For each detected attack, it would be good to provide a list of characteristic features, descriptions, and answers to the following questions:

  • Attack type

  • Name displayed on the IDS console

  • Technical description

  • Variants of false positives

  • Variants of false negatives

  • Operating systems vulnerable to this attack

  • Why this attack is important

  • What should be done to eliminate the attack or the vulnerability resulting in its implementation

  • References to CVE, X-Force, CERT, Bugtraq bulletins, Novell NetWare Knowledge Base, Microsoft Knowledge Base, etc.

Testing Intrusion Detection Systems

As I mentioned in Chapter 9, another problem relates to the lack of evaluation and testing criteria for intrusion detection systems. All existing methods are rather sparse and unsystematic. This situation is characteristic even for the test laboratories of various well-known magazines (PCWeek, Network Computing, etc.). Quite often, the testing is pre-paid by specific manufacturers. For example, I have seen the results of testing performed approximately at the same time and by the same testers whose results differed significantly. Besides this, a test lab performs experiments using test facilities that only model a real situation, but do not reproduce it completely. This, of course, does not give the testers the opportunity to forecast all situations that the customer might have to face. Quite often, a system that has shown ideal results during testing starts to malfunction in real-world conditions. Yet another shortcoming of such testing is the evaluation based on quantitative criteria. This means that all criteria are assigned weight coefficients, according to which the results are then summed to produce the total grade. The system that shows the best result according to this system of evaluation is then declared to be "the system of choice" or the "winner." This system does not take into account that fact that end-users might assign different weight coefficients to evaluation criteria according to their requirements. For example, some consumers give priority to the problem of centralized management of the IDS components, while for other companies this criterion is not a matter of primary importance. Because of this, I recommend that you critically evaluate various ratings and awards, even if they are assigned by well-known and popular magazines. Only the end-user can correctly evaluate a system. For this purpose, however, he or she must know the evaluation criteria and method. Currently, there is not much serious research work in this field, the best research being performed by the Los Alamos Test Lab [Jackson1-99] and NSS Network Testing Laboratories [NSS1-00]. The best result, however, was achieved by Lincoln Lab. This organization designed the first standard describing the testing method and requirements for the IDS testing process.

Semantic Compression

To ensure efficient intrusion detection, it is necessary to control and perform detailed logging of a large number of events taking place in the information system. This produces quite a large amount of data, most of which are not of any interest, but are stored for subsequent analysis in order to detect any suspicious events. Storing large amounts of data requires that you find a solution for the following two problems:

  • Development of mechanisms for efficient usage of disk space designated for storing log files and network traffic data.

  • Development of mechanisms for efficient representation of data that may be of any interest to the security administrator.

Both of these problems are interrelated. However, I will cover in detail only the second one. Most security specialists have encountered a situation in which the intrusion detection system generates thousands or even hundreds of thousands of records about various events taking place in large networks. No administrator is able to analyze these events manually. Although the intrusion detection systems available on the market provide tools for combining several events of the same type within a single record, the solutions they provide are far from perfect, and work on this must continue.

Currently, there are several manufacturers and research centers that develop efficient data representation methods. For example, at the end of June 1999, the ISS company announced the so-called Fusion Technology, which it implemented in the Fusion Security Module of its RealSecure SiteProtector product. The CERIAS research center also performs research work in this area. This center has even created a workgroup for developing an efficient log-file format and for convenient methods of representing log-file data to security administrators.

Lack of Mechanisms for Proving Attack Facts in Court

Collecting irrefutable proof for court or for an internal investigation is a logical accomplishment of an IDS. However, most of the problems that were already covered in this chapter prevent security specialists from collecting a sufficient amount of reliable data. These problems include the ambiguous identification of the intruder, or the probability of address spoofing. Besides this, representatives of legal organizations usually do not have the skills to allow them to make sense of the messages generated by intrusion detection systems. Because of this, contemporary intrusion detection systems must implement mechanisms that simplify the collection of proof and their representation in a form convenient for such individuals (police officers, lawyers, etc.). As of now there are not many intrusion detection mechanisms that provide this. RealSecure Network Sensor and SecureNet PRO are two of them. These systems implement event tracing mechanisms that allow you to record the whole sequence of the intruder's activities and then reproduce them (so-called replay or playback mechanisms). Notice that these events can be replayed in real-time, accelerated, or slowed-down modes, in order to analyze the intruder's methods, skills, the tools used for attack implementation, etc. This all should help to collect the proof required for a court.




Protect Your Information with Intrusion Detection
Protect Your Information with Intrusion Detection (Power)
ISBN: 1931769117
EAN: 2147483647
Year: 2001
Pages: 152

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net