State of the Practice of Intrusion Detection Technologies
1 Intrusion Detection ¾ What Is It and Why Is It Needed?1.1 The Seriousness of Cyber Attacks
Attacks on the nation's computer infrastructures are becoming an increasingly serious problem. Even though the problem is ubiquitous, government agencies are particularly appealing targets and they tend to be more willing to reveal such events than commercial organizations. This is demonstrated by the cases cited below. While statistics on the growth of attacks provide a more solid basis for justifying the need for intrusion detection (ID), case histories can often be more persuasive.
October 7, 1999: Hackers apparently working from Russia have systematically broken into Defense Department computers for more than a year and took vast amounts of unclassified but nonetheless sensitive information, U.S. officials said Wednesday. Besides penetrating the Pentagon's defenses, the hackers have raided unclassified computer networks at Energy Department nuclear weapons and research labs, at the National Aeronautics and Space Administration and at many university research facilities and defense contractors, officials said. [N9]
October 7, 1999: At NASA, the attacks are "massive, really very massive," and "very, very surreptitious," NASA Inspector General Roberta Gross said in an interview. "It's difficult to tell what the damage is," Gross said. "They weren't shutting down systems. They were taking file listings, looking to see what's in people's directories." Gross said the intruders also installed "parking tools that they can use to get back in later." Such electronic "trap doors" may be used to evade detection devices and to secretly regain access. [N9]
June 1, 1999: After NATO jets hit the Chinese Embassy in Belgrade in May, hackers from China attacked a handful of U.S. government sites, including one maintained by the Energy Department. In an unrelated incident, the official White House site was shut down briefly because of an attempt to tamper with it by unidentified hackers, officials said. [N1]
May 21, 1999: "We successfully penetrated several mission-critical systems, including one responsible for calculating detailed positioning data for Earth-orbiting spacecraft and another that processes and distributes the scientific data received from these spacecraft," the General Accounting Office (GAO) said...Having gained access to these systems, the report said, "We could have disrupted NASA's ongoing command and control operations and stolen, modified, or destroyed system software and data." [N3]
May 11, 1999: The White House Web site was shut down today to determine whether hackers who tried to tamper with the site managed to do so. White House spokesman Barry Toiv said the site was shut down for 24 hours beginning late yesterday...MSNBC reported that there have been a series of politically motivated raids on government sites, undertaken in protest of last week's NATO bombing of the Chinese embassy in Belgrade, Yugoslavia. Unnamed government sources said the departments of Energy, Interior, and Labor as well as the U.S. Information Agency recently have been hit. [N4]
April 6, 1999: The nation's three nuclear weapons labs have shut down their classified computer systems for at least a week to beef up network security. Three preeminent Energy Department facilities halted operations Friday on all computers that handle secret information, in response to an unfavorable information security rating in a DOE audit of last year, according to Los Alamos National Laboratory spokesman Jim Danneskiold. The other two labs affected by the shutdown are Lawrence Livermore National Laboratory and Sandia National Laboratories...All three facilities will undertake several initiatives to improve security, including conducting computer security and threat awareness training; devising stricter access policies and tougher enforcement; implementing more rigorous procedures for transferring information from classified to unclassified computers; and establishing new intrusion detection measures. [N5]
March 31, 1999: NATO spokesman Jamie Shea said service on NATO's home page had been "erratic to say the least" since March 28, the fifth day of the alliance's bombing campaign against Yugoslavia. "It seems that we have been dealing with some hackers in Belgrade, who have hacked into our Web site," Shea told a news conference at NATO headquarters in Brussels. "At the same time, our email system has also been saturated by one individual who is currently sending us 2,000 emails a day. We are dealing with macro viruses from Yugoslavia in our email system," he said. A senior NATO diplomat said it was clear how well-organized and prepared Belgrade's offensive was: "It ranges all the way from organized ethnic cleansing to messing up our Web site." [N6]
March 5, 1999: The Pentagon today confirmed that attacks against U.S. military computers over the past few months are under special investigation by law enforcement and intelligence authorities. Deputy Defense secretary John Hamre briefed the House Armed Services Committee on the matter in a classified meeting February 23, according to the House Armed Services Committee. He warned legislators that the attackers were not merely individual hackers, and said part of the problem may stem from the cooperation of insiders within the U.S. military staff.... Hamre told the committee that the Pentagon detects between 80 and 100 hacker "events" every day. The Pentagon must investigate approximately one in ten of these.... One security expert said that while attacks from Russian and other foreign nations was nothing new, the new breed of hacks posed grave threats in their sophistication. "There is a steadily increasing number of these attacks," said Alan Paller, director of research for The SANS Institute. "And there are more of these that have three characteristics that set them apart." The first of these is that attacks are coming simultaneously from multiple, coordinated sites. The second is that the attacks are coming with more stealth, escaping the detection of intrusion monitoring systems by limiting the number of "pings," or connections. "These are coming in just under the detection threshold, at one every hour, or every three days," said Paller. "They're coming from patient people, who are usually more professional than children." [N7]
September, 1998: Hackers are banding together across the globe to mount low-visibility attacks in an effort to sneak under the radar of security specialists and intrusion detection software, a U.S. Navy network security team said today. Coordinated attacks from up to 15 different locations on several continents have been detected, and Navy experts believe that the attackers garner information by probing Navy Web sites and then share it among themselves. "These new patterns are really hard to decipher¾you need expert forensics to get the smoking gun," said Stephen Northcutt, head of the Shadow intrusion detection team at the Naval Surface Warfare Center. "To know what's really happening will require law enforcement to get hold of the hackers' code so we can disassemble it." [N8]
1.2 The Rapidly Growing ThreatThe press releases in Section 1.1 reflect the serious and sophisticated nature of recent cyber-attacks. This is compounded by the fact that, over the past 12 years, the growth of incidents on the Internet has reflected the growth of the Internet itself. Figure 1-1 illustrates this growth by plotting the number of incidents reported to CERT/CC over those years. E-commerce can only exacerbate the upward trend in incidents. While in previous years, external attacks tended to originate from those interested in exploring the Internet for its own sake and testing their skills, there is an increasing trend towards intrusions motivated by financial, political, and military objectives. From a recent survey of 91 respondents [S33-1], there was an average loss of $256,044 per respondent's organization. While the survey indicated that internal breaches were still of greater concern, external attacks were increasing at an "alarming rate." The survey stated that "...the number of companies experiencing [penetration attacks] doubled from about 12 percent of all respondents in 1998 to 23 percent this year." Thus the stakes are being raised.
In the 1980s, intruders were the system experts (Figure 1-2). They had a high level of expertise and personally constructed methods for breaking into systems. Use of automated tools and exploit scripts was the exception rather than the rule. Today, absolutely anyone can attack a network¾due to the widespread and easy availability of intrusion tools and exploit scripts that duplicate known methods of attack.
|
Figure 1-1: Growth in number of incidents handled by the CERT/CC Figures in this file are displayed in a separate browser window. This window will remain open to display figures in this file, although it might be hidden behind other browser windows. |
|
Figure 1-2: Attack Sophistication vs. Intruder Technical Knowledge Figures in this file are displayed in a separate browser window. This window will remain open to display figures in this file, although it might be hidden behind other browser windows. |
While experienced intruders are getting smarter, as demonstrated by the increased sophistication in the types of attacks, the knowledge required on the part of novice intruders to copy and launch known methods of attack is decreasing.
In the early/mid 1980s, intruders manually entering commands on their personal computer could access tens to hundreds of systems; today, intruders use automated tools to access thousands to tens of thousands of systems.1 In the 1980s, it was relatively straightforward to determine if an intruder had broken into your systems and to determine their actions. Today, intrusions, and the damage they cause, can occur in a matter of seconds. Intruders are able to totally hide their presence by, for example, disabling commonly used services and reinstalling their own versions, and by erasing their tracks in audit and log files. In the 1980s and early 1990s, denial-of-service attacks were infrequent and not considered serious. Today, for organizations that conduct business electronically, such as online stock brokers and traders, a successful denial of service attack can put them out of business. As shown in Figure 1-1, from 1997 to 1998, we saw a 75 percent increase in the number of incidents reported to the CERT/CC. In 1999, the number of incidents increased by over 120 percent from 1998.
There are many reasons for the growing number and severity of attacks, including increased connectivity and complexity, increased availability of vulnerability information and attack scripts via the Internet, and dependence on distributed network services. As indicated by Donn Parker, the very nature of computer crime is that it is unpredictable, so you can't use previous threats or attacks as a metric to prepare for future threats or attacks¾the basis for all of today's signature-based ID products [B91].
1.3 Attacker and Victim Perspectives on IntrusionAttacks and intrusions can be viewed from a number of perspectives. The most common are those of the intruder and the victim. Each perspective brings with it distinct criteria for judging the success of the attack. Typically, we say that an intrusion has taken place when an attack is considered successful from the victim's perspective, i.e., the victim has experienced some loss or consequence. A successful attack is enabled by the presence of a vulnerability in the victim's system that is exploited by an intruder with an objective. We use the term intrusion to mean a successful attack.
An attack is unsuccessful from the perspective of the intruder if none of their objectives are fulfilled; whereas, a victim perceives an attack as unsuccessful if there are no consequences that result from the attack. Unsuccessful attacks from the perspective of an intruder may still have one or more consequences for a victim.
The intrusion process begins when an intruder takes steps to fulfill an objective. An essential component of an intrusion is taking advantage of one more vulnerabilities by using tools and exploit scripts.
The vulnerabilities exploited in this process can range from a flaw in a piece of software, such as a buffer overflow that can be exploited to elevate privileges, to a flaw in an organizational structure that allows a social engineering attack to obtain sensitive information or passwords to accounts. The intrusion process ends when some or all objectives of the intruder are realized or the intruder gives up.
Attacks can involve one or more attackers and one or more victims. Because multiple perspectives are involved in a single attack, defining what constitutes an attack is difficult. Is an attack an action taken by an adversary or is it the manifestation of that action as observed by the victim? Consider the example of the smurf attack [B92] where the attacker convinces a third party to perform an undesirable action against the intended victim. Is the attack the attacker pressing the enter key on the shell command to execute smurf? Is the attack the series of packets sent to the third party? Or is the series of packets observed at the victim site the attack? Or do all of these events fit together to define an attack?
Some example components of an attack from the perspective of an intruder are
Components of an attack fall into either a known or an unknown category. Because attacks contain multiple components, it is possible that a single intrusion contains both. The concept of known and unknown varies from differ-ent perspectives of intrusion as well. An intruder does not necessarily know the consequences of an intrusion for a victim site or all of the hosts that were affected by an intrusion. Similarly, a victim does not necessarily know the objective of an intruder, the exploit scripts that are used, the vulnerabilities that are exploited, or the identity of the intruder.
Some example components of an attack from the perspective of a victim are
The goal of intrusion detection is to positively identify all true attacks and negatively identify all non-attacks. The motivation for using intrusion detection technology may vary for different sites. Some may be interested in law enforcement including the tracking, tracing, and prosecution of intruders. Some may use intrusion detection as a mechanism for protecting computing resources, while others may be more interested in identifying and correcting vulnerabilities.
Just as attacks can be viewed in different ways, so can the process of detecting them. Intrusion detection can result from the observation of an attack in progress or from recognizing the results of an intrusion after the fact. This section summarizes several characteristics of intrusion detection.
As the terms are used below, there is a discrepancy; the term intrusion is used to connote a successful attack and it is also used in the phrase "intrusion detection system" describing a system designed to detect attacks regardless of their success. To be semantically correct and consistent, we should use the phrase "attack detection system" to represent such a system; however, we continue to use the phrase "intrusion detection system" with the understanding that unsuccessful attacks are also represented.
Intrusion detection is a young field, and many terms are not used
consistently. As discussed above, there is even disagreement about what is
meant by "intrusion" and "attack." There are multiple terms used to represent
various methods of detecting intrusions. This section clarifies the meaning of
some important ID concepts as they are used throughout this report. A more
complete set of definitions can be found in Appendix A.
This includes passive protocol analysis which is the use of sniffers in
promiscuous mode. It also includes signature analysis which is the interpretation of a series of packets (or a piece of data contained in those packets) that are determined, in advance, to represent a known pattern of attack [B26-b].
The attack signature may also be manifest in audit records, logs, or in changes in the compromised system.
The functionality of an IDS can be logically distributed into three components: sensors, analyzers, and a user interface.
In addition to these three essential components, an IDS may be supported by a "honeypot," i.e., a system designed and configured to be visible to an intruder and to appear to have known vulnerabilities. A honeypot provides an environment and additional information that can be used to support intrusion analysis. The honeypot serves as a sensor for an IDS by waiting for intruders to attack the apparently vulnerable system. Having a honeypot serve as a sensor provides indications and warnings of an attack. Honeypots have the ability to detect intrusions in a controlled environment and preserve a known state.
Intrusion detection and response have traditionally been thought of as two separate processes; however, the line between them is beginning to blur. As ID systems continue to evolve and improve, they are beginning to incorporate limited capabilities to respond to intrusions.
Typical responses to intrusions may include dropping suspicious traffic at the firewall, denying user access to resources as they exhibit anomalous behavior, or reporting the activity to other hosts or sites involved in the attack.
In Section 1.4.4, we describe
a hierarchical model for intrusion detection systems,
explaining that output from these systems tends to travel
from the lower levels to the higher. Response data on the
other hand may travel in either direction. For example, a
network-based IDS may provide host-level response, such as
modifying configuration files on particular hosts.
Response may include updating configurations for other IDS
components meaning that a response of one IDS or component
could have an effect on the behavior of another IDS or
component. For these reasons, detection and response
systems are beginning to merge.
Although every IDS can be conceptually viewed as having a sensor, an analyzer, and a user interface, the types of data examined and the types of data generated by a particular IDS may vary significantly. ID systems can be classified into one of the following categories based on the types of data they examine:
The categories of ID systems listed above can be thought of as a hierarchy, the top of the hierarchy being multi-network or infrastructure-based ID systems and the bottom being application-based. An IDS at any point in the hierarchy could receive data from any level lower in the hierarchy in addition to a sensor that may operate at the same level. Output from an IDS can be utilized by other ID systems at the same or higher levels in the hierarchy.
There are distinct analysis methods for detecting known and unknown attacks. As discussed above, we defined these as attack signature detection and anomaly detection. In this section, we describe the differences between these two methods by examining several attributes.
Anomaly-based systems in general are more difficult to configure because a comprehensive definition of known and expected behavior for a system is required. This demands that the user discover, understand, represent, and maintain the expected behavior of their system. In many cases, automated support is provided but this takes time to develop and the data that is used must be unambiguous.
The output of anomaly-based ID systems generally produce conclusions based on statistical correlations between actual and expected behaviors. Additionally, anomaly-based systems tend to produce more data since anything outside the realm of expected behavior is reported.
Depending on the environment within which an IDS is deployed, a combination of methods (signature and anomaly) for all types of ID systems (application, host, network, multi-network) may be required for the most effective solution. Signature-based ID systems are not able to detect all possible intrusions because of inherent detection limitations, constantly evolving attacks and exploits, new vulnerabilities, and use of new exploit scripts. Anomaly-based systems generally report a larger number of false positives as expected behavior changes.
An advantage of an anomaly-based IDS is the ability to detect novel attacks that can bypass signature-based systems. Such attacks can be analyzed by a person who can then define attack signatures. Using the combination of signature- and anomaly-based methods provides the capability to detect a larger variety of attacks and keep the signature-based system up to date.
1.5
Operational Challenges with Intrusion Detection Systems
Implementing intrusion detection systems on networks and hosts requires a broad understanding of computer security. The complexity of information technology infrastructures is increasing beyond any one person's ability to understand them, let alone administer them in a way that is operationally secure. Vendors are rapidly releasing new ID systems and aggressively competing for market share in an expanding market. Many products started out as point solutions. However, in response to consumers' inability to fully understand and use many ID systems, vendors are attempting to integrate approaches to solve a broader range of computer security problems. Evaluating ID systems is non-trivial and there is a lack of credible, comprehensive product evaluation information. Hiring and retaining personnel to competently administer security in general and intrusion detection in particular are increasing challenges. All of this rapid change makes it very difficult for an organization to implement an effective, long-term security strategy.
1.5.1 Growth in the Number and Claims of ID Products
Intrusion detection is an important and rapidly growing security technology market. International Data Corporation (IDC) reports revenues for these products increased 135 percent to $136 million in 1998¾and the growth is just getting started.
In 1999, the market was projected to grow almost 100
percent, and by 2003, it will approach $980 million
[B93] . This market growth
is driven by reports of steadily increasing number of
computer security breaches; a 22 percent rise from
1996 to 1998, with $136 million in associated losses
[B94]. Intrusion
detection is considered by many to be the logical
complement to network firewalls, extending the
security management capabilities of system
administrators to include security audit, monitoring,
attack recognition, and response [B23].
Clearly, in this type of fast-paced, growing market, security product vendors are eager to capture market share and make claims that will support their efforts. However, regardless of vendor claims, ID systems do not have the capability to look at every possible security event. The event could have happened on a different network, the IDS itself could have been compromised, or the IDS might have reached its maximum bandwidth capacity and dropped further network traffic [B76]. Most commercial products have their own proprietary protocol for communications between the sensor detecting the event of interest and the analysis function that interprets the significance of the event¾which makes it virtually impossible to correlate information from multiple ID systems or monitoring tools.
ID systems themselves are logical targets for attack [B26-b]. Smart intruders who realize that an IDS has been deployed on a network they are attacking will likely attack the IDS first, disabling it or forcing it to provide false information (distracting security personnel from the actual attack in progress, or framing someone else for the attack). In addition, many commercial and research ID tools have carried forward original design assumptions resulting in security weaknesses such as sending log files without encrypting them, absence of access control, and not performing integrity checks of ID system files.
It is extremely difficult to identify and evaluate the processes, procedures, tools, software, hardware, and databases that comprise the range of ID technologies. There is no industry standard against which to compare such systems because the technology is too new. The commercial ID new product cycle is very fast, based on the pace of the growing market. Northcutt [B76] recommends that you only use publications that are updated at least monthly as ID product buyer's guides. Even after an organization has identified a list of candidate ID system solutions, the evaluation process will be quite complex if it is to provide the answers required to make an informed decision.
Marketing literature rarely describes how well a given IDS finds intruders and how much work is required to use and maintain that system in a fully functioning network with significant daily traffic. IDS vendors can specify which prototypical attacks can be found by their systems, but without access to the normal traffic generated by day-to-day work, they cannot describe how well their systems detect real attacks while passing background traffic and avoiding false alarms.
This information is critical: every declared intrusion requires time to review, regardless of whether it is a correct detection for which a real intrusion occurred, or whether it is merely a false alarm [B95].
Evaluating ID system capabilities requires test data; either network traffic
(for network-based approaches) or profiles (of systems, processes, file use,
and user behavior for host-based approaches). If you choose to do this
yourself as part of the evaluation process, setting up the networks, operating
environments, traffic samples (e.g., using live traffic or simulated "bad"
traffic), and other supporting data is non-trivial and requires a significant
investment of resources and time. Determining the intrusion detection approach
employed by each product and the ways in which intrusions are detected is also
non-trivial. These topics are described in more detail in Section 2.3 and Section 3.5.1.
Some organizations and standards groups are attempting to address many of the
issues surrounding the selection and use of ID technologies. Several of these
efforts are described in Appendix
A.
Given the constantly changing landscape of attacks and intrusions, you need to maintain several types of information (based on the IDS analysis approach) to ensure that your IDS continues to detect suspicious events. According to Amoroso [B89], this information includes
·
profiles of normal and abnormal user, system, and process behavior
·
strings that denote suspicious traffic patterns, including signatures of known attacks and intrusions
·
information used to initiate response actions to various anomalies and attacks
Some of this information is likely maintained by the IDS vendor but not necessarily all. Staff responsible for the IDS should obtain the information in a secure manner and arrange for installed ID systems to be regularly updated (similar to operating system patches or new viruses being loaded into virus detection software). Any information not provided by the vendor must be maintained and applied when needed by technical staff.
Technology alone is not enough to maintain network security. An organization needs qualified technical staff to evaluate, select, install, operate, and maintain ID technologies. In today's market, there is a decreasing availability of the qualified intrusion analysts and system/network administrators who are knowledgeable about computer security.
According to Northcutt [B76], having an ID product do your "thinking/analysis" for you is a natural response to the lack of skilled technical people, particularly those with security skills. However, there are many attacks and probes occurring every day that are not canned "script kiddie" exploits. Only trained analysts with expert-class tools are going to be able to detect and analyze these.
As Amoroso indicates [B89], nearly all
reported
incidents in which an intruder has been caught in real time have involved manual intrusion detection methods used by attentive security experts. Furthermore, these incidents have involved locally developed ID tools and traps rather than commercial systems [B89]. Automation of the entire ID process is unlikely in the near future.
In the face of this reality, many organizations are choosing to outsource the
ID operations, an option that comes with its own issues and risks (see Section 4.6 for further
information).
Intrusion detection is needed because firewalls cannot provide complete protection against intrusion. Experience teaches us never to rely on a single defensive line or technique. A firewall serves as an effective noise filter, stopping many attacks before they can enter an organization's networks. However, firewalls are vulnerable to errors in configuration and ambiguous or undefined security policies. They are generally unable to protect against malicious mobile code, insider attacks, and unsecured modems. Firewalls rely on the existence of a central point through which traffic flows when the growing trend is towards geographically distributed networks with inside and outside users traversing the same subnets and, therefore, the absence of central points for firewall monitoring purposes. On internal networks, routers or switches can be configured to watch for signs of intrusion and take appropriate action based on what they detect [B76].
Implementing multiple layers of protection as part of an overall security
architecture (such as firewalls, access control and authentication mechanisms,
monitoring tools, vulnerability scanning tools, ID systems, security training)
makes penetration by external intruders more difficult while making intrusion
prevention and detection somewhat easier. See Section 4.5 for more details on this
point.
1.4.2 ID System Components
An analysis approach is a method used by an IDS to determine whether or
not an intrusion has occurred. There are two major categories of analysis
approaches:
An action conducted by one adversary, the intruder,
against another adversary, the victim. The intruder
carries out an attack with a specific objective in
mind. From the perspective of an administrator
responsible for maintaining a system, an attack is a
set of one or more events that may have one or more
security consequences. From the perspective of an
intruder, an attack is a mechanism to fulfill an
objective.
The process of using a vulnerability to violate a security policy. A tool or defined method that could be used to violate a security policy is often referred to as an exploit script.
An event that the IDS fails to identify as an intrusion when one has in
fact occurred [B26-b].
An event, incorrectly identified by the IDS as being an intrusion when none has occurred [B26-b].
A collection of data
representing one or more related attacks. Attacks may
be related by attacker, type of attack, objectives,
sites, or timing.
The person who carries out an attack. Attacker is a
common synonym for intruder. The words attacker and
intruder apply only after an attack has occurred. A
potential intruder may be referred to as an adversary.
Since the label of intruder is assigned by the victim
of the intrusion and is therefore contingent on the
victim's definition of encroachment, there can be no
ubiquitous categorization of actions as being intrusive
or not.
A common synonym for the word "attack"; more
precisely, a successful attack. In this report, we
often use the term intrusion to include attack, because
the subject of the report is intrusion detection
systems.
A feature or a combination of features of a system
that allows an adversary to place the system in a state
that is contrary to the desires of the people
responsible for the system and increases the
probability or magnitude of undesirable behavior in or
of the system.
Sensors are responsible for collecting data. The
input for a sensor may be any part of a system that
could contain evidence of an intrusion. Example types
of input to a sensor are network packets, log files,
and system call traces. Sensors collect and forward
this information to the analyzer.
Analyzers receive input from one or more sensors or from other analyzers. The analyzer is responsible for determining if an intrusion has occurred. The output of this component is an indication that an intrusion has occurred. The output may include evidence supporting the conclusion that an intrusion occurred. The analyzer may provide guidance about what actions to take as a result of the intrusion.
The user interface to an IDS enables a user to view
output from the system or control the behavior of the
system. In some systems, the user interface may equate
to a "manager," "director," or "console" component.
An application-based IDS examines the behavior of an application program, generally in the form of log files.
A host-based IDS examines data such as log files, process accounting information, user behavior, or outputs from application-based ID systems operating on the host.
A network IDS examines network traffic. It may have access to outputs from host-based and application-based ID systems operating within the monitored network environment.
A multi-network IDS generally takes the form of an incident response team (IRT), where the input of the system comes from "sites" within their constituency. A site in this case is an entity that lies within an administrative domain. Data communicated to this type of IDS is generally from application, host, network, or other multi-network intrusion detection systems.
Detecting intrusions requires either knowledge of possible intrusions or knowledge of the known and expected behavior of a system. In order for an IDS with a signature-based method to detect all attacks, it requires prior knowledge of all possible attacks. The IDS must recognize either the details of an attack or the patterns at a more abstract level that characterize the class of an attack. An anomaly-based system must have full knowledge of the expected behavior of the system to detect all attacks. In reality, neither of these is possible; they represent ideals.
Another attribute to consider is ease of configuration. A signature-based system in general requires significantly less configuration effort than a system to detect anomalies since the latter requires much data collection, analysis, and updating. Some systems allow users to create their own signature files which can increase the complexity of establishing the desired configuration.
Signature-based ID systems generally produce conclusions based on pattern matching. The output of a signature-based system can vary from an alert message indicating that a particular signature has occurred to one that also provides supporting data that is relevant to the signature's occurrence.
Signatures that are not specific and anomaly profiles that are not adequately specified to describe expected behavior both result in ID systems that produce potentially large numbers of false positives and false negatives.
1
Based on CERT/CC experience.
[Title Page]
[Abstract]
[Figures]