Policy Management for Networkbased Intrusion Detection and Prevention

Yao-Min Chen and Yanyan Yang {yao-min.chen, yanyan.yang}@watchguard.com WatchGuard Technologies, INC.

Abstract Intrusion detection and prevention systems are becoming an essential part of network infrastructure. They provide the ability to detect intrusion signatures or discover abnormal behaviors, and thus trigger actions. The actions are performed to preempt ongoing attacks as well as to prevent future intrusions. In the past, intrusion detection technology is mainly deployed as sensors that passively monitor traffic to detect symptoms that indicate attacks or their prelude. However, recent Internet worms and distributed denial-of-service attacks have shown that such passive detection is not timely enough in coping with network-based attacks. Thus, the recent trend is to integrate detection and prevention technologies into security firewalls, and deploy the technologies as active components in the network infrastructure. This poses a new challenge for network operation and policy management. The objective of this paper is to provide a framework for managing related policies in an enterprise-networking environment. Specifically, we propose a framework called Attack-Response Matrix (ARM), to integrate intrusion analysis with traffic enforcement for security purposes. ARM describes the mapping from intrusion types to traftic enforcement actions. It allows policies to dictate what actions to take on what types or stages of attacks. It is intuitive, and introduces a paradigm shift from flat detection rules to a structural representation that better describes an intrusion prevention system (IPS). It can be integrated with the framework of policy-based management, using policy decision points (i.e. PDP) and policy enforcement points (i.e. PEP), to configure, enforce, update and monitor intrusion prevention devices in the network. In the paper, we also point out related research issues, such as the chaining of prevention actions and the selfcorrection of traffic enforcement policies.

-219-

Introduction
Intrusion detection and prevention is becoming a basic firewall function Existing policy management framework is mainly for intrusion detection sensors, not intrusion prevention systems (IPS) Network operations and management needs to support IPS policies . . Talk Outline
,
'

'-

'

Architectural abstraction for'lPS

- Attack-Response Matrix (ARM) to describe traffic enforcement - Network design, policy management, and protocol requirement

..
TEEE NOMS 2004, Seoul
2

This paper addresses policy management for firewall devices integrated with intrusion prevention capabilities. While the underlying intrusion detection mechanisms are an important subject in its (ownmerit, our focus is rather on the operational policies and associated management issues. Allen etc. [AC99] and Bace [BAOO] provided comprehensive overview of intrusion detection technologies., For the purpose of this paper, one can regard firewall devices as policy-based traffic filters. But commonly they.are also equipped with networking and VPN capabilities including support for network address translation (NAT), virtual LAN (VLAN), routing protocols such.as OSPF and BGP,,and tunneling protocols such as IPSec, LZTP and PPTP. The devices provide abundant security functions such as public key exchange, user authentication, encryption, d'zcryption, and content inspection of the user traffic. They are often deployed as the security policy enforcers located at the edge of a network topology, but recently they are also used in the interior of enterprise networks to segment internal traffic. The devices are configured with security policies that dictate what traffic is allowed to pass, and what not, based on the inspected result of the packet traffic. The policies can be either locally configured by a human operator, or handed down from a central management station.

. ,. There is existing work in IETF [IE02] in terms of managing intrusion detection policies, but it has yet to address the need of intrusion prevention systems that perform active. traffic enforcement actions. This paper proposes a framework for the policy management of this,new generation of devices. It-is organized as follows. First we introduce the architectural abstraction of IPS that leads to the~proposedframework. Then we describe the proposal, called Attack-Response Matrix (ARM). In the last part ofthe paper we outline related network design, policy management, and protocol requirement.

-220-

Architectural Abstraction
IPS maps traffic classification and detection events to responses Traffic Classifier
- Generates classification results C

Intrusion Detection Engine

- Generate detection events E

Policy Moderator

- Mapping C and E to (fine-grained)

intrusion alerts or (coarse-grained) inlrusion types

....,............. . . . .~ . .......
~

~. ..... .~

~.~~~ .

f l X j . . .

Policy Enforcer
- Mapping alerts or intrusion types to responses R E E E NOMS 2004. Seoul
3

An IPS monitors passing network traffic and performs actions on the fly. As far as this paper is concerned, an IPS maps traffic classification and a detected event to a set of actions. That is, the policies define a function f C * E -7R, where C is the set oftraffic classification results, E the : set of intrusion detection events and R the set of responses, where a response is defined as a set of actions, The device implements the mapping by way of a traftic classifier, an intrusion detection engine, apolicy moderator, and apolicy enforcer. Each ofthe modules will be described in details shortly. Here we describe them in terms of their roles in the aforementioned mapping. The classifier generates the classification results, which are the elements of C. The detection engine generates detection events, which are the elements of E. The policy moderator maps the product of C and E (i.e.. C x E ) to an intermediate representation, which can be either fine-grained intrusion alerts (such as Snort alerts [R099]), or coarse-grained intrusion types. Finally the policy enforcer maps this intermediate representation into the responses, which are elements of R. In the figure, we show that the traffic classifier and intrusion detection engine monitor network traffic, and provide the processed results to the policy moderator. The policy moderator analyzes the inputs and generates one or more intrusion alerts, or an intrusion type, to the policy enforcer. The policy enforcer takes the input, generates response, and performs the associated actions on the traffic.

-221-

Traffic Classifier
,
*

Trackand extract - Flow spec (L2-L7 info) - Protocol state - Application context Flows can be classified according to network topology, network configuration, and access policy Firewall block - Firewall pass - Monitor by proxy - Redirect to VPN tunnels - etc
~

e
4

EEE NOMS 2004, Seoul

Traffic classifier is an ingrained part of firewall devices. Its role is to classify incoming traffic into traffic flows and apply the stored rules to the flow. T o fully implement the classifier for the intrusion prevention purpose, the classifier needs to look deep into the packets and extract headers as well as payload information. A tracking logic is needed to keep up-to-date with the protocol state such as TCP session states. Furthermore, packet payload content needs to be inspected to acquire the application-level context, such as HTTP context. Many of the inspections can incur expensive processing, and highperformance digital logic can be applied to speed up the processing. A key advantage in integrating intrusion prevention with the firewall technology is the fact that a firewall device acts as a gateway in the network infrastructure so it is aware of network topology, as well as the placement of :server and client hosts. Hence the device is conscious about what traffic is being blocked, and among the traffic allowed to pass, what to be trusted and what not. Therefore, the processing capability can be intelligently allocated and focused on the traffic presenting risk, so as to achieve higher efficiency in both detection rate and response time.

-222-

Intrusion Detection Engine

Detect symptoms early so preemptive actions can be taken Detect known Attacks
Signature-based detection rules - Stateful and context-aware pattern matching - Pattern normalization to detect polymorphic attacks
~

Detect unknown Attacks

- Protocolltraftic anomaly

detection - Learning period to perform site survey and establish domain-specific behavior profiles - Statistics collection and profile conformance checking - Alert correlation

IEEE NOMS 2004, Seoul

Underlying the intrusion detection engine is the various intrusion detection algorithms. This is still a rapid evolving area mainly because ofthe Internets dynamic environment and the frequent emergence of new types of attacks. A key point, from IPS point of view, is to perform early detection of intrusion symptoms and take prompt actions, so that an attacker or his machine-code agent cannot fully carry out the attack plan. It is thus ideal to perform actions at the reconnaissance or vulnerability scanning stage, before the true malicious payload is delivered. This is in contrast to the conventional NIDS approach that only passively monitors network traffic and waits for a human analyst or administrator to take actions. With regard to the detection algorithms, common intrusion detection mechanisms can be roughly categorized into the detection of known attacks and the detection of unknown attacks, which are respectively referred to as misuse intrusion detection and anomaly intrusion detection in the past [KU95, DD99, AC99, BAOO]. For known attacks, intrusion signatures can be compiled and installed on the devices to perform run-time signature matching [KU95, R@99]. Since normal traffic can sometimes match signatures and result in errors commonly known as false positives, stateful matching and context-aware matching are introduced to reduce such errors. An example is to perform signature comparison only on established flows; and another is to analyze whether a flow is from the client side or server side. Also note that, since an attack can be converted into many forms (so-called polymorphic attacks) that can exponentially increase the number of signatures for the devices to store, normalization is performed to map the various patterns to a standard format used for signature comparison. Detection of unknown attacks typically relies on checking whether there is protocol anomaly or traffic anomaly. To first establish what is normal, a learning period is used to conduct site survey to gather normal traffic and protocol patterns to record such patterns into domain-specific profiles. At run time, statistics are gathered and compared against the profiles to see ifthere is any deviation. When there is a real attack, the symptoms can occur in many places, from both signature-based rules and anomaly-based rules. Therefore, alert correlation [VSOI] can be performed to give a true picture of what attack is undertaking.

-223-

Policy Moderator
Input: - Flow spec, state, context
(from Traffic Classifier) - Firewall policies (pass, block, proxy, monitor, etc) - Intrusion detection event (from Detection Engine)

Example Intrusion types

- Admin Privilege Acquisition - User Privilege Acquisition - Unauthorized Information

Access
- Application-Level Attack

output:
- Intrusion Alerts, or - Intrusion Type (aggregated

alert)
IEEE NOMS 2004, Seoul

(e.g., Web CGI attack) DOSIDDOSAttacks (e.g., SYN Flood) Protocol Anomaly - WormiVirus - Reconnaissance (e.g., IPIport
~

The policy rnoderator combines information from the traffic classider and detection engine. The input from the classifier includes the flow specification, protocol state, and application context. The classifier also provides information about what the firewall policy dictates about the flow pass, block, use proxy for content filtering, or passively monitor the flow. The input from the detection engine is the detection result from either signature matching or anomaly analysis. Since the policy moderator needs to solicit many inputs and derive intelligent decisions, as well as keeping up to date with the latest intrusion types, it is suitable for software implementation. Various techniques such as expert systems, neural networks, and Bayesian reasoning algorithms can be applied besides the basic rule-based decision process. Note that, the decision making is done only when there is a detected event, which should be rare compared with normal traffic. When the events do become frequent, implying heavy attacks, the moderator can notify the policy enforcer to throttle the incoming traffic (using rate limiting or reducing TCP window size) so that enough time budget can be allocated to handle the attacks. The output of the moderator is the alert events to be sent to the policy enforcer. Since there ,can be thousands or more rules each generating its own alert, policies based on individual alert may be too fine-grained and difficult to manage. For example, current version of Snort [R09')] has more than 2000 alerts. To effectively manage, it is more efficient to aggregate the alerts into intrusion types. There are several ways to classify intrusions [NP89,KU95,LJ97]. We are inclined to classify based on the actions to be taken to disrupt the intrusions. However the ARM framework does not restrict the exact manner in which intrusions are classified. One example classification is to put intrusions into the following types: acquisition of administrator or user privileges; unauthorized obtaining of information stored in the network; application-level attacks such as web server attacks; denial of service attacks; protocol anomaly. attacks that are precursor to real (payload) attacks; worm and virus attacks that can trigger information leaking, destroy of s,ystems, or denial of service; and lastly reconnaissance such as using port scan to gather information for future use.

-224-

Policy Enforcer
Alert-to-response mapping Traffic Enforcement Actions
- Interface Actions: random packet

drop, rate limiting, and interface blocking - Nehvork Actions: packet or connection blocking, IPiURL blocking - Service Actions: TCPiUDP Service (Telnet, FTP, H T P , SNMP) filtering, NAT and pon forwarding . - File Actions: email attachment stripping, httpiftp file blocking Content Actions: protocol command blocking, HITP content filtering, etc
~

,,....

Network Mgmt Actions

-

Alarm
Log

E-mail or pager notification SNMPTrap HoneypoUHoneynet

IEEE NOMS 2004, Seoul

Policy enforcer maps intrusion alerts to responses, where the alerts can be in their raw, finegrained form (e.g., Snort alerts), or the aggregated form (i.e., intrusion type). A response is a list of actions including traffic enforcement actions and network management actions. Traffic enforcement actions can be roughly categorized into the following types: interface actions, network actions, service actions, file actions and content actions. Interface actions perform responses that are at the interface level and oblivious to the protocol attributes of traffic (e.g., IP addresses and TCP ports). For example, one can perform random packet discard or rate limiting on an interface upon detecting DDoS or flooding attacks. Network actions can discard packets or connections, as well as block or limit traffic based on link or network layer addresses, such as Ethernet, IP or web addresses. Service actions are based on the service types carried by the traffic, typically identifiable by TCP or UDP port numbers; Based on the services, packets are filtered, address-translated via NAT, or service port-translated via port forwarding. File actions are to perform passing, striping, or altering the files carried in traffic flows. Finally Content actions include examples such as to block specific pan ofcontent, or to replace content. For example, we can block or replace application protocol commands embedded in packet payloads. Network management actions typically include alarm generation, event logging, email or pager notification, and SNMP traps to propagate the events northbound to the operation center. More advanced actions are also possible, such as redirecting intrusive traffic to a honey pot or honey net, which are operational tools to engage and catch intruders.

-225-

Traffic Enforcement Actions

Action List
~~

Concurrent actions andlor

-- State machine-controlled

Activating Condition
-- Counters to track history of

~~

alerts or the intrusion type Thresholds to control firing of actions be triggered by a prior action (chaining of actions)

. Deactivating Condition
~

-- An action may alternatively

Use expiration timer to limit how long the actions are in effect . - Pull system back to steady state upon expiration - Determine value by system stability analysis

E E E NOMS 2004, Seoul

Traffic enforcement actions form a list indexed by an intrusion alert, or its aggregated form of the intrusion type. The list is configurable and can be implemented in a lookup table that uses alert ID or intrusion type ID as the index. Since there can be potentially thousands or more different alert, it is more efficient that the policy moderator aggregates alerts into intrusion types so that policy enforcer can use intrusion type as the index. The list may consist of multiple actions that can be activated together, or transit from one to another as the intrusion aggravates. For example, we may start from dropping packet, then blocking a source IP address, and finally transits into blocking the whole interface if the anack continues. Each of the actions can be fine-grain controlled using activating- and deactivating-conditions. An example of activating condition is to count the alerts so that real actions are applied to the traffic only after the number of its occurrences exceeds a threshold. In other words, we introduce an intermediate state for traffic where it is being conditionally passed (i.e., not just a simple pass or block decision). lfthe threshold is not reached within a certain time window, we can restore the system to the original state. In this way, we provide a damping mechanism to control system entry into the intrusion prevention state that can potentially disrupt normal traffic.
An example of deactivating condition is to use timers to keep track ofthe expiration time for an action. The timer continues to tick as long as no new intrusion is reported; otherwise the tirner is reset. In this way, the system can return to its normal state (steady state) after the intrusion activities disappear. The fine-grained control is a way to maintain system stability, and provides effective compensation against possible error due to false positives.

- 226 -

Attack-Response Matrix (ARM)

Description of traffic enforcement rules Per-service (HTTP, Mail, FTP, Telnet) matrix
- 2D array of "cells" - Each cell is a cross point of

an intrusion type and an action Each row describes a list of actions associated with an intrusion type, including optional transition between actions
9

IEEE NOMS 2004, Seoul

The intrusion responses can be determined a priori or retrieved on demand. They can be stored in matrices called attack-response matrices (ARMS), one for each service. Services herein referred are common network application services such as http, email, ftp, telnet etc. On a perservice basis we create a matrix dictating what list of actions to take for each intrusion type. For example, for worm or virus attacks we strip tile or sanitize content, and for administration and user privilege acquisition we drop the packet and block the source 1P address. An element in the matrix is called an active element if it specifies an action to be applied for an intrusion type. Other elements are called inactive. For each active element, we associate with activating and deactivating conditions. Specifically, we configure a threshold on how many alerts needed to trigger the action, and a response duration that defines how long should an action last once it is triggered, conditioned on no further intrusion detected. Determination ofthese parameters can be by a user, through network operation and management directives, or intelligently derived thorough system stability analysis. In a more advanced design the ARM matrices can be dynamic in the sense that the response associated with an attack can be stateful. That is, the responses are arranged in a state machine such that the response at a particular time f depends on the history of the responses that we have already applied to the attack. By doing this we can increase the intensity (scope) of the response if attacks continue and are not blocked by earlier response, or we decrease the intensity (scope) if system detects that the possibility of false alarms is becoming high and we want to relax the response actions. The state machine can be embedded into the ARM matrices by way of defining the transition from one cell to another.

'

-227-

Properties of ARM
*

Service-specific e.g., the HTTP service (or fine-grained Inbound HTTP and Outbound HTTP services) A row is empty if the intrusion type is not applicable to the service If a cell is active, it has an activating as well as deactivating condition for the action If there are multiple active cells on the same row, they can represent concurrent actions or an "action" state machine
~

El?NOMS 2004, Seoul

10

In this slide we use HTTP as an example to illustrate the properties of ARM. Recall that ARM should be defined on a per-service (e.g., HTTP) basis. For the HTTP service, certain intrusion types are applicable, while others not. So there should be no active actions applied to the latter intrusion types. For each applicable intrusion type, the corresponding row in the matrix defines the list of actions to be performed once this intrusion type is detected. The list may contain a single action. For example, consider a worm or virus attack where the malicious payload is embedded in a file, the action may be to strip off attachment files for a specified amount of time, after there is 1 0 more detected malicious content. Or the list may contain multiple actions. For 1 example, for reconnaissance or protocol anomaly, which are typically precursor to true attacks containing malicious payload, the action list contains dropping the packet, and blocking the source IP address from sending traffic to the internal network. In the figure, the cells having a check mark represent active actions. Within each cell that specifies an active action, we can also configure the activating and deactivating conditions, namely the triggering threshold and the response duration. Depending on the severity of the offense, these numbers vary between intrusion types and between prevention actions. For example, for serious offense such as the acquisition of administration privilege, we may want to trigger action!; at low threshold and make the actions last for a longer period of time.

-228 -

Network Design Issues

ARM matrices should be topology-aware
- ARM content varies according location in the network (stricter

towards edge; looser towards the core) - Network-wide coordination

ARM responses should be self-stabilizing

~

Effect of false positives is self-corrected

*w,

4 .

EEE NOMS 2004. Seoul

W?ltt;12d5

As intrusion prevention is integrated with firewall gateways, it becomes part of network infrastructure. This is in contrast to conventional intrusion detection sensors that are transparent to network configuration and traffic. Therefore, network-design issues related to this new infrastructure component need to be addressed. First o f all, depending on whether the gateway is located at the interior or boundary of the network, different ARM configurations may be needed. Furthermore, if multiple-layer network defenses are deployed, the ARM matrices at different layers may be different. Only a central management station has the visibility to all parts o f the network, and is aware of the full network topology and configuration. For this reason, a central policy management is needed to coordinate the different ARM-based devices in the network,. Secondly, since ARM responses actively and dynamically control network traffic, a glitch in the intrusion detection engine can lead to mistreatment oftraffic. False positives are a common glitch, which can lead to false responses. Since responses are timercontrolled, it is possible to devise self-correcting procedures so that normal traffic can resume within a finite amount o f time. This self-stabilizing requirement, in the context of network feedback control, is a research area worth active pursuit. The research will require both a model for false positives and a model on the impact to normal traffic when ARM responses are applied to the traffic.

-229-

Policy Management
*

*
*

PDP: Policy servers - Top-down propagation of ARM PEP: Appliances - Enforcement of ARM A policy protocol
- Client andserver - Server andserver

Both push and pull Push: new intrusion types, ARM configuration changes - Pull: on-demand download of ARM policies (new devices, network topology changes)
~

IEEE NOMS 2004. Scad

I2

What we propose is to use ARM matrices as the basis for the intrusion prevention policy management. The entities in the resulting management framework include the following. First, we should have policy servers (central management stations) acting as the policy decision points, and the firewall appliances, which are clients, acting as the policy enforcement points. This framework is needed for a couple of reasons. First, it is needed for scalability. We can have one or a set of similar policies that are deployed to multiple appliance clients. Second, it improves efficiency because appliances do not need to be equipped with the enormous resources required to store policies, detection rules, virus and worm signatures, etc. Third, it provides timely communication from central policy decision maker to the boxes deployed in the field. A push model can be implemented to perform run-time, to-the-minute, updates of policies and signatures. The framework would require a policy protocol for communication between servers and clients, as well as between the servers themselves if the servers are hierarchically configured. Existing IETF Intrusion Detection Exchange Protocol (IDXP) []E021 is mainly for coordinated intrusion detection, which lacks of intrusion prevention aspects of the policy management. It is possible to extend the protocol to incorporate ARM matrices. Another approach is to take advantage ofthe well-established SNMP protocol and define new MIB objects to include attributes of ARM. Qin etc. investigated integrating intrusion detection and network management [QLO2] utilizing existing MIB I1 variables for anomaly-based intrusion detection. More study is still needed to consider defining new MIB variables for the intrusion prevention purpose. The communications between the servers and clients should realize both push and pull models. In the push model, intrusion detection rules and actions are sent from a server to its clients whenever the central site updates policies, such as when new intrusion types are discovered. In the pull model, when the appliance receives traffic that has no a priori policy configured for it, it requests instant downloading of the policy for the traffic. The advantage of the pull model (but at the cost of longer latency) is that the there is no need to pre-configure many policies if the device does not pass the corresponding traffic.

-230-

Policy Protocol
Signaling and data exchange between policy management entities (PDPs and PEPs)
- Secure communication channel using IPSec or TLS (SSL) - Reliable transmission, mutual authentication, message

confidentiality, and message integrity

Data exchange format

~

Extend IETF IDIF to cover ARM objects, or

- Define new SNMP MIB objects for ARM

Data exchange content

- ARM configurations (PDP push or PEP

pull)

- Network status monitoring for policy validation and self correction

Standardization or de facto standards required

E E E NOMS 2004 Seoul
13

As allured to earlier, what is still missing from the community is a policy protocol that performs signaling and data exchange between the various management entities (PDPs and PEPs) for this framework. Naturally this communication needs to be secure, so utilizing an established secure transport mechanism such as IPSec (for the network layer) or TLSiSSL (for the session layer) may be advantageous. The resulting signaling and data exchange protocol needs to fulfill requirements such as reliable transmission of messages, mutual authentication between the entities, confidentiality during the transmission of messages, and integrity of the transmitted messages, just to name a few.
Currently the IETF Intrusion Detection Exchange Format working group only defines the data format and exchange protocol for the intrusion detection systems. This work needs to be extended to incorporate the various actions that can be applied to the traffic. ARM is a good candidate framework for the data format to be exchanged in the extended protocol, for at least the following reasons. First of all it is intuitive, describing mapping from intrusion type to the responding actions. Secondly, it is scaleable to new intrusion types and prevention actions, because new intrusion types and new actions can be easily added to the matrix in their corresponding dimensions. Thirdly, it is comprehensive in addressing action activation, action deactivation, action transition, and network feedback control. The ideal protocol should also provide an associated mechanism to monitor network status in order to sanity-check the policy configuration. If a policy leads to undesired network operational state, such information should be collected and propagated back to the policy server so corrections can be made. Before there is a standard, vendors may resort to proprietary or defacto protocols. ARM is also well suited for such purposes.

-231-

Conclusions
IPS traffic enforcement requires policies to describe actions based on intrusion types ARM is intuitive and effective for configuration, communication, monitoring, and analysis for IPS traffic enforcement ARM can be communicated over a policy or network management protocol to control appliance behaviors Research is needed in the behavior model for the control loop realized by ARM-based systems
IEEE NOMS 2004, Seoul
14

WJ'""

II

In summary, we believe intrusion prevention is already an essential part of network infrastructure. However, operations and management support for it is still missing from this community, which seems to be an area that we should actively pursue. This paper outlined a framework called Attack-Response Matrix, which can be used as basis for configuration, communication, monitoring and analysis for the intrusion prevention policy management. The framework provides fine-grained control to compensate false positives, but research on the behavior of the feedback loop is still needed.
References [AC99] J. Allen, A. Christie, W. Fithen, J. McHugh, J. Pickel, and E. Stoner, "Slare o rhePiaclice.ofl~msionDereclion f

TechnologieS', CMUISEI Technical Report CMUISEI-99-TR-028, 1999. IBA001 RG. Bace. "lnlrusion Delecrion': Macmillan Technology Publishing, 2000. [E021 M. Wootl and M. Erlinger "IntrusionDelecrion Mesage ExchangeRequirement~," IETFIIDWG draft-ietf-idwgrequirements-l O.txt, 2002. [R099] M. Roertch, "Snorr - Lighrweighr Intrusion Detecrionfor Nerwrkr." In Praceedings of Thirteenth Systems Administration Conference (USENIX LISA'99), 1999. [KU95] S . Kumar. "Classlficarion and Delecrion ofCompurerlntrusion~,," PhD thesis, Purdue University. August 1995. [DD99] H.Dehzr, M. Dacier, and A. Wepsi, " T o w r d s LI Tmonovp oflnrmion-Derection &rems," Computer Networks 31(8): 805-822, 1999. [VSOI] A. Valdt:s and K. Skinner, "ProbabilisticAlen Correlalion," in Proceedings of Recent Advances in Intrusion Detection (RAW), 2001 [NP89] P. G. Neumann and D.B. Parker, "A s u m m q o compurer rnimse rechniques" in Proceedings of the 12th f National Camputer Security Conference, 1989. [LJ97] U. Lindqvist and E. Jmsson, "How lo sysremalically cl as^$ computer securip intrusions," in Proceedingr of the IEEE Symposium on Security and Privacy, 1997. [QLO2] X. Qin, 'W. Lee, L. Lewis, J.B. Cahrera, "Inregraring lnmsion Detection andMIwork Managerwnr. in Proceedings of IEEE/IFIP NOMS, 2002.
I '

- 232