Background Paper
On
Distributed Intrusion
Detection
Ian P. Duffy
7 June 2002
iduffy@satx.rr.com
1.
– Background – The Three Common Models of Intrusion Detection
Distributed IDS is a term that loosely describes a distributed network of intrusion detection devices, all working in unison to observe network traffic and enhance network security. Intrusion detection, in its current state, provides a great deal of information about the traffic that is traversing a network. Throughout this document, I will describe three paradigms for implementing an IDS architecture on a network: single-system IDS, disparate IDS, and distributed IDS. I will attempt to describe the benefits and drawbacks of each methodology. It is my belief that the distributed IDS model is far more robust than either single-system or disparate IDS implementations.
Distributed IDS provides the “more than one pair of eyes” solution: what one system may miss, another system may see. In addition, distributed IDS provides a way of aggregating information from multiple different types of IDS systems into one consolidated, centralized format that can be reviewed by a security expert. Distributed IDS is a way to take intrusion detection sensor data from multiple sources and correlate, aggregate and analyze that data to provide a security manager with a consolidated summary of interesting network traffic.
Throughout this document, I will describe both the benefits and difficulties associated with distributed IDS and the reasons why I believe that, as networks expand and increase in size, distributed IDS is an inevitable paradigm shift in network monitoring. The goal of this document is to describe how the distributed IDS model provides levels of scalability, interoperability, and fault tolerance that are unmatched under today’s current IDS paradigms--describing how these three tenets can dramatically enhance the overall level of network security.
1.1 - Glossary
Throughout this document, several terms will be used to describe features and components of IDS implementations. The specific usage of the following list of terms is significant to an accurate understanding of the Distributed IDS architecture.
1. Single-System IDS – Single-System IDS is an IDS architecture in which only one IDS system is implemented to monitor network activity. The system may be composed of multiple sensors and/or monitoring stations, but it is comprised of only a single type, brand, and model. This is currently a very common IDS model.
2. Disparate IDS – Disparate IDS is a term to describe a security architecture in which multiple, different IDS systems are monitoring traffic. These systems each have proprietary reporting and logging methods for handling suspicious activity, and the individual logs and reports must be managed and reviewed individually.
3. Distributed IDS – Distributed IDS is a term to describe a security architecture of different IDS system types that all report to a single, centralized system (“Expert System”; see item #7 below), and the reports are correlated, aggregated, and presented in a consolidated alert / log format.
4. Network-based sensors – A network-based IDS is a device that resides on a network segment and monitors traffic that traverses that network segment. The network-based IDS inspects each packet for anomalous (not matching standard patterns) or malicious (as defined by a signature set) traffic and reports any traffic that it deems suspicious.
5. Host-based IDS – A host-based IDS is similar in functionality to a network-based IDS, except that rather than watching traffic on the network, it monitors activity on a single host computer on which it is installed. Some host-based IDS systems actually monitor network traffic for the host and report suspicious traffic, while others monitor logs on the host on which they are installed and report anomalous log entries.
6.
Firewall – A firewall is basically a packet filter. A
firewall’s main purpose is to deny network access to unauthorized traffic, and
allow network access to authorized traffic. A firewall will usually contain a
rule set against which it compares all incoming traffic. From this rule set,
each packet is determined to be authorized or unauthorized, and the packet is
either forwarded into the network, dropped, denied, reset, rate limited, or
redirected. Properly configured, a firewall can enforce network policies,
dramatically improving network security.
7. Expert System – Expert systems are the enablers of the distributed IDS concept. An expert system, as used in this document, is a device that takes input from several different devices (both network and host based, and potentially others), performs some processing on these inputs (i.e. correlation, aggregation, categorization, prioritization, etc.), and then takes some action based on those inputs (i.e. logging to a database, notification, pre-programmed automated responses, etc.).
8. Network Security Manager – this is a generic title for the individual within an organization who is responsible for that organization’s network security. Generally this is the person that configures the network security devices described in this list, and monitors their output.
1.2 - Analysis of
Current IDS Capabilities
Currently, Intrusion Detection devices play a significant role in network security. Many networks currently have some version of an IDS monitoring traffic. These sensors provide the network security manager an invaluable view into what traffic (both malicious and benign) is traversing their network. In addition, these sensors provide valuable network intelligence that can lead to real-time (or near real-time) detection of significant network events, insight into network vulnerabilities and attacker techniques and procedures, prosecution evidence related to intrusion incidents and many other valuable network security benefits. However, current IDS implementations are limited in several ways:
1. Single-System IDS (both signature- and anomaly-based) implementations only look for what they are programmed to look for. Many have a fixed “signature” set, or hard-coded logic as to what to look for. In the case of anomaly-based systems, logic flaws or oversights (these systems are designed by humans, after all) can potentially allow an attacker to slip by unnoticed. Generally, in a Single-System implementation, if one system fails to recognize malicious traffic, then all systems (since they analyze traffic using the same logic) will fail to recognize that malicious traffic.
2. Disparate IDS systems provide more in-depth views into what types of traffic are traversing the network. Chances of detection are increased with Disparate IDS implementations due to the fact that they apply different detection logic to their traffic analysis procedures. However, Disparate IDS implementations contain several different types of IDS systems, none of which will interoperate with others to provide a consolidated view of network activity. Each individual IDS system within the Disparate IDS architecture will create its own summary of network traffic and each summary must be reviewed separately and correlated with all other reports to provide the “total picture” of network activity – this can provide a potentially overwhelming amount of data to the network security administrator.
3. Network-based IDS devices only analyze the traffic that traverses the network segment to which they are directly connected. If there is an alternate route into the network, an encrypted tunnel (not uncommon with https and the newer “web services” that we’re starting to hear so much about) or a way to avoid detection by the network-based IDS, then an attacker can potentially enter and manipulate a network without being detected by the IDS.
4. Host-based IDS software only analyzes events that are occurring on the individual host that they are monitoring. This can be extremely valuable on high-value assets such as servers because they are likely targets for attackers. However, host-based systems can potentially have a negative effect on system performance, and, more importantly, host-based IDS devices only provide a limited view of what is potentially a much larger picture.
5. High-bandwidth networks are very difficult to monitor. Network-based IDS devices can potentially require a great deal of CPU time for each packet that they monitor. As the number of packets per second increases, the CPU and memory of the system can quickly become overwhelmed. For this reason, the monitoring of high-bandwidth networks becomes difficult, requiring either expensive, high-speed computers or specialized hardware.
6. Single-System IDS implementations can potentially create a “single point-of-failure” for intrusion detection. If the implementation is such that there is only one IDS device, and that device is disabled, subverted or brought down for any reason, its network will no longer be monitored. If the implementation is such that multiple devices of a single brand/model/type are in use, and these systems are poor at detecting certain types of attacks, then ALL systems of that brand/model/type that are in use will have the same inherent vulnerability. Therefore, single-system IDS implementations are not fault tolerant.
7. As networks grow and expand, a Single-System IDS implementation becomes impractical. For example, corporations with many regional offices may not be able to be monitored by a single network IDS (or even by several IDS systems of the same brand/model/type). As a network’s bandwidth requirements increase, a single IDS device on the high-speed link becomes impractical for reasons discussed in section 1.2.5. As a company acquires new property, offices, etc., and implements a network at these new (potentially geographically separated) locations, the network becomes increasingly difficult to monitor with a single-system IDS architecture. Where initially the corporation may have been able to meet its needs with one network IDS, growth and expansion can make this impossible. Single-system IDS architectures do not scale well.
8. A Single-System IDS implementation may not make the “bigger picture” readily apparent. Single-System IDS implementations may overlook coordinated attacks, insider attacks, and “low and slow” scans. This is, of course, implementation dependant. As an example, consider the following scenario: An attacker has control of several systems on other networks. The attacker uses these “zombie systems” to craft packets from multiple source hosts destined for the same target. A single-system, network-based IDS solution may see the individual packets from separate hosts as unrelated, when, in fact, they can potentially cause some unanticipated results when received by the target system. With Distributed IDS, if you had a host-based solution in place on the target system, you would (should) still receive an alert notification whereas you might not with a single network-based system.
9. A
Single-System IDS implementation will be good at catching certain types of
attacks and poor at catching other types of attacks. One way around this is to
implement multiple types of IDS systems. But this creates another problem: too
much information. A network security manager would have to review each systems
output individually since current IDS solutions do not interoperate well..
1.3 -
Distributed IDS
An old military catch phrase, “centralized control, decentralized execution”, describes the military’s mode of operation during wartime. This principle means that one central office (the Pentagon) coordinates the activities of the units under its command, while the units are directly responsible for accomplishing the tasks assigned to them by that office. The benefit to this is that if that central office is destroyed, the functional organizational structure remains and can still perform its mission. It also means that if one unit in the chain of command fails to accomplish its mission, other units can take its place. This is a good metaphor for describing Distributed IDS; one central expert system, or a hierarchical network of expert systems, receive and process data from IDS devices and pass that data along to the network security manager(s). In the past section, I discussed some of the shortcomings of current IDS capabilities. Distributed IDS addresses these shortcomings in several ways.
1. Since Distributed IDS implementations can contain many different types of IDS systems, then the “more than one pair of eyes” analogy applies. It is therefore more powerful than the Single-System IDS implementation. The more (logically unique) systems you have monitoring network traffic, the less likely it is that an attack will go unnoticed. Distributed IDS provides a centralized means for managing data from these different systems, which in turn provides the network security manager a consolidated, highly accurate view of significant network activity.
2. Disparate IDS implementations involve multiple IDS systems that do not interoperate well. The main drawback to a Disparate IDS implementation is that the network security manager must manually correlate data from each system (or manually implement systems to kludge the two systems together to make them work as desired) to determine what traffic is significant. Since Distributed IDS provides a centralized processing, analysis, and reporting capability in its “Expert System”, it greatly reduces the amount of manual analysis that must be done in comparison to Disparate IDS implementations.
3.
If a network based IDS can only see what traverses the
network segment that it is monitoring, then a collection of network-based IDS
devices, monitoring several network segments, all reporting to one central
expert system, provides a far more comprehensive intrusion detection model than
a single IDS solution, since several network segments can be monitored.
4. Host-based IDS software or devices, in a distributed IDS model, can be configured to report to the same expert system as the network-based IDS devices. This vastly improves insight into network activity, since traffic that is flagged as important by a network-based IDS can be correlated with what is reported by host-based IDS(s). This means that a network security manager can determine if an attack was successful based on correlated reports from both network-based IDS(s) and host-based IDS(s). This provides a much greater level of network intelligence than (naďve?) reliance on a single system.
5. Due to the fact that distributed IDS devices can be delegated to lower levels in the network architecture, it is no longer necessary for network-based IDS devices to be placed on the main network trunk, which is usually the highest-bandwidth link on the network. Rather, several network-based IDS devices can be placed at lower levels of the network on links that may be lower bandwidth. Through event correlation at the expert system, these several devices can provide a more comprehensive picture of network activity than a single network IDS on the trunk (Please note that externally-located, trunk-based IDS systems are still important for several reasons). Also, the IDS devices will not require specialized or expensive hardware since their processing requirements on lower-bandwidth segments will be much less than a single device placed on a higher-bandwidth network trunk.
6. In a distributed IDS architecture, there is no one single point of failure. If one IDS device fails in a distributed IDS architecture, it will have a much less significant impact on network security than device failure where only one IDS were in place. This is called “not putting all of your eggs in one basket” – risk mitigation through distribution of assets. It is this distribution of network security assets that makes distributed IDS much more fault tolerant than a single IDS implementation.
7. Distributed IDS architectures are inherently scalable. As networks grow and expand, IDS devices can be added as needed and plugged in to the distributed IDS architecture. Distributed IDS hierarchies can be created, and network security responsibilities can be delegated to security managers at appropriate levels. A network’s IDS infrastructure can grow and expand at equal pace with the expansion of the network.
8. Distributed IDS architectures are “smarter” than single IDS architectures. Through the use of a centralized expert system and event correlation, a security manager will be able to see much more than with a Single-System IDS implementation. For example, in a single IDS implementation, if an attacker probes multiple sites, the relationship between those probes may not be apparent to the security manager in a Single-System IDS implementation. However if those same sites are reporting to a central expert system, the probes can be correlated and given a higher level of significance than if they were unrelated. This helps to find the “needle in the haystack” and present significant events in an aggregated format to the network security manager in a timely manner.
2. - The Importance of
Standards – Standardized data representations are a prerequisite to Distributed
IDS
Standardization of several aspects of the Distributed IDS architecture is an important first-step towards enabling implementation of distributed IDS. First, there must be a standardized method for describing intrusion detection events such that all applications can interpret and process these events. Second, there must be a standardized method of communicating this data between supporting systems, so that all supporting systems can communicate and interoperate. Third, there should be well-documented information describing these standards and how to implement them in a Distributed IDS architecture so that the standards can be easily implemented by network security professionals. Standardization of these procedures should be openly presented to the network security community, so that they can be reviewed, discussed, and adapted to meet the needs of as many network security implementations as possible.
One promising “step-in-the-right-direction” to a method for standardizing the representation of intrusion detection data is the Internet Engineering Task Force (IETF) Intrusion Detection Working Group’s (IDWG) proposed standards of the Intrusion Detection Message Exchange Format (IDMEF)[1], Incident Object Description and Exchange Format (IODEF)[2], and the Intrusion Detection Exchange Protocol (IDXP/BEEP)[3]. IDMEF is a proposed schema for an XML-based representation of IDS event data (from both network and host based systems). IODEF is a proposed XML schema for representation of network incidents. IDXP is a proposed protocol that details a secure, end-to-end communications model for transmitting intrusion data (IDMEF and IODEF) from analyzers (IDS devices) to managers (Expert Systems, databases, management applications, etc.) Since many applications are XML enabled, and support for XML is growing every day, this standard seems to be a powerful, easily adapted method for sharing IDS data. Also, since XML is operating system and programming language independent, all devices and programs can easily be extended to support these standards. Another benefit to these standards is that the IETF IDWG has sought to provide a way for handling proprietary data. Therefore it becomes more useful in that it can be adapted and implemented by IDS vendors whose products provide data beyond what is considered “standard” IDS data.
It is impossible to overstress the importance of open, well-defined and well-documented standards for distributed IDS. These standards are essential to ensure the success of the Distributed IDS concept. As the standards are developed further, they will be adopted (and demanded) by many vendors, which will enable the interoperability that is so crucial in a Distributed IDS implementation. Standards are the foundation of interoperability, and interoperability is crucial in order for Distributed IDS devices to work together. Without standards, distributed IDS is nothing more than just a concept on paper.
3.
- Information Management – The drawbacks of Disparate IDS and the problems
caused by non-interoperable IDS implementations
These days, there are many IDS products available that claim they will make a network more secure. Each one will provide a different capability to a network security manager. Each one will provide a different level of insight into the activity that is taking place on a network. Not one will interoperate with an other.
Were a network configured with several of the commercially available intrusion detection systems that are available today, then piles of data would be available to the network security manager. Some sensors would not report on certain attacks while others would (known as false negatives). Some sensors would report on attacks when none had really occurred (known as false positives). A network security manager would have mountains of data to sift through, correlate, and from which draw some sort of conclusion regarding the state of their network’s security. By the time they were done, who knows what kind of damage an intruder may have done? This is a job that surely no one would want!
In comes the expert system – a highly optimized, semi-intelligent, completely configurable bit of software that accepts IDS input data (in a standardized format), melds that data into a consolidated, standardized picture of significant (and not-so-significant but still relevant) network activity. IDS sensors of different types that adhere to standardized protocols can send their data to these expert systems. Lower-level expert systems can be arranged in hierarchies to send their data to higher-level expert systems based on certain criteria. Security management consoles can connect to these expert systems and provide network security managers with real-time, accurate, detailed pictures of significant network activity. Managers at all levels can drill up, down or across for greater insight into their network security at different levels. Network security managers at different sites can collaborate with other network security managers in real-time.
Information overload can rapidly become a significant problem in a network security infrastructure; Disparate IDS implementations do nothing to solve this problem. In the past, more information has generally been considered a good thing. It still is, as long as it is manageable. Expert systems can help to remedy the problem of information overload. Expert systems are an extension of current intrusion detection systems. They are a way for intrusion detection systems to work together, to consolidate their input, and to provide an intelligent view into what is going on within a network. Data from sensors external to a network can be correlated with internal sensor data to determine if the network firewall is effective at blocking malicious traffic. Data from multiple sensors can be correlated to determine if distributed attacks are occurring. Attack data can be aggregated so that a network security manager won’t have to dig through mounds of data to review a single attack. Expert systems, through the use of configurable logic, can greatly reduce the amount of data that a network security manager will have to process. They can dramatically improve the network security manager’s decision and response time, which can lead to improved network security. The expert system is the brain of the distributed IDS architecture, allowing a network’s intrusion detection infrastructure to scale indefinitely, giving the network security manager complete control over what gets reported and to whom it gets reported.
3.1 - Intrusion Detection Hierarchies
Hierarchical architecture is an enormous benefit to Distributed IDS. It allows delegation of responsibility within the network security architecture, which can be extremely beneficial in very large networks. Consider as an example a large corporation that has several offices in San Francisco, several offices in Chicago, several offices in New York, and several offices in London. One expert system and network security manager can be assigned to each city, to collect, correlate, and aggregate data from IDS devices at each of the several offices in each city. In addition, one “master” expert system and a corporate network security manager can be assigned to monitor the data forwarded by the expert systems in each city, creating another level of network security management (the “big-picture” view). Network security managers at this higher level have the ability to drill down – connect to any of the expert systems at any of the cities and get an accurate view into what is going on at any of these sites. They can also easily collaborate with network security mangers at each of these sites to discuss relevant network activity. Intrusion detection hierarchies might look like the following diagram:
Diagram 1: Distributed IDS Example Expert System
Hierarchy
In the diagram, the reporting hierarchy of this distributed IDS model is evident. One or more network security managers in one city can be responsible for monitoring the IDS data from each office in that city. One or more network security managers can be at corporate headquarters monitoring the status of the corporate network at any level of detail that they choose. If permitted to do so, site network security managers at any given city can connect to the corporate expert system and review corporate network security data. Offices can run multiple IDS systems (as long as they subscribe to a specified standard) that report to the expert system for the city that they are in. This is just one example (a standard tree structure) of a hierarchy that could be created. Mesh structures and other hierarchies can easily be implemented to meet the needs of the organization. Another model for implementation of distributed IDS hierarchies is to segregate monitoring duties for a subnetted network, with sensors on each subnet reporting to a central expert system somewhere on that network. The configurability of the expert system will allow a monitoring and reporting hierarchy to be created for any given structure that a network security manager chooses. The level of configurability of the expert system determines its utility and capability.
Now consider another example – a corporation already has a distributed IDS architecture in place, and that corporation purchases another corporation, bringing several new sites into the network security manager’s purview. At each of these sites, sensors and expert systems can be installed and rapidly “plugged in” to the existing distributed IDS hierarchy. If the sites already have IDS systems in place that comply with the required standards, then they can simply be “pointed at” the expert systems that are already in place. The expert systems at each new site can be configured with similar reporting policies as defined by the corporate network security manager in order to rapidly make these new sites compliant with corporate network security policy.
The ability to create hierarchies is one of the major benefits of distributed IDS. Networks will grow with time; users will always want more capability, and networks must grow and expand to accommodate these users. At a certain point, monitoring of this ever-growing network will become extremely difficult, if not impossible. However, with distributed intrusion detection, as a network expands, the responsibility of monitoring the network can be delegated to a network security manager at a lower level. As the network expands to different sites, new IDS devices and expert systems can be “plugged in” to the distributed IDS architecture. A distributed IDS architecture is, therefore, inherently scalable. Citing our previous example, the network security manager in London can assume responsibility for certain network monitoring tasks, freeing the corporate network security manager to deal with more pressing issues (incident management, multi-site attacks, etc.). The corporate network security manager can be called upon by the regional network security managers to assist in investigation and resolution of suspicious network events. In this sense, distributed IDS provides a layer of “filtering”, so that the lower level problems (false positives, minor incident resolution, device configuration errors, etc.) can be resolved at the lower level, while more significant events can percolate to the top. This delegation mirrors the military “centralized control, decentralized execution” paradigm, where one entity is responsible for the operation of the entire enterprise, while another independent entity is responsible for the individual operations (in this case, network security) of their specific organization, ensuring that their organization supports the mission set forth by the controlling entity.
3.2 -
Event Reporting
One interesting question that distributed IDS hierarchies pose is the question of “who sees what”? What level of filtering should be done? What events are percolated to the top, and which are filtered out and dealt with at the lower levels? Configurations on expert systems should allow alteration to accommodate the needs of network security managers. The expert systems should be completely configurable so that a network security manager can easily configure them to forward certain events up the hierarchy, and simply process (and not forward) others. Such configurability will allow the network security managers to tailor specific policies for security management and implement those policies in a distributed IDS environment that meets their unique requirements. For example, let’s say that our corporate network security manager says “I want to see all alerts that involve buffer overflow attacks where there was more than X amount of data transmitted between the attacker and the target. I don’t want to see any scanning activity.” In this case, the expert system at each region can be given a ruleset stating that all events that it processes as “scans” can be processed and dealt with locally, while any event that it processes as a buffer overflow, that meets the data transfer size limits, should be forwarded up to the next level in the distributed IDS hierarchy. This, in a sense, is just one big filtering system – removing the less significant items so that a higher-level network security manager can spend time reviewing significant events for the entire enterprise, while lower-level network security managers can deal with the less-significant activity and work with higher-level network security managers to resolve any issues. With completely configurable logic, expert systems’ filtering capabilities can reduce the workload on network security managers, thus contributing to the overall productivity, performance, and scalability of distributed IDS implementations. This, in turn, improves network security.
4. - Sensor Interoperability, the “Sensor Fusion” Concept, and How Distributed IDS Supports Them Both
Sensor fusion is a term used by the Air Force regarding its network intrusion detection infrastructure. Their goal is (was) to have several intrusion detection devices working together to provide one common picture into network security. Distributed IDS contributes to the Sensor Fusion concept by promoting standardization and enabling collection, aggregation and correlation of event data from several different IDS devices. Key to Sensor Fusion (and distributed IDS) is the concept of interoperability between different types of IDS devices. When data from multiple IDS devices can be centrally managed and interpreted, a greater level of insight into network activity can be achieved. This is “Sensor Fusion”, and it will not be achieved unless there is a certain level of interoperability between different types of intrusion detection devices.
One goal of sensor fusion was to evaluate effectiveness of firewalls. By placing intrusion detection devices on internal and external interfaces of network firewalls and collecting and aggregating (“fusing”) data from those devices, it was hoped that network security managers could determine whether their firewall was configured properly and was effective at preventing attackers from accessing sensitive networks. This is one major benefit of Distributed IDS – the more sensors that exist on a network, the more of this type of feedback there will be. Expert systems can be configured to differentiate between external and internal sensors and only alert on events that are flagged by either both sensors together, or only the internal sensors. As an example, consider an attacker who is targeting an internal DNS server, and the network security manager happens to have host-based IDS software running on that DNS server. The host-based IDS software on the DNS server should generate an alert when the attacker attempts to access that server. Network-based IDS devices may or may not see this attack – there are several emerging methods to circumvent network-based intrusion detection devices[4]. Regardless, the host-based IDS should alert on the malicious activity and the network security manager will receive an alert on it regardless of whether or not the network-based IDS reports on it. After they receive the alert, appropriate action can be taken. By having IDS devices on both sides of the firewall, the network security manager can determine which attacks are significant and which are less significant due to the fact that they are blocked by the firewall. This can help alleviate the “information overload” problem that was discussed earlier.
In another scenario, a network security manager has only one network-based IDS device, external to their firewall, on the trunk that connects their network to the internet. This network-based IDS device constantly alerts on traffic that is blocked by the firewall. The network security manager must sort through the false alarms and search for the legitimate attacks, possibly having to correlate IDS alerts with firewall rules in order to determine if the malicious traffic actually reached its target (and would thus require further investigation). Distributed IDS solves this problem by correlating and aggregating attack data from both internal and external IDS sensors and presenting this summarized data to the network security manager.
It is important to note that in order for “sensor fusion” to become a reality, there must be a standardized method for representing IDS events and communicating these events to the expert systems. As stated before, I believe that the proposed standards of IDMEF and IDXP are excellent candidates for this standard. These standards provide for the interoperability of the sensors in the distributed IDS model, which is absolutely critical for Distributed IDS to be successful. Current IDS implementations do not interoperate, which causes all of the problems of Single-System or Disparate IDS implementations.
5. – Distributed IDS Fault
Tolerance – How Distributed IDS Compensates for Weaknesses in Implementations
Distributed IDS is an improvement on both Single-System IDS and Disparate IDS because it provides a level of fault tolerance that is not present in either other model. To illustrate this point, consider the previous example where a network has both network-based and host-based IDS devices configured in a Distributed IDS model, and an attacker is attempting to access a DNS server. In this scenario, however, the network based IDS device has experienced a disk failure and is therefore no longer able to detect attacks. However, due to the fact that the host-based IDS is still functional, there will still be an alert generated as the attacker attempts to access the DNS server. There is layered security in a Distributed IDS model, and this layered security provides the fault tolerance that is missing in other IDS models. If one system fails in a distributed IDS model, it does not drastically effect the level of security enterprise-wide, since other systems will (should) be in place to continue monitoring against attacks. In contrast, in a Single-System IDS implementation, if a sensor is disabled for any reason, it can have significant security implications for a network. For example, consider an enterprise that has network-based IDS devices deployed at each of its offices. If one of those sensors should fail, then the entire office that is monitored by that sensor becomes vulnerable. A well-timed attack could potentially allow access to the entire enterprise through the network(s) of that office.
6. – Conclusion
Functional Distributed IDS systems are still a few years off, but their successful creation and implementation are attainable goals. Systems are emerging today that are designed for interoperability, using the standards that were mentioned in this document. These systems will directly contribute to the birth and evolution of Distributed IDS. This goal of moving towards interoperable systems is a crucial first step in what will become a significant improvement in intrusion detection capability. And all of this effort will contribute to a synergistic collection of capability, that, when applied to intrusion detection on computer networks, will be markedly better than today’s Single-System and Disparate intrusion detection models.