Cisco Knowledge Suite Cisco SystemsCisco Press
   

   
Home
MyCKS
Cutting Edge
Certification
Core Reference
Guided Learning
   
Networking Architecture
LAN
WAN
Switching
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services
 

Analysis Schemes

   

Contents Next >

Analysis Schemes

  

4.1. -

Thinking About Intrusions

  

4.2. -

A Model for Intrusion Analysis

  

4.3. -

Techniques

  

4.4. -

Conclusion

  

 

Endnotes

Save to MyCKS

 
Intrusion Detection

From: Intrusion Detection
Author: Rebecca Bace
Publisher: MTP
More Information

4. Analysis Schemes

“Is there any other point to which you would wish to draw my attention?”
“To the curious incident of the dog in the nighttime.”
“The dog did nothing in the nighttime.”
“That was the curious incident,” remarked Sherlock Holmes.
--Sir Arthur Conan Doyle

Given a variety of rich information sources about the system activities you're charged with monitoring, the next stop on the intrusion detection circuit is analysis. With analysis, you're faced with the core issue of intrusion detection: What is going on here, and should I be interested in or concerned about it?

Within the analysis function, information is synchronized, classified, and subjected to scrutiny of various types to identify activity patterns of security significance. This chapter covers the vast area of analysis, considers the various goals of analysis, and discusses the issues you must take into account when devising an analysis scheme for a particular goal or system. It also explores the variables that affect the quality of the analysis.

4.1. Thinking About Intrusions

In considering the analysis functions of intrusion detection, let's start by articulating the detection process in intuitive terms. This definition will lend structure to the subsequent discussion of the fundamental issues and functions of analysis.

4.1.1. Defining Analysis

Analysis, in the context of intrusion detection, is organizing and characterizing data about user and system activity to identify activity of interest. This activity can be isolated either as it happens or after the fact. In some cases, further analysis is needed to establish accountability for the activity. Depending on the type of analysis, additional evaluation may be performed to tune or otherwise improve the outcome of subsequent analysis.

Intrusion detection is the second step in a general system security management process model, pictured in Figure 4.1. This model is helpful because certain analysis functions serve the needs of the investigative and resolution steps of the management process.

Figure 4.1. A General Model of Security Management

4.1.2. Goals

Security managers hope to gain several benefits by performing intrusion detection analysis. The overarching assumption is that people use intrusion detection systems to improve the security of their information systems.

  • Significant deterrence    One benefit a security manager seeks is to deter problem behaviors. The knowledge that analysis is being performed and the credible threat of discovery and punishment serve as a deterrent to intruders.

  • Quality control for security design and administration     Problems that are discovered in the course of analysis can indicate flaws in the design and management of security for the system. The security manager, so notified, can then correct theseproblems before an adversary utilizes them to damage or steal information.

  • Useful information on actual intrusions    This information should be relevant, detailed, and trustworthy so that it can support criminal or civil legal remedies. It can also be used to identify needed corrections in the organization's security configuration, policy, or strategy.

4.1.3. Supporting Goals

Now that the goals of the analysis process are outlined, it's time to consider how each one drives specific functional requirements for an intrusion detection system. Structuring the requirements as sets of prioritized goals and subgoals helps to optimize the system.

4.1.3.1. Requirements

Intrusion detection analysis supports two basic requirements. One is, as we've mentioned before, accountability, which refers to the ability to link an activity with the person or entity responsible for it. Accountability requires you to be able to consistently and reliably identify and authenticate each user of the system. Furthermore, you must also be able to reliably associate each user with the audit or other event records of her activities.

Although the concepts of accountability are straightforward and common in businessenvironments, they are difficult to implement in network environments. Unless you're in an environment featuring a single sign-on system, which centralizes identification and authentication for a large network, a user may have different user identities on different systems within the network. Because host-level audit trails reflect user activity in terms of the user's local identity, keeping track of user identity in activities that involve multiple hosts and user accounts requires additional processing.

The second requirement for intrusion detection analysis is real-time detection and response. This requirement includes the ability to quickly recognize the chain of events associated with an attack, and the ability to then block the attack (for instance, by terminating the network connection used by the attacker) or to shield the system from the impact of the attack (for instance, by tracing the commands sent by the attacker and restoring any altered files or objects to their pre-attack state).

4.1.3.2. Subgoals

Analysis also has subgoals. For instance, you might need to retain information in a form that supports system and network forensic analysis. Another subgoal might involve retaining some knowledge about the system performance or identifying problems that affectsystem performance. Yet another might involve archiving and protecting the integrity of event logs required by regulators or law enforcement entities.

4.1.3.3. Prioritizing Goals

After goals and requirements are articulated, they should be prioritized. Prioritization is necessary to determine the structure of the analysis subsystem. The priorities can be ranked by schedule (for instance, “this requirement will be serviced before that one”), by system(for example, “all requirements associated with system X will be serviced before those associated with other systems”), or by other attributes.

4.1.3.4. Trade-offs

At times, the goals and requirements of analysis may conflict. For example, one goal of analysis is to minimize the impact of analysis on the performance and resource consumption of the target system. However, the requirement to maintain logs for legal purposes often conflicts with this goal. In another example, the system overhead required to maintain accountability may affect the analyzer's ability to identify intrusions quickly enough tosupport active response.

4.1.4. Detecting Intrusions

To understand the nature of intrusion detection analysis, you should consider the full range of intrusion analysis available to customers, starting with those used in older systems. Although the focus here is on techniques suitable for automation, consider the full spectrum of discovery techniques for security intrusions and other violations of policy.

4.1.4.1. The Human Detector

Humans (“wetware” or “carbon units”) are the most obvious and traditionally the most common source of intrusion information. A system manager may report that a machine is acting funny, or a user may report finding evidence of unauthorized activity on a system. Unfortunately, this approach is of extremely limited value because most incidents gounnoticed at sites where no intrusion detection systems are in place. For instance, one early study showed that over a period of time in which a prototype intrusion detectionsystem detected several hundred intrusions, only 20f those were detected by the humans charged with performing manual intrusion detection.

4.1.4.2. External Events

Events external to the computer system often trigger suspicion of potential intrusion. These events include hiring and firing (especially of key personnel), reports of anomalies (such as sudden unexplained affluence of employees who work on critical systems), results of security penetration tests, and discovery of missing goods or information. These events are sometimes tracked as part of a traditional corporate fraud detection or loss control program.

News coverage or warnings posted to the Internet about particular classes of attacksalso trigger suspicion of potential intrusion. This information appears to encourage the installation or use of antivirus tools.

4.1.4.3. Precursors to Intrusion

Next are the signs of intrusion that come from the victim systems. The first sign isevidence of an intruder having primed the system for future attack, which includes signs of trojan horse placement (that is, tampered system files) and unauthorized accountadditions to password files or trusted host configuration files (such as /etc/.rhosts in UNIX systems). These examples were the first symptoms of security problems targeted by early security tools such as COPS.

4.1.4.4. Artifacts of Intrusion

As precursors to intrusion alert customers to likely incidents, so do those indicators left in the wake of intrusions. These artifacts, evidence of past intrusions, can be reliable indicators of attack for both intrusion detection and vulnerability analysis. They can be discovered in real time (immediately upon the completion of the first step of an intrusion) or after the fact (during batch mode analysis of log files). Artifacts that are discovered immediately can be used by intrusion detection systems functioning in real time. Examples of artifacts of intrusions include password sniffer log files, unexplained system failures, and damaged files. Note that some artifacts are incidental to the intrusion (that is, they are not an intended goal of the intrusion) but excellent indicators, nevertheless, for detection purposes. Examples of such incidental outcomes include abnormal patterns of system resource use, discrepancies in accounting records (due to intruders deleting some, but not all,evidence of their activities), and unusual network traffic levels.

4.1.4.5. Observing Attack in Real Time

The final scenario for detecting misuse became possible with the advent and availability of intrusion detection systems--recognizing attacks by monitoring systems in real time. The ability to detect attacks by using these systems has opened the door to attack-blocking and other adaptive system responses to detected problems.

   

Contents Next >

Save to MyCKS

 

Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.

             
     

From the Brains at InformIT

|

Contact Us

|

Copyright, Terms & Conditions

|

Privacy Policy

 

© Copyright 2000 InformIT. All rights reserved.