Systems and networks are subject to electronic attacks. The increasingly frequent attacks on Internet visible systems are attempts to breach information security requirements for protection of data. Vulnerability assessment tools check systems and networks for system problems and configuration errors that represent security vulnerabilities. Intrusion detection systems collect information from a variety of vantage points within computer systems and networks and analyze this information for symptoms of security breaches. Both intrusion detection and vulnerability assessment technologies allow organizations to protect themselves from losses associated with network security problems.
The market for intrusion detection products, driven by reports of steadily increasing computer security breaches, has grown from $40 million in 1997 to $100 million in 1998. Intrusion detection is the logical complement to network firewalls, extending the security management capabilities of system administrators to include security audit, monitoring, attack recognition, and response.
Intrusion detection systems perform a variety of functions:
Benefits of intrusion detection and vulnerability assessment products include the following:
Unrealistic expectations about intrusion detection and vulnerability assessment products must be corrected: these products are not silver bullets and they
The following terms explain the main concepts in intrusion detection, and will help to standardize the terminology and description of evolving products.
Intrusion Detection Systems are security management tools that:
Application based intrusion detection sensors collect information at the application level. Examples of application level include logs generated by database management software, web servers, or firewalls. With the proliferation of Webbed electric commerce, security will increasingly focus on interactions between users and application programs and data.
Host based intrusion detection agents (also called sensors) collect information reflecting the activity that occurs on a particular system. This information is sometimes in the form of operating system audit trails. It can also include system logs, other logs generated by operating system processes, and contents of system objects not reflected in the standard operating system audit and logging mechanisms.
Integrity analysis enables one to implement a focused and effective monitoring strategy for systems in which data integrity and process integrity are of primary concern. This approach monitors specific files, system objects and system object attributes for change, looking at the outcome of attack processes rather than the details of the attack processes. Some systems use checksums (computations whose value depends on the original constitution of the system object) to detect breaches of integrity.
Network based intrusion detection sensors collect information from the network itself. This information is usually gathered by packet sniffing, using network interfaces set in promiscuous mode; however, some agents are integrated in network hardware devices.
Some intrusion detection products combine application, host, and network based sensors.
Once the location(s) of intrusion detection system agents are established, the timing of the information collection and analysis are of interest.
In batch oriented (also called interval oriented) approaches, operating system audit mechanisms or other host based agents log event information to files and the intrusion detection system periodically analyzes these files for signs of intrusion or misuse.
Real time systems provide information collection, analysis, and reporting (with possible responses) on a continuous basis. The term real-time is used here as in process control systems; that is, the detection process happens quickly enough to hinder the attack. Note that while this definition applies to systems that take milliseconds to perform analysis, it can also describe systems that are slower. Real-time systems provide a variety of real-time alarms (many support offsite alarming mechanisms such as email, pagers, and telephone messaging), as well as automatic responses to attacks. Typical responses range from simple notification to increasing the sensitivity of the monitoring, terminating the network connection from the source of the attack or changing system settings to limit damage.
As in sensors, analysis functions can reside at host level, at network level, or both. Performing analysis strictly at the host level has the advantage of minimizing network load. However, it has the disadvantage of not allowing the detection of broad scale attacks targeting a network of machines (for instance, an attacker sequentially hopping through a network performing brute force password guessing against each host).
Consolidating raw data and performing analysis strictly at the network level (in the case of systems with sensors at both host and network levels) offer the capability to detect attacks that involve more than one host on the network. The disadvantage to this approach is that the network load associated with transferring raw host level information to the analysis engine can be crippling.
As in sensor placement, the optimal strategy for performing analysis of logs is one in which analysis is done at both host and network levels. The analysis done at the host level can be simple or extensive depending on the nature of the sensor information generated in that host or the signature against which the information is matched. The network level analysis can take the results from the host level analysis and use it to detect signs of network wide attack or suspicious behavior without incurring as heavy a network load. Furthermore, in larger networks, this sort of approach can be applied hierarchically. That is, groups of hosts can report to a network analysis engine, which in turn reports its results to another analysis engine that collects results from a number of other network analysis engines and so on. This hierarchical structure lets intrusion detection products succeed even in larger organizations.
Signatures are patterns corresponding to known attacks or misuses of systems. They may be simple (character string matching looking for a single term or command) or complex (security state transition written as a formal mathematical expression). In general a signature can be concerned with a process (the execution of a particular command) or an outcome (the acquisition of a root shell.).
Signature analysis is pattern matching of system settings and user activities against a database of known attacks. Most commercial intrusion detection products perform signature analysis against a vendor supplied database of known attacks. Additional signatures specified by the customer can also be added as part of the intrusion detection system configuration process. Most vendors also include periodic updates of signature databases as part of software maintenance agreements.
One advantage of signature analysis is that it allows sensors to collect a more tightly targeted set of system data, thereby reducing system overhead. Unless signature databases are unusually large (say hundreds of thousands or millions of complex signatures), signature analysis is usually more efficient than statistical analysis due to the absence of floating point computations.
Statistical analysis finds deviations from normal patterns of behavior. This feature, common in research settings, is found in few commercial intrusion detection products. Statistical profiles are created for system objects (e.g., users, files, directories, devices, etc.) by measuring various attributes of normal use (e.g., number of accesses, number of times an operation fails, time of day, etc.). Mean frequencies and measures of variability are calculated for each type of normal usage. Possible intrusions are signaled when observed values fall outside the normal range. For example, statistical analysis might signal an unusual event if an accountant who had never previously logged into the network outside the hours of 8 AM to 6 PM were to access the system at 2 AM.
Integrity analysis focuses on whether some aspect of a file or object has been altered. This often includes file and directory attributes, content and data streams. Integrity analysis often utilizes strong cryptographic mechanisms, called message digest (or hash) algorithms, which can recognize even subtle changes.
Some network based intrusion detection systems permit one to specify a desired reaction to a detected problem. This feature has captured the imagination of many in the security management arena, especially as the frequency of denial of service attacks (saturation of system resources) has increased.
A typical response to a detected network attack is to take steps to alter the environment of the system under attack. This alteration can consist of terminating the connection used by the attacker and reconfiguring network devices to block further access to the site from the same source address. The response mechanisms are intended to allow system administrators to take an active role within their authority to minimize damage associated with a detected attack.
Although it is a popular topic of discussion, striking back by attacking the source is ill advised at this point. TCP/IP, the basis for Internet communications, allows spoofing of packet source addressing; therefore, retaliation against the putative source of an attack might in fact damage an innocent party whose IP address had been forged for the attack.
Another valuable feature of intrusion detection systems is to drill down into information sources by setting agents and audit mechanisms to collect more information about the connection in question. This can also include collecting information that allows playback of attacks. This response allows the system administrator to collect information that supports more accurate judgments about the intent of the attacker. It also allows collection of information that might assist law enforcement or other investigators in identifying those responsible for the attack.
Knowledgeable attackers will often attempt to target the intrusion detection sensors or the analysis engine. In this case, a validation response, in which the sensors and/or analysis engine are queried in order to determine whether they continue to work properly, is suitable.
Finally, most real-time systems allow a system administrator to select a variety of alarm mechanisms to notify responsible parties of detected attacks. The alarms can notify key personnel by email or pager messages sent instantaneously with information about the problem. A message to the system console is standard, and many systems allow a variety of visual and auditory signals as part of the alarm.
Customers need flexibility in adapting intrusion detection systems to their own environments. The following features help to tailor these products to specific needs.
No two organizations are the same. Each has a different set of security and management concerns driving security policy, a different set of hardware and software platforms included in their systems environment, a different set of users or a different set of operational policies. Therefore, the first issue facing a customer who acquires an intrusion detection system is the installation and setup of the system.
Many products, especially those designed for Windows NT environments, are shipped with clear, concise directions and installation scripts included. However, configuring these products is still an involved process. Information that customers must enter range from the IP addresses of the systems protected by the product to the sorts of security violations or system activities that the products are to detect and report. This is when a clear, current set of site security policy, procedures, and practices pays off handsomely.
Products that include host level agents typically use operating system audit mechanisms. These products offer improved user interfaces to the operating system audit controls, allowing users to specify what information is collected and how it is collected.
One of the benefits of intrusion detection systems is the demonstration of due diligence in system security management practice. A key to demonstrating this due diligence (e.g., to upper management, internal auditors and regulatory personnel) is to document the findings of intrusion detection products over a particular time interval.
Most intrusion detection products have the ability to easily generate reports; many offer the capability to export report data to databases for subsequent analysis and archiving. Many offer multiple report formats (e.g., hard copy, screen, and HTML), with features allowing the user to report different layers of detail depending on the intended recipient of the report.
Once the intrusion detection product is configured to the system environment, the next issue is actually running the system. Rudimentary controls include starting and stopping the system, establishing the schedule at which certain activities should take place, and specifying how alarms should be handled. In the control function, another critical issue in intrusion detection products is addressed: the security and reliability of the intrusion detection system itself. One way of addressing this is to require authentication before the system responds to control or configuration commands. This reduces the risk of an adversary gaining access to the system and shutting it down.
In some cases, intrusion detection systems are used to ensure the operation of other parts of the security infrastructure (e.g., firewalls). In this proof of validity, the intrusion detection system analyses information from both inside and outside the coverage area of the security mechanism in question, then compares results. The mechanism is proven valid when the intrusion detection system isolates evidence that an attack (sensed on the outside) is blocked by the mechanism (therefore not sensed on the inside). Vulnerability assessment products are often used as part of this validation process and they function in synergy with intrusion detection systems.
Given the role of intrusion detection systems and the sensitivity of the information they sometimes contain, system designers have devoted considerable thought to the measures needed to protect the system itself. A standard strategy of attackers is to determine what security mechanisms are in place and then take steps to nullify or circumvent them. One can therefore assume that intrusion detection systems will operate in a hostile threat environment. Consequently, many features are included in systems to minimize the chances that the system will be successfully defeated, or worse yet, will be used as a vehicle of attack.
Some vendors provide embedded license mechanisms to assure that only legitimate customers of the vendor can utilize the product. This reduces the risk that if the software is successfully stolen from the vendor or customer, the adversary could use it to monitor other machines or probe them for vulnerabilities.
Another protection strategy utilizes strong encryption to secure communications between sensors, analysis engines, and control consoles. This lowers the risk that an adversary might spoof the sensor output for a particular system in order to mask attack activity.
Some vendors use digital signature and message digest algorithms to protect signature database updates from tampering by adversaries. This allows time sensitive distribution of new attack signatures to customers without the risk of corruption.
Some vendors offer decoy server software to allow more accurate characterization of the threat levels for a customer's system environment. A decoy server is just that -- a server that has no other purpose than attracting hacker attention. It is equipped with sensitive agents that collect information about the hacker's location, the path of the attack and the substance of the attack. The decoy collects and logs this information to a secure location. Some decoy servers also provide features that create jail environments to which hackers are redirected -- environments in which their attacks cannot damage operational systems.
Vulnerability assessment products (also known as scanners) are security management tools that:
Vulnerability assessment products complement intrusion detection systems: they allow system administrators to be proactive in securing their systems by finding and closing security holes before attackers can use them. Intrusion detection systems are by nature reactive: they monitor for attackers targeting systems in hopes of interrupting the attacks before the system is damaged.
Application based assessment uses passive, non-invasive techniques to check settings and configurations within application packages for errors known to have security ramifications.
Host based assessment uses passive, non-invasive techniques to check system settings and configurations for errors known to cause security problems. These checks typically encompass system internals and include things such as file permissions and ownership settings and whether operating system bug patches have been applied.
Most vulnerability assessment products perform password analysis as part of their assessment. Password analysis consists of running password crackers against password files, utilizing a well known attack in order to quickly locate weak, nonexistent, or otherwise flawed passwords.
Target based assessment (also known as file integrity assessment) uses passive, non-invasive techniques to check the integrity of system and data files as well as system objects and their attributes (e.g., hidden data streams, databases, and registry keys). Target based assessment products use cryptographic checksums (message digest algorithms) to make tampering evident for critical systems objects and files. Message digest algorithms are based on hash functions, which possess the property that extremely subtle changes in the input to the function produce large differences in the result. This means that a change in a data stream fed to a message digest algorithm produces a huge change in the checksum generated by the algorithm. These algorithms are cryptographically strong; i.e., given a particular output value, it is practically impossible to come up with another input to the algorithm that will product an identical output. This eliminates a common attack against relatively simple CRC (cyclic redundancy code) checksums in which hackers mask alterations to files by altering the content of the file so that the same checksum is generated for both the original and the tampered file. (Garfinkel, Simson, and Spafford, Gene, Practical UNIX and Internet Security, Second Edition, Sebastopol, CA, O’Reilly and Associates, 1996)
Target based assessment products run in a closed loop, processing files, system objects, and system object attributes to generate checksums; they then compare them to previous checksums, looking for changes. When a change is detected, the product sends a message to the intrusion detection system that records the problem with a time stamp corresponding to the probable time of alteration. This process can provide a one record trigger for an intruder alert or it can serve as a milestone for an investigator performing a trace of the events leading to the alteration.
Network based vulnerability assessment uses active, invasive techniques to determine whether a given system is vulnerable to a set of attacks. In network based assessment, a variety of attack scenarios are reenacted against the target system(s), and results analyzed in order to determine the system's vulnerability to attack. In some cases, network assessment is used to scan for network specific problems (e.g., port scanning.)
Network based vulnerability assessment is often used for penetration testing (specifically, testing a firewall) and security auditing.
Integrated vulnerability assessment combines both active, network based assessment with passive, host based assessment techniques, often combining them with a centralized management function. We note here that Windows NT environments do not recognize as crisp a policy boundary between host and network based access.
Collecting data is the first step in vulnerability assessment; data analysis is the second. In large complex network installations, it is helpful to organize vulnerability assessment using a console agent architecture. This architecture is particularly helpful where networks are heterogeneous, i.e., with a wide range of operating system platforms.
Reporting in vulnerability assessment holds the key to understanding and rectifying security holes. Reporting provides the opportunity to document the security health of the systems scanned, to publish problems to an appropriate level of management so that resources and responsibilities are assigned to fix them, and to educate everyone in the organization about the importance of system security and how to achieve it. Options provided include variable reporting formats (with HTML offering the ability to selectively drill down to a finer level of detail as desired) and levels of detail, providing different amounts of background information about the vulnerabilities and associated fixes.
Although it is easy to understand the requirements driving vulnerability assessment products, and easier still to understand how the products might be used to support an organizational security strategy, perhaps the most critical features in selecting a product are those regarding the deployment of that product in an operational environment.
Once the user has run vulnerability assessment tools and spotted vulnerabilities, the user can specify responses. The response options provided include the following:
As in intrusion detection, vulnerability assessment products have various management functions:
As in intrusion detection, there are special security considerations associated with the design, deployment, and maintenance of vulnerability assessment products.