Special Issue: Intrusion Detection (Sept. 1999) Table of Contents
IN THIS ISSUE . . .
CONFERENCE REPORTS
Reports on the
First Conference on Network Administration
Reports on the
Workshop on Intrusion Detection and Network Monitoring
FEATURES
Cisco Flow Logs and Intrusion
Detection at the Ohio State University by Steve Romig, Mark Fullmer, and Suresh Ramachandran
Invisible Intruders:
Rootkits in Practice by David Brumley
Indicators of UNIX
Host Compromise by Paul C. Brutch, Tasneem G. Brutch, and Udo Pooch
A Hacker's Approach
to ID by Mudge A
Glimpse Into the Future of ID by Tim Bass and Dave Gruber
On Reliability
by John Sellens
ANNOUNCEMENTS AND CALLS
3rd Annual Linux Showcase
3rd Large Installation System Administration of Windows
NT / 2000 Conference 9th USENIX Security Symposium
For those who are interested, a more in-depth analysis of these products can be found elsewhere.
ISS RealSecure by Internet Security Systems
is probably the most well known intrusion detection system in the market. Its operation is similar to the Network Security
Monitor mentioned earlier: it is connected to the network and listens to all the traffic passing through, searching
for matches against the patterns it is configured to look for. It can monitor TCP, UDP and ICMP traffic, and in case
a match is found countermeasures can be implemented. The announced bundling of the product with CheckPoint's Firewall-1
should become one of the best-selling security products in the market.
CyberCop by Network Associates is another product that follows the
NSM paradigm. Its operation follows that of ISS RealSecure in the detection level, but its architecture is a more distributed
one. The system is composed of a number of sensors that are scattered among the network nodes and a management server
that collects intrusion reports sent by the sensors. In case an intrusion is detected the management server presents
an elaborate but concise description of the event to the security manager, who can deal with the problem. CyberCop has
the advantage to be backed by one of the largest companies in software business today and especially in the field of
security.
Bro is an IDS developed at the Lawrence Berkley
National Laboratory. Its source code is freely available and the architecture on which it is based is a modular one.
The event engine is separated from the policy script interpreter, which dictates the policy implemented through a proprietary
language. The event engine is designed to be capable of monitoring network connections of more than 100 Mbps, indicating
that performance has been emphasized throughout its design.
NID is another freely available IDS. It is installed
on a dedicated system from where it monitors network traffic. It searches for known attack signatures, as well as deviations
from normal behavior inside the network. In case an intrusion is detected the security manager is notified.
Generally speaking, IDSs are grouped into two families: the first performs mainly auditing functions, carrying out
continuous calls to the hosts linked to the system. The second works independently, observing the traffic on the networks
directly (and passively), carrying out "usual" packet filtering. Some commercial products combine the two methods.
Many IDSs feature automatic network-attack recognition and response-system type. The IDSs are installed and made
to "run" throughout the network or on parts of it where there is a need to preserve critical information.
Monitoring of data traffic generally takes place on the TCP/IP stream passing through Ethernet-based infrastructures.
(Some manufacturers are working on supports for different layouts.) Thus, the IDS combines the functions of a simple
network analyzer with that of recognizing attacks. This is generally achieved by means of a signature check, rather
like programs that detect viruses. The system contains a database of attacks, which functions as a basis of comparison
with the traffic analyzed. When an attack is recognized, the IDS can stop the stream of data immediately, thereby preventing
the attack
Arguments about the Effectiveness of IDSs
To what extent can an IDS influence the performance of a network? How effective can it really be? Management wonders
most about such issues. Two well-known American security experts, Thomas T. Pracek and Timothy N. Newsham, have recently
triggered a discussion about the true effectiveness of IDSs. According to these two experts, these types of device have
many "weak points." However, most of these Achilles' heels reside in the analysis models.
In considering IDSs based on the signature-analysis method, also known as misuse detection, Pracek and Newsham have
raised the objection that often the policies implemented are too stiff and are linked to mere signature matching; that
is, in practice they are based excessively on passive monitoring. Errors made during configuration can lead to a burst
of false alarms, particularly when specific services are used. To this end, the two experts, who state that they are
more in favor of the active-proxy monitoring type of setup, feel that maximum granularity of the IDSs based on this
method is required. As they have pointed out, highlighting the possible leaks in the analysis and operational model
of an IDS does not label these devices as irreparably unsafe -- not at all. Instead, it points to a series of improvements
to make to products in order to make these systems as safe as possible.
Lance Spitzner Last Modified: 23 May,
2000
Firewalls do a good job of keeping the bad guys out. But wouldn't it be nice to know when the bad guys are
knocking on your door? This article covers just that, how to determine when the bad guys are probing your network.
We discuss how you can use the FW-1 User Defined Alert to track when you are being probed, and by whom. If you
would like to see actual intrusion detection results,
click here. NOTE: This script works only
on Unix based systems. Download the latest
version here.
Ports: The IDS script has been ported to run on NT systems. I have not personally tested any of the scripts, you
are on your own. James Oryszczyn
has developed detect.pl,
written in PERL Oscar Wahlberg has developed
fw1_alert.pl, written in PERL Roberson Andrew has written
alert.zip, written mainly in Windows Script
Host 5.1
New Features with ver 1.4.3: Removed TrackDown() function, due to changes in Whois database. Tested and runs on most
Unix flavors, including Linux, Solaris, and Nokia
COAST Audit Trails Format
Group
List of accepted papers
BW: Network ICE Offers First
Intrusion Detection System for Linux(May 08, 2000)
LinuxSecurity.com: Build a Secure
System with LIDS(Apr 25, 2000)
Lids.org: LIDS Hacking HOWTO(Apr
09, 2000) Network Computing: Best
Practices in Network Security(Mar 18, 2000)
LinuxSecurity.com: Intrusion Detection
Primer(Mar 13, 2000) TechWeb:
Linux Suppliers Focus On Improved Security [via Tripwire](Mar 03, 2000)
Security Portal: Some thoughts
on (network) intrusion detection systems(Jan 16, 2000)
Security Portal: Network Intrusion
Detection Systems and Virus Scanners - are they the answer?(Jan 09, 2000)
Security Portal: Do you have an
Intrusion Detection Response Plan?(Aug 24, 1999)
Security Portal: Detecting Intruders
in Linux(Aug 16, 1999)
Slashdot: Intrusion Detection
[Book Review](Jan 27, 2000)
Slashdot: Review: Network
Intrusion Detection: An Analysis Handbook(Sep 28, 1999)
http://www.anticode.com - huge selection, nicely layed out, the
supermarket of exploit sites http://www.rootshell.com - out of date
but nicely searchable index http://www.technotronic.com - exploit
code and other tools such as sniffers and intrusion detection http://www.nmap.org
- Nmap scanner http://www.nessus.org - Nessus intrusion scanner
http://www.marko.net/cheops/ - Cheops
http://www.isag.com - Internet Security Advisors Group (Ira Winkler is
President of said company) http://securityportal.com/research/research.underground.html
- Underground Resources
First, some terminology. There are at least two general types of IDS: host-based and network-based. Host-based systems
are installed on the server or desktop they're designed to protect, and generally monitor logfiles for certain events
and key files for changes. Some host-based systems are hybrids, as they also monitor network traffic sent to the host
where they're installed. Host-based IDSs send alerts to a central console, as do network-based systems.
Network-based IDSs (NIDSs) sniff network traffic using a system called a sensor. The sensor collects all packets
and evaluates both the network headers and the data, looking for signs of misuse. Many sensors focus on attack signatures-that
is, a pattern in the header or data that matches a known attack. Some sensors go beyond mere signature matching, attempting
to match traffic with correct layer-4 and layer-7 protocols.
... ... ...
I recently spoke with an employee of a large Web hosting and Internet services company about NIDS' practical uses.
This employee uses the free NIDS tool snort to monitor the internal
backbone at a large colocation facility. At this facility, snort collects between five thousand and six thousand
alerts each weekday (fewer over weekends), and this is with a trimmed list of attack signatures. With so many potential
incidents, all they do at this site is filter through the alert logs on an hourly basis to determine exactly what is
significant and what, if anything, can be done about it.
Most sites won't have to deal with thousands of alerts each day. But even dealing with several alerts each
day is a full-time job for someone skilled in network and operating system security. The person monitoring the
IDS console must first perform triage-deciding which alert deserves immediate attention, and which can wait. Then this
person must locate the potentially compromised system, determine if the attack has succeeded, and, if so, decide the
next step. Should the system be further analyzed? Saved for evidence? Or just reformatted, with a new, patched operating
system and applications installed? And does this attack hint at more undiscovered vulnerabilities on other systems that
should also be patched immediately?
For those who are interested, a more in-depth analysis of these products can be found elsewhere.
ISS RealSecure by Internet Security Systems
is probably the most well known intrusion detection system in the market. Its operation is similar to the Network Security
Monitor mentioned earlier: it is connected to the network and listens to all the traffic passing through, searching
for matches against the patterns it is configured to look for. It can monitor TCP, UDP and ICMP traffic, and in case
a match is found countermeasures can be implemented. The announced bundling of the product with CheckPoint's Firewall-1
should become one of the best-selling security products in the market.
CyberCop by Network Associates is another product that follows the
NSM paradigm. Its operation follows that of ISS RealSecure in the detection level, but its architecture is a more distributed
one. The system is composed of a number of sensors that are scattered among the network nodes and a management server
that collects intrusion reports sent by the sensors. In case an intrusion is detected the management server presents
an elaborate but concise description of the event to the security manager, who can deal with the problem. CyberCop has
the advantage to be backed by one of the largest companies in software business today and especially in the field of
security.
Bro is an IDS developed at the Lawrence Berkley
National Laboratory. Its source code is freely available and the architecture on which it is based is a modular one.
The event engine is separated from the policy script interpreter, which dictates the policy implemented through a proprietary
language. The event engine is designed to be capable of monitoring network connections of more than 100 Mbps, indicating
that performance has been emphasized throughout its design.
NID is another freely available IDS. It is installed
on a dedicated system from where it monitors network traffic. It searches for known attack signatures, as well as deviations
from normal behavior inside the network. In case an intrusion is detected the security manager is notified.
USENIX ;login - intrusion-detection
systems by Dario Forte
Generally speaking, IDSs are grouped into two families: the first performs mainly auditing functions, carrying out
continuous calls to the hosts linked to the system. The second works independently, observing the traffic on the networks
directly (and passively), carrying out "usual" packet filtering. Some commercial products combine the two methods.
Many IDSs feature automatic network-attack recognition and response-system type. The IDSs are installed and made
to "run" throughout the network or on parts of it where there is a need to preserve critical information.
Monitoring of data traffic generally takes place on the TCP/IP stream passing through Ethernet-based infrastructures.
(Some manufacturers are working on supports for different layouts.) Thus, the IDS combines the functions of a simple
network analyzer with that of recognizing attacks. This is generally achieved by means of a signature check, rather
like programs that detect viruses. The system contains a database of attacks, which functions as a basis of comparison
with the traffic analyzed. When an attack is recognized, the IDS can stop the stream of data immediately, thereby preventing
the attack
Arguments about the Effectiveness of IDSs
To what extent can an IDS influence the performance of a network? How effective can it really be? Management wonders
most about such issues. Two well-known American security experts, Thomas T. Pracek and Timothy N. Newsham, have recently
triggered a discussion about the true effectiveness of IDSs. According to these two experts, these types of device have
many "weak points." However, most of these Achilles' heels reside in the analysis models.
In considering IDSs based on the signature-analysis method, also known as misuse detection, Pracek and Newsham have
raised the objection that often the policies implemented are too stiff and are linked to mere signature matching; that
is, in practice they are based excessively on passive monitoring. Errors made during configuration can lead to a burst
of false alarms, particularly when specific services are used. To this end, the two experts, who state that they are
more in favor of the active-proxy monitoring type of setup, feel that maximum granularity of the IDSs based on this
method is required. As they have pointed out, highlighting the possible leaks in the analysis and operational model
of an IDS does not label these devices as irreparably unsafe -- not at all. Instead, it points to a series of improvements
to make to products in order to make these systems as safe as possible.
Cisco Flow Logs and Intrusion Detection
at the Ohio State University
Intrusion Detection for Check Point FireWall-1
Lance Spitzner
Last Modified: 23 May, 2000
Firewalls do a good job of keeping the bad guys out. But wouldn't it be nice to know when the bad guys are
knocking on your door? This article covers just that, how to determine when the bad guys are probing your network.
We discuss how you can use the FW-1 User Defined Alert to track when you are being probed, and by whom. If you
would like to see actual intrusion detection results,
click here. NOTE: This script works only
on Unix based systems. Download the latest
version here.
Ports:
The IDS script has been ported to run on NT systems. I have not personally tested any of the scripts, you are on your
own.
James Oryszczyn
has developed detect.pl,
written in PERL
Oscar Wahlberg has developed fw1_alert.pl,
written in PERL
Roberson Andrew has written alert.zip, written
mainly in Windows Script Host 5.1
New Features with ver 1.4.3:
Removed TrackDown() function, due to changes in Whois database.
Tested and runs on most Unix flavors, including Linux, Solaris, and Nokia
EBN - Summer Dreams of IDS
By Rik Farrow
08/03/2001 10:16 AM EST
URL:
http://www.itarchitect.com/shared/article/showArticle.jhtml?articleId=8703157
Imagine network security the way it should be. You show up for work in the morning and get a report via e-mail from
your Intrusion Detection System (IDS): Everything is OK. You might feel a little dubious about this, but why should
you? After all, isn't the goal of network security to prevent problems in the first place? resou Today's IDSs don't
come close to reaching that goal. Instead, their main allure is reporting what might be wrong in your network, and most
products focus on producing lots of alerts about incidents so that you don't feel that you wasted your time and money
deploying the system. And while knowing what's happening on your network is a worthwhile goal, it doesn't in itself
do anything to solve the problems manifesting through the medium of the IDS console.
Perhaps I am being a bit unfair. But if you do nothing but listen to vendors rave about their products, you are bound
to be misled and disappointed when the reality of what your shiny new IDS can't do sets in. IDS products are getting
better, but they still have a long way to go.
A Distant Dream?
This article is not about products. Producing a useful review of IDS products is a very difficult task-one that's
illustrated well by a review by Greg Shipley, director of consulting services with Neohapsis
(see Resources). According
to Shipley, the review should be published at roughly the same time as this issue of Network Magazine.
In this column, I'll focus on the technology behind IDSs, as well as an idealized view on some features that would
dramatically increase these products' functionality.
First, some terminology. There are at least two general types of IDS: host-based and network-based. Host-based systems
are installed on the server or desktop they're designed to protect, and generally monitor logfiles for certain events
and key files for changes. Some host-based systems are hybrids, as they also monitor network traffic sent to the host
where they're installed. Host-based IDSs send alerts to a central console, as do network-based systems.
Network-based IDSs (NIDSs) sniff network traffic using a system called a sensor. The sensor collects all packets
and evaluates both the network headers and the data, looking for signs of misuse. Many sensors focus on attack signatures-that
is, a pattern in the header or data that matches a known attack. Some sensors go beyond mere signature matching, attempting
to match traffic with correct layer-4 and layer-7 protocols.
While researching this column, I spoke with Shipley, who disclosed some results of the Neohapsis product review.
Some of the details were striking. For example, many NIDS sensors crashed during the testing under real, not test, network
loads. The fastest sensor caught almost every attack, but it had a user interface that only a Unix sysadmin would adore.
A different product with an even faster sensor had a great user interface, but only a tiny signature database-so it
missed many attacks.
Another issue for existing NIDS is that some of the best-known vendors are only now catching up to some of the tricks
used to evade IDSs. In early 1998, Thomas Ptacek and Timothy Newsham published a paper about bypassing NIDSs using fragmentation
and out-of-order packets. And what was true in 1998 remains true to some degree today. While many NIDS do attempt to
defragment packets sniffed off a network, it's just not as simple as that. (See
Network Defense, July 1999, for more
information on fragmentation issues and NIDS.) And while vendors might claim it's not so easy to fragment attacks, Dug
Song, while an employee of IDS vendor Anzen, wrote fragrouter, a tool that makes fragmenting any network traffic easy.
A related issue has to do with out-of-order packets. Another way of playing hob with NIDS is sending small packets
that contain an attack split among them, so that the attack signature doesn't appear in any one of them, and sending
the first packet last. The NIDS sensor's task is to reassemble the data stream, then analyze it for attacks in what
IDS vendors now call "maintaining state." But adding this detail to an NIDS sensor already operating at its performance
limits often pushes it right over the edge.
A sensor claiming to monitor 100Mbits/sec can often only do this part of the time. In another article (see
Resources), Shipley claims
that this is due in part to packet size. A 100Mbit/sec Ethernet link filled with maximum-size packets can carry, at
most, 8,120 packets per second. But send the smallest possible packets (for example, pure TCP ACK packets), and the
packets-per-second rate goes up to 144,880. Now, to make things really interesting, let's make many of those packet
acknowledgments to ongoing TCP connections that the sensor is supposed to be monitoring in its state table-and you can
really begin to understand why many sensors experience meltdown.
It's one thing to sniff 144,880 packets per second (no mean feat), and another to check them for known attack signatures.
Matching them to existing data streams before checking them, however, is quite another matter. An attacker can, through
a port scanner, quickly set up thousands of connections in the state table, leading to memory overload. According to
Shipley, many products he reviewed had memory leaks-places in the code where memory was used but never freed-that led
to crashes over time.
People Power
IDSs' failings may be legion, but I'm not claiming these products are useless. In fact, a properly working IDS brings
up the next big issue for proper deployment: Who will handle the potential security incident that the IDS reports?
I recently spoke with an employee of a large Web hosting and Internet services company about NIDS' practical uses.
This employee uses the free NIDS tool snort to monitor the internal
backbone at a large colocation facility. At this facility, snort collects between five thousand and six thousand alerts
each weekday (fewer over weekends), and this is with a trimmed list of attack signatures. With so many potential incidents,
all they do at this site is filter through the alert logs on an hourly basis to determine exactly what is significant
and what, if anything, can be done about it.
Most sites won't have to deal with thousands of alerts each day. But even dealing with several alerts each day is
a full-time job for someone skilled in network and operating system security. The person monitoring the IDS console
must first perform triage-deciding which alert deserves immediate attention, and which can wait. Then this person must
locate the potentially compromised system, determine if the attack has succeeded, and, if so, decide the next step.
Should the system be further analyzed? Saved for evidence? Or just reformatted, with a new, patched operating system
and applications installed? And does this attack hint at more undiscovered vulnerabilities on other systems that should
also be patched immediately?
Just installing a single sensor and an NIDS console can easily consume weeks. Proper installation involves not only
the physical process of installing the sensor and the console software, but also configuring the NIDS itself. Almost
all IDS products support some level of customization. Sometimes the IDS will do this "automatically"-you launch a tool,
and the tool scans the network, attempts to identify operating systems, then only watches for attacks specific to those
IP addresses and the operating system associated with a particular address. Of course, you must remember to launch this
configuration process anytime a system is added to your network.
More than likely, you'll need to manually select sets of attack signatures that you're most interested in. For example,
if your organization has nothing but Microsoft systems, you don't want the IDS console annoying you with alerts about
Unix/Linux exploits directed at internal systems. You might want the IDS to alert you to attacks against external Unix
systems coming from your own network, though. And as you use a tool, you'll begin to learn which alerts will most likely
be false positives-something the IDS picks up as an attack, but which actually represent normal network activity at
your site.
The console will also be of critical importance to users. It must be capable of providing a high-level view but still
permit you to drill down to collect more detailed information about a particular alert. There must be a mechanism for
clearing alerts when you're done with them, or annotating the alerts, so you can remember later what you've done about
a specific alert.
Hopefully, the console won't just present you with a terse log-style message, but will provide information about
what the alert means, how serious it might be, how to actually verify if the alert represents a real event and, finally,
how to patch the system involved.
Keeping the Dream Alive?
While some IDSs do hint at what an alert means, and a few even make suggestions about how to check a system and see
if the attack has been successful, that's far from the "dream" IDS envisioned earlier in this column. But let's stay
with that dream for a minute and imagine what a Manhattan Project approach ($2 billion in 1945 dollars) could do to
implement the ideal IDS.
The ideal IDS would be a hybrid, with both host-based and network-based sensors. The host-based module would also
permit operating system software and upgrading on monitored machines, and the ability to adjust file permissions/ownerships,
registry keys/configuration, and operating system tuning parameters-all without rebooting. And this host-based IDS would
consume few CPU cycles, so installing it even on heavily loaded servers wouldn't be a problem.
The NIDS sensors would be installed in switches (two vendors have already achieved this) so that all traffic could
easily be monitored. The sensors wouldn't just be passive network traffic monitors, but would keep track of in-use IP
addresses and use passive fingerprinting to identify operating systems, and active fingerprinting if necessary. If a
new system appeared, the sensor would go into active mode and perform a vulnerability scan of the new system, installing
any operating system or application updates that were previously approved for that platform. The sensor would also inform
the central console of a new system on the network.
The NIDS sensor would keep a history of all network traffic. If a new service suddenly appeared on a system, this
could be an indication of either a successful attack or the installation of a Trojan. The NIDS would not only alert
the console but also might take countermeasures against the possible Trojan-especially if the NIDS sensor detected other
suspicious activity, such as a sudden flood or port scan originating from the suspect system.
While this type of system remains a dream, it's not mine alone. Department of Defense (DoD) research projects such
as Emerald and Sapphire focus on assimilating reports from an array of sensors to provide the big picture, correlation
between reports, and the ability to drill down to get details from individual sensors or hosts. Someday, the dream may
come true.
Rik Farrow is an independent security consultant. His Web site,
www.spirit.com, contains security links and information about network
and computer security courses. He can be reached at [email protected].
Resources
Thomas Ptacek and Timothy Newsham's Intrusion Detection (ID) paper is located at
this link.
Greg Shipley's article about Intrusion Detection Systems (IDSs) from Network Computing is located
here.
Greg Shipley and Neohapsis' review of ID products will appear at
Neohapsis sometime in August 2001.
Dug Song wrote fragrouter, a tool for testing network IDSs, while he worked for Anzen. Go to http://packetstorm.securify.com/UNIX/IDS/fragrouter-1.6.tar.gz
or www.monkey.org to download fragrouter.
The CERIAS page defines IDS terms and provides IDS references. Go to
this link.
A nice summary of different types of IDSs (including vulnerability scanners) can be found
here.
The Evolution of Intrusion Detection Systems
Paul Innella 2001-11-16
The Evolution of Intrusion Detection Systems
by Paul Innella,
Tetrad Digital Integrity, LLC
last updated November 16, 2001
Introduction
I am currently working with a client who asked me to choose an intrusion detection system (IDS) to deploy in their
environment. I have been working with intrusion detection since it was virtually unknown, so it would seem the decision
would be quite simple. On the contrary, with all of the different components and vendors to choose from, IDS offerings
have become pretty complex. That led me to wonder how IDS technology has progressed to its current state. So, I invested
some time trying to figure it out. Now that I have, let me tell you, it is enough to induce a headache. Nonetheless,
I wrote this article to share my findings with you. If you are ready for a discussion about the evolution of IDS, then
read on; however, be forewarned, the history of intrusion detection is as confusing as Greenspan's economic strategies.
IDS Components
Before we get started, let me provide a layman's description of the primary IDS components:
Network Intrusion Detection (NID)
Network intrusion detection deals with information passing on the wire between hosts. Typically referred to as "packet-sniffers,"
network intrusion detection devices intercept packets traveling along various communication mediums and protocols, usually
TCP/IP. Once captured, the packets are analyzed in a number of different ways. Some NID devices will simply compare
the packet to a signature database consisting of known attacks and malicious packet "fingerprints", while others will
look for anomalous packet activity that might indicate malicious behavior. In either case, network intrusion detection
should be regarded primarily as a perimeter defense.
NID has historically been incapable of operating in the following environments:
- Switched networks
- Encrypted networks
- High-speed networks (anything over 100 Mbps)
Recently, however, Cisco released a module for their Catalyst 6000 switch that incorporates network intrusion detection
directly in the switch, overcoming the first of these flaws. Additionally, ISS/Network ICE indicated that they are now
capable of "packet-sniffing" at gigabit speeds.
Host-based Intrusion Detection (HID)
Host-based intrusion detection systems are designed to monitor, detect, and respond to user and system activity and
attacks on a given host. Some more robust tools also offer audit policy management and centralization, supply data forensics,
statistical analysis and evidentiary support, and in certain instances provide some measure of access control. The difference
between host-based and network-based intrusion detection is that NID deals with data transmitted from host to host while
HID is concerned with what occurs on the hosts themselves.
Host-based intrusion detection is best suited to combat internal threats because of its ability to monitor and respond
to specific user actions and file accesses on the host. The majority of computer threats come from within organizations,
from many different sources; disgruntled employees and corporate spies are just two examples. In fact, intrusion detection
expert Richard Power states, "each year, we've asked the respondents [of the CSI/FBI survey] to rate the likely sources
of [a network] attack. Invariably, disgruntled and dishonest employees have topped the list, with over 80% of respondents
citing them as a likely source." (Power, 1999: 32.)
Hybrid Intrusion Detection
Hybrid intrusion detection systems offer management of and alert notification from both network and host-based intrusion
detection devices. Hybrid solutions provide the logical complement to NID and HID - central intrusion detection management.
Network-Node Intrusion Detection (NNID)
Network-node intrusion detection was developed to work around the inherent flaws in traditional NID. Network-node
pulls the packet-intercepting technology off of the wire and puts it on the host. With NNID, the "packet-sniffer" is
positioned in such a way that it captures packets after they reach their final target, the destination host. The packet
is then analyzed just as if it were traveling along the network through a conventional "packet-sniffer." This scheme
came from a HID-centric assumption that each critical host would already be taking advantage of host-based technology.
In this approach, network-node is simply another module that can attach to the HID agent. Network node's major disadvantage
is that it only evaluates packets addressed to the host on which it resides. Traditional network intrusion detection,
on the other hand, can monitor packets on an entire subnet. Even so, "packet-sniffers" are equally incapable of viewing
a complete subnet when the network uses high-speed communications, encryption, or switches since they are essentially
"without a sense of smell" (first and last NID joke, I promise.) The advantage to NNID is its ability to defend specific
hosts against packet-based attacks in these complex environments where conventional NID is ineffective.
Intrusion Detection Systems: A Brief History
The goal of intrusion detection is to monitor network assets to detect anomalous behavior and misuse. This concept
has been around for nearly twenty years but only recently has it seen a dramatic rise in popularity and incorporation
into the overall information security infrastructure. Beginning in 1980, with James Anderson's paper,
Computer Security Threat Monitoring
and Surveillance, the notion of intrusion detection was born. Since then, several pivotal events in IDS technology
have advanced intrusion detection to its current state. Let's focus on how IDS has progressed since its inception.
James Anderson's seminal paper, written for a government organization, introduced the notion that audit trails contained
vital information that could be valuable in tracking misuse and understanding user behavior. With the release of this
paper, the concept of "detecting" misuse and specific user events emerged. His insight into audit data and its importance
led to tremendous improvements in the auditing subsystems of virtually every operating system. Anderson's conjecture
also provided the foundation for future intrusion detection system design and development. His work was the start of
host-based intrusion detection and IDS in general.
In 1983, SRI International, and specifically Dr. Dorothy Denning,
began working on a government project that launched a new effort into intrusion detection development. Their goal was
to analyze audit trails from government mainframe computers and create profiles of users based upon their activities.
One year later, Dr. Denning helped to develop the first model for intrusion detection, the Intrusion Detection Expert
System (IDES), which provided the foundation for the IDS technology development that was soon to follow.
In 1984, SRI also developed a means of tracking and analyzing audit data containing authentication information of
users on ARPANET, the original Internet. Soon after, SRI completed a Navy SPAWAR contract with the realization of the
first functional intrusion detection system, IDES. Using her research and development work at SRI, Dr. Denning published
the decisive work, An Intrusion
Detection Model, which revealed the necessary information for commercial intrusion detection system development.
Her paper is the basis for most of the work in IDS that followed.
Meanwhile, there were other significant advances occurring at University of California Davis'
Lawrence Livermore Laboratories. In 1988, the Haystack project
at Lawrence Livermore Labs released another version of intrusion detection for the US Air Force. This project produced
an IDS that analyzed audit data by comparing it with defined patterns. In a telephone interview with the author, Crosby
Marks, a former Haystack Project team member and Haystack Labs employee said that, "searching through this large amount
of data for one specific misuse was equivalent to looking for a needle in a haystack."
The subsequent iteration of this tool was called the Distributed Intrusion Detection System (DIDS). DIDS augmented
the existing solution by tracking client machines as well as the servers it originally monitored. Finally in 1989, the
developers from the Haystack project formed the commercial company, Haystack Labs, and released the last generation
of the technology, Stalker. Crosby Marks says that "Stalker was a host-based, pattern matching system that included
robust search capabilities to manually and automatically query the audit data." The Haystack advances, coupled with
the work of SRI and Denning, greatly advanced the development of host-based intrusion detection technologies.
To kick off the '90s, UC Davis's Todd Heberlein introduced the idea of network intrusion detection. In 1990, Heberlein
was the primary author and developer of Network Security Monitor (NSM), the first network intrusion detection system
( see Heberlein, L. et al. "A Network Security Monitor." Proceedings of the IEEE Computer Society Symposium, Research
in Security and Privacy, May 1990, pp. 296-303.) NSM was deployed at major government installations where network traffic
analysis provided massive amounts of information. This new awareness generated more interest in the field of intrusion
detection and investments in that market increased significantly. Heberlein's contributions also extended to the DIDS
project where, along with the Haystack team, he introduced the first idea of hybrid intrusion detection. The work of
the Haystack project and the introduction of the Network Security Monitor revolutionized the IDS field and brought it
into the commercial world.
Commercial development of intrusion detection technologies began in the early 1990s. Haystack Labs was the first
commercial vendor of IDS tools, with its Stalker line of host-based products. SAIC was also developing a form of host-based
intrusion detection, called Computer Misuse Detection System (CMDS). Simultaneously, the Air Force's Cryptologic Support
Center developed the Automated Security Measurement System (ASIM) to monitor network traffic on the US Air Force's network.
ASIM made considerable progress in overcoming scalability and portability issues that previously plagued NID products.
Additionally, ASIM was the first solution to incorporate both a hardware and software solution to network intrusion
detection. ASIM is still currently in use and managed by the
Air Force's Computer Emergency Response Team (AFCERT)
at locations all over the world. As often happened, the development group on the ASIM project formed a commercial company
in 1994, the Wheel Group. Their product, NetRanger, was the first commercially viable network intrusion detection device.
Nonetheless, commercial intrusion detection systems developed slowly during these years and only truly blossomed towards
the latter half of the decade.
The intrusion detection market began to gain in popularity and truly generate revenues around 1997. In that year,
the security market leader, ISS, developed a network intrusion detection system called RealSecure. A year later, Cisco
recognized the importance of network intrusion detection and purchased the Wheel Group, attaining a security solution
they could provide to their customers. Similarly, the first visible host-based intrusion detection company, Centrax
Corporation, emerged as a result of a merger of the development staff from Haystack Labs and the departure of the CMDS
team from SAIC. From there, the commercial IDS world expanded its market-base and a roller coaster ride of start-up
companies, mergers, and acquisitions ensued. (The next section, Players, discusses these developments.)
Currently, market statistics show that IDS is amidst the top selling security vendor technologies and should continue
to rise. Furthermore, government initiatives, such as the Federal Intrusion Detection Network, (FIDNet) created under
Presidential Decision Directive 63, are also
adding impetus to the evolution of IDS. Advancements in IDS will ultimately push security technology into a whole new
arena of automated security intelligence.
So what's next? Well, there's application intrusion detection, heuristics and rules-based intrusion detection, incorporation
of artificial intelligence, and who knows what else. (If I did I would be working on that instead of writing this article.)
Regardless of how intrusion detection technology evolves, one thing is for sure - it is now an important and integral
component of information security.
Players
The IDS market appears to grow and shrink with the stock market. In the February 2000 timeframe there seemed to be
a gaggle of IDS vendors, but there are now only a few serious ones remaining. Most have faded away or been gobbled up
by the bigger fish. It is important to note how different intrusion detection vendors' technologies came to be. So,
let's review the current players in the market and discuss how they got here.
Cisco
Cisco currently provides both host-based and network-based intrusion
detection products. They first entered the IDS market in 1997 by acquiring the Wheel Group and their
NetRanger technology for $124
million. Their IDS 4230 and 4210 series provide typical NID solutions while the Catalyst 6000 module is the first switched-integrated
NID offering on the market. On the host-based intrusion detection side, they use Entercept's technology instead of having
developed their own.
Internet Security Systems (ISS)
ISS provides both a proprietary hybrid intrusion detection
solution and an additional NID system that functions independently of their hybrid offering. ISS ventured into NID with
the release of
RealSecure,
virtually at the same time that CISCO purchased NetRanger. Only two years later, they introduced a host-based component
that made their hybrid IDS offering complete. ISS recently made another move towards conquest of the IDS market with
the acquisition of Network ICE and their highly respected NID solutions, including their new gigabit NID system.
Symantec
Symantec recently acquired Axent and thus gained their Intruder Alert and NetProwler technologies, bringing them
into the IDS market. Symantec offers both NID and HID solutions and a method of providing hybrid integration as well.
Enterasys
Like Cisco, Enterasys/Cabletron realized that providing bridges and routers was a viable means of subsequently offering
intrusion detection. Consequently, Enterasys purchased Network Security Wizards and their Dragon NID solution and Squire
HID system.
The Rest
Now, let’s discuss the rest of the IDS field. Okay, ready, take a deep breath, and here we go.
We start with the merger of the CMDS development staff from SAIC who went on to start Centrax Corporation along with
the people from Haystack Labs. Incidentally, the remainder of Haystack was purchased by Trusted Information Systems,
which was then acquired by Network Associates. Centrax Corporation
was purchased by CyberSafe Corporation and changed the host-based product, Entrax, into Centrax. Centrax then became
the first commercially viable host-based intrusion detection product. CyberSafe later introduced NID followed by NNID
technologies into their Centrax product; they even partnered with Network ICE to round out the solution - until ISS
bought Network ICE and ended that relationship.
Meanwhile, CMDS moved to its new home when SAIC sold it to ODS, who renamed it to Kane Security Enterprise and then
spun off Intrusion.com to better market the product. Intrusion.com then purchased MimeStar, and its SecureNet Pro NID
solution, to provide its customers with a total IDS offering.
Okay, you can let it out now - the long and short of this series of spin-offs, acquisitions, mergers, and failures
is that the strong seem to get stronger and the number of IDS competitors continue to decrease.
Conclusion
Summing up, the work of Anderson, Heberlein, and Denning spawned the concept of IDS. Government funding and corporate
interest helped to develop their concept into a tangible technology that eventually found its way into the mainstream
of network security. Intrusion detection has indeed come a long way, becoming a necessary means of monitoring, detecting,
and responding to security threats. From theory to practice, and finally to commercially viable tools, IDS technology
has gone through countless iterations and numerous owners. Nonetheless, the use of intrusion detection as a means of
deterring misuse has ultimately become commonplace. Moreover, IDS has become essential.
References
Allen, J., Christie, A., Fithen, W., McHugh, J., Pickel, J., and Stoner, E., State of the Practice of Intrusion Detection
Technologies. CMU/SEI-99-TR-028, Carnegie Mellon University, Software Engineering Institute, January 2000.
Anderson, James P., Computer Security Threat Monitoring and Surveillance. James P. Anderson Co., Fort Washington,
Pa., 1980.
D. E. Denning, "An intrusion-detection model." IEEE Transactions on Software Engineering, Vol. SE-13(No. 2):222-232,
Feb. 1987.
Heberlein, L. et al. "A Network Security Monitor." Proceedings of the IEEE Computer Society Symposium, Research in
Security and Privacy, May 1990, pp. 296-303.
Marks, Crosby, former Haystack Project team member and Haystack Labs employee, telephone interview, September 3,
2001.
Mchugh, J. et al. "Intrusion Detection: Implementation and Operational Issues," Software Engineering Institute Computer
Emergency Response Team White Paper, January 2001.
Power, Richard, "1999 CSI/FBI Computer Crime and Security Survey," Computer Security Journal, Volume XV, Number 2,
1999, pp. 32.
Proctor, Paul, The Practical Intrusion Detection Handbook, Prentice Hall, 2001.
Sans Institute, "Intrusion Detection and Vulnerability Testing Tools: What Works" Feb 2001.
Shipley, Greg, "Watching the Watchers: Intrusion Detection," Network Computing, November 13, 2000.
Paul Innella, CISSP, is President of
Tetrad Digital Integrity, LLC a Washington, D.C. based information
security services company. Mr. Innella has nearly ten years of experience in the computer industry working at several
commercial and government companies as a security engineer, developer, integrator, systems administrator, program manager,
and sales engineer. Mr. Innella is a member of the Gerson Lehrman Group Council of Advisors, the CISSP Speakers/SME
Bureau, ISSA, and CSI.
SecurityFocus accepts Infocus article submissions from members of the security community. Articles are published
based on outstanding merit and level of technical detail. Full submission guidelines can be found at
http://www.securityfocus.com/static/submissions.html.
Society
Groupthink :
Two Party System
as Polyarchy :
Corruption of Regulators :
Bureaucracies :
Understanding Micromanagers
and Control Freaks : Toxic Managers :
Harvard Mafia :
Diplomatic Communication
: Surviving a Bad Performance
Review : Insufficient Retirement Funds as
Immanent Problem of Neoliberal Regime : PseudoScience :
Who Rules America :
Neoliberalism
: The Iron
Law of Oligarchy :
Libertarian Philosophy
Quotes
War and Peace
: Skeptical
Finance : John
Kenneth Galbraith :Talleyrand :
Oscar Wilde :
Otto Von Bismarck :
Keynes :
George Carlin :
Skeptics :
Propaganda : SE
quotes : Language Design and Programming Quotes :
Random IT-related quotes :
Somerset Maugham :
Marcus Aurelius :
Kurt Vonnegut :
Eric Hoffer :
Winston Churchill :
Napoleon Bonaparte :
Ambrose Bierce :
Bernard Shaw :
Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient
markets hypothesis :
Political Skeptic Bulletin, 2013 :
Unemployment Bulletin, 2010 :
Vol 23, No.10
(October, 2011) An observation about corporate security departments :
Slightly Skeptical Euromaydan Chronicles, June 2014 :
Greenspan legacy bulletin, 2008 :
Vol 25, No.10 (October, 2013) Cryptolocker Trojan
(Win32/Crilock.A) :
Vol 25, No.08 (August, 2013) Cloud providers
as intelligence collection hubs :
Financial Humor Bulletin, 2010 :
Inequality Bulletin, 2009 :
Financial Humor Bulletin, 2008 :
Copyleft Problems
Bulletin, 2004 :
Financial Humor Bulletin, 2011 :
Energy Bulletin, 2010 :
Malware Protection Bulletin, 2010 : Vol 26,
No.1 (January, 2013) Object-Oriented Cult :
Political Skeptic Bulletin, 2011 :
Vol 23, No.11 (November, 2011) Softpanorama classification
of sysadmin horror stories : Vol 25, No.05
(May, 2013) Corporate bullshit as a communication method :
Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000):
the triumph of the US computer engineering :
Donald Knuth : TAoCP
and its Influence of Computer Science : Richard Stallman
: Linus Torvalds :
Larry Wall :
John K. Ousterhout :
CTSS : Multix OS Unix
History : Unix shell history :
VI editor :
History of pipes concept :
Solaris : MS DOS
: Programming Languages History :
PL/1 : Simula 67 :
C :
History of GCC development :
Scripting Languages :
Perl history :
OS History : Mail :
DNS : SSH
: CPU Instruction Sets :
SPARC systems 1987-2006 :
Norton Commander :
Norton Utilities :
Norton Ghost :
Frontpage history :
Malware Defense History :
GNU Screen :
OSS early history
Classic books:
The Peter
Principle : Parkinson
Law : 1984 :
The Mythical Man-Month :
How to Solve It by George Polya :
The Art of Computer Programming :
The Elements of Programming Style :
The Unix Hater’s Handbook :
The Jargon file :
The True Believer :
Programming Pearls :
The Good Soldier Svejk :
The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society :
Ten Commandments
of the IT Slackers Society : Computer Humor Collection
: BSD Logo Story :
The Cuckoo's Egg :
IT Slang : C++ Humor
: ARE YOU A BBS ADDICT? :
The Perl Purity Test :
Object oriented programmers of all nations
: Financial Humor :
Financial Humor Bulletin,
2008 : Financial
Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related
Humor : Programming Language Humor :
Goldman Sachs related humor :
Greenspan humor : C Humor :
Scripting Humor :
Real Programmers Humor :
Web Humor : GPL-related Humor
: OFM Humor :
Politically Incorrect Humor :
IDS Humor :
"Linux Sucks" Humor : Russian
Musical Humor : Best Russian Programmer
Humor : Microsoft plans to buy Catholic Church
: Richard Stallman Related Humor :
Admin Humor : Perl-related
Humor : Linus Torvalds Related
humor : PseudoScience Related Humor :
Networking Humor :
Shell Humor :
Financial Humor Bulletin,
2011 : Financial
Humor Bulletin, 2012 :
Financial Humor Bulletin,
2013 : Java Humor : Software
Engineering Humor : Sun Solaris Related Humor :
Education Humor : IBM
Humor : Assembler-related Humor :
VIM Humor : Computer
Viruses Humor : Bright tomorrow is rescheduled
to a day after tomorrow : Classic Computer
Humor
The Last but not Least Technology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org
was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP)
without any remuneration. This document is an industrial compilation designed and created exclusively
for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong
to respective owners. Quotes are made for educational purposes only
in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
Last modified:
March, 12, 2019
