The Evolution of Intrusion Detection Systems — The Next Step

The Evolution of Intrusion Detection Systems — The Next Step

Computers & Security, 20 (2001) 132-145 The Evolution of Intrusion Detection Systems — The Next Step Richard Barber Articon-Integralis,Theale House, ...

88KB Sizes 9 Downloads 78 Views

Computers & Security, 20 (2001) 132-145

The Evolution of Intrusion Detection Systems — The Next Step Richard Barber Articon-Integralis,Theale House, Brunel Road,Theale, Berkshire, RG7 4AQ, UK.

The current situation in the intrusion detection arena has spurred global information security group Articon-Integralis to make the next step in Intrusion Detection Systems. Accordingly, the group decided to conduct a detailed commercial, corporate and technical assessment of all key players in the market during the second half of 2000. This article will look at the specification that drove the selection and test process and will cover the key technical parameters which were used to assess each offering. It will go on to detail the topology, machines and attacks that were used to make the assessment. It will also attempt to give some insight into the process that the group has adopted to keep abreast of all key ‘best of breed’ security products and the companies that provide them.

Introduction Current market-leading Intrusion Detection Systems (IDS) fill a very necessary role in the ongoing and escalating conflict between corporates defending their computer networks and information assets; and the hacking community who feel it necessary to probe, assess, attack and invade these networks on a quest for information. However, it has been understood for some time and has become more obvious in recent years, that traditional IDSs have not been scaling up sufficiently and are failing to adapt to the increasing role and workload of the corporate network. Developments such as switched networks,

132

100MB Ethernet, server-type operating systems on the desktop (e.g. NT4/2000), have left the IDS market in such a state that well-respected security specialists such as Stuart McClure and Joel Scambray (authors along with George Kurtz of Hacking Exposed), have publicly stated that the death of network IDS is at hand. Clearly not an encouraging statement for corporates hoping to defend themselves against hacking attacks in a proactive manner. So, is this article just a clever means to ensure revenue keeps flowing and the corporate coffers of resellers, integrators and manufacturers keep on being lined? No. The Network IDS (and IDSs in general) is very much alive but some evolution of the genre is required. Many technologies go through a sea-change in their history, usually when they hit their limitations. Then a different approach is adopted which provides it with a new lease of life. This is what Articon-Integralis went to find.

Assessment Criteria — The Three Forces at Work Product selection requires an assessment of the manufacturers.The main three ‘forces’ addressed are:

Computers & Security, Vol. 20, No. 2



Technology: This addresses how well the technology has been implemented and how well it meets its objectives.



Corporate: This section deals with the stability of the company that created the product.



Commercial: This section deals with how the company views its own market and competition. What are its long-term goals? How well-defined is their strategy?

What is needed is a balance of these three factors to provide a thorough assessment of each product.

Technical Forces First, to set the scene for what follows.There is what seems to be an eternal battle between two sets of purists. On the one side we have the technical people who want the most technically capable product and eschew anything less. This usually means selecting the best operating system for the job (usually a Unix flavour although it could mean a mainframe OS), and then putting the best application or tools on top.This approach is the best one if a tool is going to be operated by a highly capable technologist. However, experience shows that if many people with differing levels of IT security skill need access to the same tool, then it has to be made appropriate for use by those with less knowledge and skills. Corporates cannot afford to be prevented from protecting themselves simply because they do not have highly skilled resources to hand. There is a very similar story in the operating system space. All sorts of people need access to a fullfeatured OSs and a set of compatible applications. Unix was too complex for the majority of the market and in went Microsoft amongst others to meet the needs of many more companies. Nobody is suggesting that Microsoft products are excellent but their approach to the market is the most successful one because it meets the needs of the majority.

So, this means that most tools that require Unix skills are not likely to be the products of choice for the market at large. However, a product that uses Unix (or similar) with the right balance of strengths cannot be ruled out. This would generally mean Unix is used in parts of the network that users don’t handle and Windows where they do. This is an approach — not a mandate. Then, the main driver in selecting a product for a commercial company is simple — there has to be a market. This whole exercise was based on a recognition that the current market leaders were not providing the performance that their own market needed if it was to defend itself against hackers.

Commercial Forces Besides the technical efficacy of a particular technical solution there is the necessity of being confident that the supplier will remain in business long-term. The best technical solution is not going to help if the designer cannot continue to supply, update and extend the design. This is an area where open source code could score highly but does not provide the commercial confidence that the supply chain and the market in general requires. For example corporate entities are not likely to deploy mission critical applications on Linux servers if they cannot have a commercial support contract to protect them against system failure. It is true that a large number of IT professionals use Linux within their corporations but usually not for business critical applications.The popularity of Linux can be seen in the fact that so many applications are now developed and supported on Linux platforms but it is very unlikely that Linux would have achieved corporate respect-ability without such commercial foundations. But despite this progress Linux is still not an end user product. As part of the commercial assessment of IDS providers, we asked questions about sales focus, marketing and technical support, territorial coverage, and the ability to support the commercial chain to the

133

The Evolution of Intrusion Detection Systems — The Next Step/Richard Barber

end-user and quality of support materials.There are no right or wrong answers here and timing is a crucial element in any assessment. If product companies are reviewed at the ‘wrong’ time they simply aren’t ready even if their plans include a schedule for being ready. Or they may be at a key stage in negotiating a new relationship and be unable to reveal further details. Any number of reasons may mean that a product is not selected for commercial reasons and there can be no fault assigned or attached to any of the parties.

Corporate Forces The corporate forces are the foundations of the product vendor.They overlap somewhat with commercial forces as the two are closely related. The corporate forces are the establishment and realization of a vision (usually driven by one person or a small group of people within each organization).They set the scene and direction for the company. Three factors need to intersect for success: the market need, ArticonIntegralis’ objective and the strength and background of the players in the market. Again, timing is a critical variable in this equation.

in any areas. An exhaustive test would have taken far too long and would not have proven that a particular product would always detect all attacks.

Technical Assessment All products were installed on a non-switched, routed network with a number of attack and monitoring machines. A variety of operating systems were also used including Windows 98 & NT, Linux (SuSe distribution, Solaris 2.6 etc.). These products were evaluated against the following criteria: • Attack recognition • Ability to handle IP fragmentation • Performance under load (with and without IP fragmentation) • Ease of installation • Management and administration • Logs and reporting • Documentation The Network topology is depicted in Figure 1.

So, the questions asked are: • How long had they been in business? • What are their sources of funding and business plan? • Who are their key technology partners? • Who are their key customers?

The Process Articon-Integralis assembled a list of 15 commercially available IDS solutions. By applying the above criteria these were reduced to just six.These six were asked to supply the latest version of their product(s) and several man-months were devoted to performing the technical assessment. Manufacturers were shown the test set-up and allowed to participate in the set-up so that their products would be shown in their best light. The purpose of using these tests was not to exhaustively assess the detection capabilities of each of the products but to discover if they had problems

134

In order to test the IDS solutions properly a total of eight machines were built — some as attack machines, others as the targets, some more as sensors and others to generate traffic on the network. This number was also needed for the tests to enable different operating systems from SuSE Linux 6.3 (kernel version 2.2.12) and Windows NT (4.0 SP5) to Solaris 2.6 to accommodate the requirements of the six IDS’ that were finally tested. The full list of machines used and their set ups are below:

Machines attack1.attack.net IP address: 192.168.20.10 Memory: 128 MB Disk: 8GB OS: SuSE Linux 6.3 (Kernel version 2.2.13) Purpose: Source for Unix based attacks

Computers & Security, Vol. 20, No. 2

Figure 1 - Network Topology Software: various Unix based attack tools (see below),Web-Browser attack2.attack.net IP address: 192.168.20.30 Memory: 128 MB Disk: 8GB OS:Windows NT 4.0 SP5 Purpose: Source for Windows based attacks Software: various Windows based attack tools (see below) fragsun.attack.net IP address: 192.168.20.21 Memory: 128 MB Disk: 3GB OS: Solaris 2.6 Purpose: Fragmentation of packets for testing the

packet reassembly capabilities of the IDS systems. For the fragmentation tests, the route of attack1 and attack2 to the .22-net was set to this machine. Software: fragrouter 1.6 (see below) target1.ids.net IP address: 192.168.22.30 Memory: 64 MB Disk: 2GB OS: SuSE Linux 6.3 (kernel version 2.2.12) Purpose: Linux target Software: Apache web server, sendmail SMTP server, telnet and FTP daemons target2.ids.net IP address: 192.168.22.20 Memory: 128 MB Disk: 8GB

135

The Evolution of Intrusion Detection Systems — The Next Step/Richard Barber

OS:Windows NT 4.0 SP5 Purpose:Windows target Software: Netbus server and Subseven server target3.ids.net IP address: 192.168.22.40 Memory: 128 MB Disk: 4GB OS: Solaris 2.6 Purpose: Solaris target Software: telnet and FTP daemons console.ids.net IP address: 192.168.22.50 IP address: 192.168.25.100 Memory: 128 MB Disk: 8GB OS:Windows NT 4.0/SuSE Linux 6.2 (Kernel 2.2.10) Purpose: Installation of IDS management software Software: management and administration software for each IDS, each one on an individual partition sensor.ids.net IP address: 192.168.22.10 IP address: 192.168.25.10 Memory: 512 MB Dual Pentium III 700 MHz For this machine three different configurations have been used: •

Windows based IDS Disk: 2x18GB SCSI OS:Windows NT 4.0



Dragon by Network Security Wizards (on Linux) Due to problems of the Linux kernel with the SCSI disks, an IDE disk has been used here. OS: SuSE Linux 6.2 (Kernel 2.2.10)



Appliance for Anzen Flight Jacket Anzen Flight Jacket requires an IDE hard disk and IDE cdrom.

Purpose: Installation of network sensors. Software: Network sensor of each IDS, each one on an individual partition.

136

Cisco router IP address: 192.168.20.10 Memory: 32 MB/16MB flash OS: IOS 12.0.8.fc1 Purpose: Routing between the two networks

Attack Tools The attacks tools themselves were many and various —23 different tools in total ranging from ‘teardrop’ which generates an IP fragment overlap attack to ‘synk4’ — a SYN flooder which spoofs source addresses randomly. The full list of attacks and what they do is below: fping Source: http://networking.stanford.edu Version 2.2b1 Use: fping is able to ping a several machines at once. fragrouter Source: http://www.anzen.com Version: 1.6 Use: fragrouter is a program that performs fragmentation on incoming packets and forwards them to the gateway of the machine it is running on. nmap Source: http://www.insecure.org/nmap Version: 2.30BETA17 Use: nmap can perform different kinds of port scans, optionally combined with fragmentation and OS detection. During the test the xnmap GUI was used. targa2 Source: http://www.rootshell.com 3/22/99 Version: 2.1 Use: targa2 contains 11 different DoS attacks which can either be run individually or all at once on a range of target addresses. teardrop Source: http://www.rootshell.com 11/14/97 Use: teardrop is an IP fragment overlap attack.

Computers & Security, Vol. 20, No. 2

newtear Source: http://www.rootshell.com 1/9/98 Use: newtear is a more recent version of teardrop which also crashes Windows machines where all service packs and hotfixes are applied that were available at the release time of this attack. jolt2 Source: http://www.rootshell.com 5/31/2000 Use: jolt2 floods the target with ICMP fragments causing a high CPU utilization, in particular cases even an OS crash. synk4 Source: http://www.rootshell.com 6/29/97 Use: synk4 is a SYN flooder. Source addresses can be spoofed randomly. smurf Source: http://www.rootshell.com 10/30/97 Use: A DDoS attack that sends ECHO requests to a list of target machines with a spoofed source address (the target).The target then gets flooded with the ECHO replies. octopus Source: http://www.rootshell.com 9/22/96 Use: Octopus opens as many sockets on a remote host as possible. On many systems, the process table will be saturated. Targets are SunOS, Irix and Linux. cpd Source: http://www.rootshell.com 7/1/2000 Use: Brand new (July 2000) Denial of Service attacks against the Checkpoint FW-1. The exploit sends some 100 spoofed UDP packets to the firewall. Checkpoint FW-1 and its OS crashes when it detects these packets, coming from a different MAC address with the same IP address as the firewall itself. winnuke Source: http://www.rootshell.com 5/26/97 Use: An OOB (out of band) attack.The attack sends OOB data to port 139 ( NetBIOS ) on a Windows

machine.The target reacts unpredictably (e.g. drops network connections). Solaris telnet exploit Source: http://www.rootshell.com 8/17/97 Use: Exploit against Solaris 2.x targets.The exploit attacks the telnet daemon and tries to crash the target remotely by flooding the telnet server with ^D characters. l22dos Source: http://www.rootshell.com: 6/2/99 Use: Exploit against Linux targets with 2.2 kernels. It sends manipulated ICMP packets resulting in a kernel panic. Nessus Source: http://www.nessus.org Use: Nessus is graphic tool that contains various attacks in different categories ranging from DoS to SMTP attacks. Whisker Source: http://www.wiretrip.net/rfp/ Version: 1.3 Use:Whisker is a perl-based CGI vulnerability scanner with special anti-NIDS features. It scans for a large range of vulnerabilities and identifies the web server. boping Source: http://packetstorm.securify.com Use: A very fast network scanner for the Back Orifice Trojan. NetBus Source: http://neworder.box.sk Version: 2.0b pro Use: Latest version of Netbus. A Trojan which allows the attacker complete remote “administration” of the target. SubSeven Source: http://neworder.box.sk Version: 2.0 Use: Latest version of SubSeven. It allows the attacking client to remote control the target, if the corresponding server is started.

137

The Evolution of Intrusion Detection Systems — The Next Step/Richard Barber

Click Source: http://neworder.box.sk Version: 1.4 Use: Click is a Windows based attack tool which floods its target with selectable ICMP error messages.The main purpose of this tool is to flood IRC clients. Divine Intervention Source: http://neworder.box.sk Use:This multipurpose attack tool contains different Windows based attacks under one GUI.The attacks range from an OOB nuker, Flooders (ping and ICQ) to mail bombing tools. IGMP Nuke Source: http://neworder.box.sk Use:This attack tool floods a target with IGMP messages.The user can select the number of packets and the packet size. ICMP bomber Source: http://neworder.box.sk Use:This simple tool floods the target with ICMP messages.The user can define the packet size and the flooding interval. The Network sensors were tested under four different conditions: • • • •

Without load and without fragmented packets. Without load and with fragmented packets. With load and without fragmented packets. With load and with fragmented packets.

For the fragmentation tests the default routes of the attack machines were set to fragsun. We set fragrouter to use ordered 24-byte fragments with preservation of the first header with the following command line options: fragrouter-I qfel -p F2. The load generation was done by Divine Intervention running on target2 (ping flood to target3, 3 threads, packet size 8000 bytes).With these settings a background load of roughly 50Mbit/s was reached.

138

The Unix-based attacks were started from attack1, the Windows based ones from attack2. For each of the four conditions given above the following tests were made: • Linux based scans and port probes. • Linux based attacks including teardrop, targa2 land, bonk, nestae, syndrop, jolt, jolt2, smurf, octopus, cpd,WinNuke etc. • Whisker CGI probes. • Windows NT based Trojan attacks including BOPing, BetBus, SubSeven. • Windows NT based attacks including Click, Divine Intervention, Doom IGMP Nuke, ICMP Bomber. A False Positive test was performed as follows: • HTTP-access from attack1 to target 1 using URL http://target1.ids.net/./index.html. • Mail from attack1 to target1 containing this URL in the body. • URLs containing,,/./” are normally recognized as possible attack. Reporting the email as an attack would be a false positive. The following host based tests were conducted on Windows NT: • Administrator account password guessing. • Try to change a user’s password providing a wrong old password. • Manipulation of important files with the Administrator account. • Local login attempt with user/password guest. • Reboot machine. • Start and stop of an NT service. • Remote registry changes. Host based test in Unix were carried out as follows: • Root password guessing local login. • Try to change a user’s password providing a wrong old password. • Manipulation of important files with the root account. • Copy/etc/passwd as non privileged user.

Computers & Security, Vol. 20, No. 2

• • • •

Root login with telnet. Daemon monitoring. Create user with group root. Replace ps and netstat binaries (stimulate root kit installation). • Reboot system. Given the type of machines being used and the type of attacks and attack tools being used, it is important to look at what the test team were specifically looking for. The technical parameters for evaluating the products fell into a number of areas, the most critical of which are discussed below.

Evaluation Parameters Network IDS Performance The team wanted to ensure that the IDSs’ detection capabilities were not diminished as load increased. Network-based Intrusion Detection Systems (NIDS) can suffer in terms of performance once network load goes over 35%. This problem is partly caused by many of these systems continuing to employ signature analysis when checking packets. There are very few NIDS’ employing signature analysis able to sit on the network checking all packets on that network regardless of whether the network is 4Mbps token ring or Gigabit Ethernet. A clear solution to this problem is moving from signature to protocol analysis. Protocol analysis enables the IP packet to be segmented by layer so that the IDS can check the TCP datagram within the packet and an HTTP string within this, for example. Protocol analysis is able to divide threats according to protocol i.e. FTP-specific threats can be handled by the system. What this also means is that violations of the IP protocol or a member of the protocol suite can be quickly and positively identified, false-positives can be significantly reduced and more sensible thresholds can be set for uncertain traffic. It is important to prevent overload of the network sensor

and subsequent loss of packets (where an undefined number of packets get through simply because the IDS does not have time to check them). It also means that the IDS cannot be fooled simply by slightly modifying the attacks (e.g. using the URL encoded format for CGI-based attacks). All products were checked for maximum packet acceptance, packet drop out threshold and driver limitations. Systems were also checked for ability to handle ‘Out of order delivery’. Hackers often sneak attacks through by deliberately fragmenting and jumbling up packets that carry an attack. Systems need to have a way of reassembling and assessing the threat before it goes on to the IP stack.

Host IDS Performance The performance of Host IDS has been traditionally about log collecting, collating and analyzing log file entries.This is a good practice despite concerns that it is not ‘real-time’ and manufacturers have been sensitive to the requirements to reduce the latency of this approach. Some of the products also needed to address the need to audit across the entire network, including such mundane but important events as user logon events. It is necessary to track for instance, whether BobF is logging on simultaneously from Karachi and from Paris at the same time. There are products that specialize in such things and attempt also to profile users as well, but the standard Host IDS needs to offer more functionality in this area. There is the ongoing problem of collecting, collating and storing logs from disparate sources into one target database and still preserve the relevancy and context of the original data.This problem is not going to be solved any time soon but there is work in various industry and standards committees to come up with an accurate, portable, feature-rich directory language that all directory formats can share. Good work has already been done in this area and while more is needed, the vendors themselves need to absorb some of these innovations.

139

The Evolution of Intrusion Detection Systems — The Next Step/Richard Barber

However, the ability to replicate database content across the enterprise quickly and cleanly and with minimal impact on the network itself, needs to be solved. I would have better understood Scambray & McClure if they had said that the Host IDS is dead but the response would still have been the same. There is a danger of throwing the baby out with the bath water. Systems were examined for the ability to deploy distributed databases and the update mechanisms they employed as well as the efficiency and effectiveness of replication techniques.

Reporting Systems were also checked for logging capabilities. For example it is useful to be able to have a system which prioritizes signatures and groups of agents so that an administrator only receives an alert if the product or signature priority and severity of the agent group exceeds the administrators’ noti-fication levels. It is also useful to determine which alerts are logged to the database and which are dropped. Issues like how multiple attacks, which are actually part of a single attack, are identified and reported at the console are also important. All systems were tested to establish how long it took them to spot these sorts of attacks and then report them as a single attack. The range of styles and techniques for reporting attacks was also explored in the evaluation. Some products offer interactive reporting, i.e. delivering information on current status by intrusion type, intrusion change, host report or agent status. Periodic status reporting capability is also useful for comparing two time intervals and identifying new attacks or hosts that have not been attacked in the first interval. Secure storage of log entries with time stamps and identification of attacks is also very important and will become more so for any electronic forensic work that police forces need to carry out to help them track down criminal hackers.

140

Alerting Appropriate alerting is also a key aspect of an IDS.The system needs to be able to pre-define scenarios where alerts will need to be provided and who will need to be alerted according to the severity of the problem. This sort of escalation management ensures that if corporate systems really are under threat the right person can be emailed or even paged with a message. SNMP support can be useful for this purpose for example.

Pros and Cons BlackICE and BlackICE Sentry by Network ICE + Very good network engine, good handling of IP fragmentation. + Flexible agent software distribution for Windows targets (push/pull). + Because of its protocol oriented approach a new signature is not needed for new variants of a certain attack. + Also possible to detect some new attacks without updating the product. - Management account concept currently too weak for large distributed deployments. - Host agents are limited to network based attacks, no ‘classical’ host functionality (e.g. login trials). - No possibility to create custom network signatures. NetProwler and Intruder Alert by Axent + Custom signatures can be created either by programming with a toolkit or by using a GUI interface (patterns, logical operators, etc.). - No common administration for host based and network based agents. - Performance problems. Centrax by Cybersafe + Strong and flexible approach for host based IDS (based on the auditing system instead of pattern matching in log files). + Flexible signature configuration. + Mature management GUI.

Computers & Security, Vol. 20, No. 2

- The auditing systems have to be configured very carefully in order to avoid high CPU load on the agents and high network load due to reporting data. - Very weak network sensor. - No possibility to create custom network signatures. RealSecure by ISS + Integrated management of network and host based agents. + Very good explanations on attacks. + Support for custom network signatures. - Host and network sensors do not perform well in their respective areas. Dragon by Network Security Wizards + Support for custom signatures (patterns). - Dragon is a powerful and flexible product but the installation and configuration is only suitable for users familiar with Unix. - Very focussed on technical features. - Poor in areas of usability and user-friendliness. - With the standard signature library Dragon did not recognize Windows based attacks. Anzen Flight Jacket by Anzen Computing + Powerful programming language for custom signatures. - Requires very specific hardware without providing a performance benefit over the other products. - The GUI is not mature for large corporate deployments and had performance problems.

Recommendation for Network Based Intrusion Detection From a technical point of view NetworkICE is recommended due to its convincing performance with regard to attack recognition and its ability to handle IP fragmentation. The approach of protocol analysis instead of pattern matching has proven very powerful. NetworkICE’s current weakness, the account concept

and ease of management will be addressed in the upcoming releases.

Recommendation for Host Based Intrusion Detection On the host based part, Centrax by Cybersafe is recommended. Like Network ICE in the network area, Centrax differs in its approach from its competitors. Centrax is built on top of the OS’s auditing system which makes it far less susceptible to log file manipulation and allows it to watch a large variety of events with fine granularity. This is a big advantage over the ‘classic’ approach of performing pattern scans on log files. Also the configuration is very flexible and seems suitable for large deployments. Unfortunately the network sensor did not perform as well as many others.

Conclusion The assessment exercise of the key commercial IDSs in the market clearly underlines the supposition that the market is still not mature. By bringing together the Centrax product from CyberSafe and NetworkICE to create CentraxICE this March, Articon-Integralis is pleased to be able to offer companies the benefits of a best of breed NIDS and HIDS-based solution. It shows that far from being dead the Network IDS is capable of much greater performance than the market has previously experienced and that it needed new skills to achieve this boost. What may not have been so clear in this article is that Network IDS is capable of more than just detection — it can prevent as well. It also heralds a necessary improvement in Host IDS as they make the quantum leap to host auditing across the enterprise. This doesn’t mean that others are not trying to achieve the same goals. It does mean that for the time being CyberSafe has made the clearest step forward in this space. Readers should not think that we are attempting to present the ‘killer’ IDS. Nobody is suggesting that the

141

The Evolution of Intrusion Detection Systems — The Next Step/Richard Barber

Network ICE BlackICE

142

Cybersafe Centrax

Axent NetProwler/ ITA

ISS RealSecure

Anzen Flight Jacket

NSW Dragon

Computers & Security, Vol. 20, No. 2

Network ICE BlackICE

Cybersafe Centrax

Axent NetProwler/ ITA

ISS RealSecure

Anzen Flight Jacket

NSW Dragon

143

The Evolution of Intrusion Detection Systems — The Next Step/Richard Barber

Network ICE BlackICE

144

Cybersafe Centrax

Axent NetProwler/ ITA

ISS RealSecure

Anzen Flight Jacket

NSW Dragon

Computers & Security, Vol. 20, No. 2

Network ICE BlackICE

Cybersafe Centrax

Axent NetProwler/ ITA

ISS RealSecure

Anzen Flight Jacket

NSW Dragon

Performance Matrix

This partnership also opens the door for a further improvement in detection rates and performance by comparing the alerts from a network sensor and comparing this against the host sensor.There are also benefits by comparing alerts in the other direction as well.

The scene is set for the IDS jigsaw puzzle to be re-defined in terms using more comprehensive policy-based systems that perform detection, crosscorrelation, interception and reaction. If the firewall provides corporate perimeter security then there is space for something else that is more akin to a corporate security web or ‘net cast’ over all corporate network devices where an attack on any one device causes a reaction elsewhere.

What about the future of the IDS? It needs to be able to detect and respond accurately to Denial of Service attacks and filter good traffic.This is an interception role best performed at the perimeter of the ISP. It should also be able to detect and prevent application layer attacks that should be performed on or maybe just in front of application servers (not just Web servers).

Richard Barber is Future Technologist with Articon-Integralis, and may be contacted at Articon-Integralis on +44 (0)1189 306060. Further details on the Centrax ICE product and Articon-Integralis is available on the Internet under www.articon-integralis.com.

solution is perfect or that Intrusion Detection Systems are complete as they stand, but it does show that there is a future for Network IDS in the enterprise space.

145