Scanners

Several products are available to inspect your system or network configuration for weaknesses. Most of these products are run on a scheduled interval. An advantage of this approach is that the scanner product can be customized for different applications. For example, if certain Web server configurations are known to open security holes, a scanner can read the contents of the configuration files and look for improper entries. The scanner also can make an appropriate change to the file to remove the problem.

What are some things a scanner is not designed to do? Scanners obviously are not responsible for the primary I&A activities of the system. Also, scanners are not responsible for deciding the outcome of all access control requests. Do you need a scanner? The answer is almost certainly “yes.” Scanners provide a way for you to verify that your security policy is configured correctly and that the policy is being enforced correctly by the numerous security components at your site. Today, most scanners are marketed as intrusion detection products because they look for weaknesses in your system that can be exploited by an intruder or by a malicious insider.

Intrusion Detection and Monitoring

Although the research community has been active with intrusion detection systems (IDSs) for more than a decade, products in this category have only recently received wider market interest. The purpose of an IDS product is to monitor the system for attacks. An attack might be signaled by something as simple as a program that illegally modifies a user name. Complex attacks might involve sequences of events that span multiple systems. Intrusion detection products are classified with system monitors because they usually depend on auditing information provided from the system’s logs or data gathered by sniffing network traffic. One difference between scanners and IDSs is the time interval. A scanner is running in real time when it is started. However, a scanner is rarely run all of the time. Intrusion detection products are designed to run in real time and to constantly monitor the system for attacks.

Additional Product Differences

Besides thinking about products based on the security services they perform, you can also differentiate between products based on other design tradeoffs chosen by the vendor. Some tradeoffs are binary because the vendor is faced with two conflicting requirements that cannot be met simultaneously. A common example is the conflict surrounding a product designed for novice users or for expert users. If a product is complex and provides features that a sophisticated user might want, such as the capability to configure access control rules containing many different variables, a novice user probably will be overwhelmed when configuring the security policy. If the vendor decides in favor of expert users, the novice user might buy a less capable but easier-to-use product. When you think critically about security products, watch for the following tradeoffs.

Real Time or Interval Based

A product like a scanner runs on an interval. That is, you schedule the scan to begin at a specific time rather than running the scan continuously. A real-time intrusion detection product, on the other hand, would always be running and watching for attacks. Sometimes classifying a product as real time or interval based can be a confusing process because real time is always a relative concept. For example, a product might claim to detect events in real time. However, the operating system may be storing several events in a queue for seconds or minutes before releasing the events to waiting programs. The event monitoring program may not really see the event until long after it happened. In computer security, a few milliseconds can make a difference between disaster or success. Keep in mind that the perception of real time depends on your perspective of the system. Someone working at the level of the CPU itself has a different notion of real time than someone connected to a system across a network.

Centralized or Distributed

Everyone who manages a network of computers wants some type of centralized administration and reporting. On the other hand, centralized decision making can often be slower. Finding the proper balance is a challenge for security vendors.

Centralized reporting of security incidents is advised for a number of reasons including cost, consistency, and accountability for actions. Conversely, you do not want automated responses, like disconnecting a hacker, to be adversely affected by network delays. The time it takes the attacked node to receive the “disconnect response” from a centralized response database could leave enough of a window for someone to plant a Trojan Horse. A middle-of-the-road approach would be to report security violations at a central console but to let each node in the network immediately carry out a predefined automated response using its own computing resources, rather than looking up the appropriate response in a centralized database. A configuration option for centralized reports but distributed responses would make this possible.

System Level or Network Level

Some security products focus on improving network security, and others add value at a higher level of abstraction in the computer. A product that encrypts network traffic improves the confidentiality of data passed between systems at the network level. Programs controlling whether users are allowed to delete files operate at the file system level of abstraction, rather than at the network packet level. In the intrusion detection product area, vendors have tended to focus on either the network level or the system level.

Augment or Replace

One of the basic reasons you buy additional security products is because something you already have is not sufficient. You buy another access control product because the operating system that came with your computer did not allow you to express the types of access control rules you need for your policy. The new product can either replace programs that shipped with the operating system, or it can augment these operating system programs, typically by intercepting them. The vendor may choose to replace programs or libraries because this leads to better performance. The tradeoff is obvious when the operating system provider ships a patch that reverts to the original program and wipes out the replacement provided by the security vendor. You need to perform some additional integration tasks after the patch is applied. If the operating calls are intercepted, the security vendor might be trading off performance penalties for a simpler implementation.