|
|
This chapter contains the following sections:
Without a doubt, cyberspace attacks have grabbed lots of headlines.
According to usnews.com, the online version of U.S. News and World Report, the past twelve months have seen dozens of hacks perpretated against high-profile targets, including newspapers, telephone companies, Internet startups, computer hardware manufacturers, and even government agencies. In 1997 an East Coast hacker disabled operations at a regional telephone utility and radio transmissions at a local airport. Dozens of other cases involve disgruntled employees inflicting major damage to their former employer's proprietary data and hardware.
These attacks are perpretated for a variety of reasons, including extortion, fraud, espionage, sabotage, or mere curiosity. The acts themselves can involve a range of activity, including misuse of authorized systems, system break-ins, equipment theft, interception of network traffic, and reconfiguration of victim systems to allow future access. Because of the nature of global networks, these attacks can (and often do) cross network and national boundaries.
To counter these security threats, various commercial vendors have brought security products to the market, such as firewalls, encryption and authentication, and access control lists. These products, although providing a certain measure of security, contain certain limitations that may allow attackers to get past them.
Complex security threats require complex security countermeasures, so there is a definite need for a complementary security technology, one that:
The technology previously described is known as intrusion detection. The remainder of this guide provides background information, design considerations, and scenarios for deploying intrusion detection systems.
Intrusion detection, put simply, is the ability to analyze data in real time to detect, log, and stop misuse or attacks as they occur. In practice, intrusion detection is more complex than this simple definition, and various types of intrusion detection systems (IDSs) go about their activity in different ways.
Host-based IDSes, for example, are used to secure critical network servers or other systems containing sensitive information. In a typical implementation, agents are loaded on each protected asset (see Figure 1-1). These agents make use of system resources---disk space, RAM, CPU time---to analyze operating system, application, and system audit trails. The collected information is compared to a set of rules to determine if a security incident has occurred. These agents are tailored to detect host-related activity and can track these types of events with a fine degree of granularity (for example, which user accessed which file at what time).
Host-based agents can be self-contained, sending alarm information to the local console, or remotely managed by a manager/collector that receives periodic updates and security data. A host-based implementation that includes a centralized management platform makes it easier to upgrade the software. These systems are ideal if a limited number of critical systems need protection, and are complementary to network-based IDSes, but they do not scale well if an enterprise-wide solution is needed.
Network-based IDSes monitor activity on a specific network segment. Unlike host-based agents, network-based systems are usually dedicated platforms with two components: a sensor, which passively analyzes network traffic, and a management system, which displays alarm information from the sensor and allows security personnel to configure the sensors (see Figure 1-2). Implementations vary: some vendors sell separate sensor and management platforms; others offer a self-contained sensor/manager.
The sensors in a network-based IDS capture network traffic in the monitored segment and perform rules-based or expert system analysis of the traffic using configured parameters. The sensors analyze packet headers to determine source and destination addresses and type of data being transmitted, and analyze the packet payload to discover information in the data being transmitted. Once the sensor detects misuse, it can perform various security-related actions: log the event, send an alarm to the management console, reset the data connection, or instruct a router to shun (deny) any future traffic from that host or network.
The types of rules that an IDS uses to detect misuse can vary, but there are two primary ways of detecting misuse: profile-based and signature-based detection.
Profile-based detection (also known as anomaly-based detection) involves building statistical profiles of user activity and then reacting to any activity that falls outside these established profiles. A user's profile can contain attributes such as files and servers frequently accessed, time spent logged onto the network, location of network access, and so forth.
There are two major hurdles that so far have kept profile-based detection an impractical, cost-prohibitive solution. First, users change the way they use the network on a regular basis. Projects begin and end, employees are transferred to other departments, or they go on the road or work from home, thus changing their point of entry into the network. Second, there is as yet no cost-effective way to build a sensor with enough memory and processing power to maintain even a small percentage of the ever-changing user profiles. Thus, due to current limitations on memory and processing power, profile-based intrusion detection often leads to a large number of false positives, or alarms deriving from non-threatening events.
Signature-based detection, on a very basic level, can be compared to virus checking programs. Vendors produce a list of signatures that the IDS uses to compare against activity on the network or host. When a match is found, the IDS takes some action, such as logging the event or sending an alarm to a management console. Although many vendors allow users to configure existing signatures and create new ones, for the most part customers are dependent on vendors to provide the latest signatures to keep the IDS up to date with the latest attacks.
Signature-based detection can also produce false positives, as certain normal network activity can be construed as malicious. For example, some network applications or operating systems may send out numerous ICMP messages, which a signature-based detection system may interpret as an attempt by an attacker to map out a network segment.
"Design Considerations," provides more information on analyzing users and traffic patterns, as well as other network considerations, which should help minimize false positives.
As stated previously, intrusion detection technology is a complimentary tool that can be used alongside traditional security products. In other words, intrusion detection is another part of the total end-to-end security solution. How do IDSes compare with other security products? This section discusses the following types of products and how IDSes can complement them:
Firewalls, one of the most popular security products, are based on the customer defining a very comprehensive policy (authorized traffic flows and services) that is enforced by the firewall. Generally speaking, there are two types of policies:
1. That which is not specifically authorized is denied.
2. That which is not specifically denied is authorized.
The first type of policy is by far the most prevalent, but it requires that the customer know the risks involved before authorizing services to pass through the firewall. For instance, if the firewall allows Web traffic to pass, then an attacker can send a command that exercises a buffer overflow in the web browser application. The firewall will not stop these packets from reaching the victim system.
IDS vendors, on the other hand, research and define the vulnerabilities inherent in different types of services. In the previous example, a countermeasure that detects the buffer overflow command on specific types of traffic (TCP port 80, for example) could be developed and deployed in a matter of hours.
Another difference between IDSes and firewalls is their impact on network performance. Firewalls typically are used as access control devices on a network, and could impact throughput on a local link. IDSes are typically passive monitors; a few, like Cisco's IOS IDS implementation, are inline devices that inspect packets as they cross a router's interface.
One way to effectively use firewalls and IDSes together is to place the IDS sensor in the demilitarized zone (DMZ), in front of the firewall. In the DMZ, the sensor monitors all traffic that enters and leaves the protected network. The sensor can detect attacks that may be of interest to the organization, such as competitors trying to map the network. Another scenario involves placing the sensor inside the firewall, and connecting it to the protected LAN. The firewall can then protect the perimeter, and the IDS sensor monitors internal users and acts as a verifier of firewall policies.
These and other scenarios are covered in "Scenarios."
Encryption and authentication are also very popular and very effective ways to secure information and resources. However, each of these has associated problems that keep them from being the end-all be-all security solution.
Encryption provides point-to-point confidentiality of data. The points involved can be client-to-client, client-to-server, or router-to-router. The data on any given network segment can be bulk-encrypted---in other words, every packet between the end points is encrypted---or encrypted by session.
For example, a web server on an e-commerce site might be configured to allow customers to enter confidential information (credit card numbers and other personal data) via an SSL (Secure Socket Layer) session. At the same time, there might be thousands of customers merely browsing the online catalog, an activity that does not require encryption.
In this situation, the web site's data and hard disk are both unprotected because only the user sessions are encrypted. Once the data from these sessions is stored on the server (such as in a database) it is stored in an unencrypted manner. An attacker could conceivably find a vulnerability in the web server that would allow access; once logged on, the attacker could browse the confidential consumer information without any roadblocks. No one would be the wiser.
Of course, an attacker may not be interested in browsing the data, but in erasing it or shutting down the server (the latter is termed a denial-of-service attack). In either case, even host-based encryption schemes protecting the server's data would be unable to prevent this activity.
Authentication schemes are in wide use in these security-conscious days. Just about every machine on the network requires a user to log on and provide a password. However, this requirement cannot protect against users creating weak or easily guessed passwords. Furthermore, some attackers can bypass the authentication safeguard and install services on a system that give them future uncontested access.
Although IDSes normally are not used to enforce authentication or encryption schemes, they would be able to detect many of the common attacks used by the hacker community to exploit network server vulnerabilities. The attempts to break in to a server would trigger an alarm, alerting security personnel that some malicious activity is going on.
Access control lists, or sets of rules that routers and firewalls use to permit or deny certain traffic, are an effective measure against unauthorized traffic entering a network. Access control lists are commonly applied to router or firewall interfaces, and can be configured to control which data sessions can pass and which fail.
The main problem with access control lists is that unless the system administrator instructs the router to log any instances in which traffic is denied, then nobody has a clear picture of ongoing policy violations. Knowing about policy violations, or intrusion attempts that fail, is just as important as detecting successful attacks. If configured correctly, a router or firewall can log policy violations and send this information to a management console.
Cisco Systems currently uses a centralized management console known as the NetRanger Director, to gather alarm data from various sources, among them the NetRanger Sensor, the Cisco IOS IDS feature of the Cisco IOS Firewall Feature Set, and access control lists (see Figure 1-3).
Posted: Wed Aug 4 09:12:18 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.