Designing and Implementing a Family of Intrusion Detection Systems

Richard A. Kemmerer Reliable Software Group

Department of Computer ScienceUniversity of California, Santa Barbara

Santa Barbara, CA 93106 USA

kemm@cs.ucsb.edu

RTO-MP-IST-041 KN - 1

Intrusion detection systems (IDSs) analyze information about the activities performed in a computer system ornetwork, looking for evidence of malicious behavior. Attacks against a system manifest themselves in terms ofevents. These events can be of a different nature and level of granularity. For example, they may be representedby network packets, operating system calls, audit records produced by the operating system auditing facilities, orlog messages produced by applications. The goal of intrusion detection systems is to analyze one or more eventstreams and identify manifestations of attacks.

The intrusion detection community has developed a number of different tools that perform intrusion detectionin particular domains (e.g., hosts or networks), in specific environments (e.g., Windows NT or Solaris), and atdifferent levels of abstraction (e.g., kernel-level tools and alert correlation systems). These tools suffer from twomain limitations: they are developed ad hoc for certain types of domains and/or environments, and they are difficultto configure, extend, and control remotely.

In the specific case of signature-based intrusion detection systems the sensors are equipped with a number ofattack models that are matched against a stream of incoming events. The attack models are described using an adhoc, domain-specific language (e.g., N-code, which is the language used by the Network Flight Recorder intrusiondetection system). Therefore, performing intrusion detection in a new environment requires the development ofboth a new system and a new attack modeling language. As intrusion detection is applied to new and previouslyunforeseen domains, this approach results in increased development effort.

Today’s network are not only heterogeneous, but also dynamic. Therefore, intrusion detection systems needto support mechanisms to dynamically change their configuration as the security state of the protected systemevolves. Most existing intrusion detection systems are initialized with a set of signatures at startup time. Updatingthe signature set requires stopping the IDS, adding new signatures, and then restarting execution. Some of thesesystems provide a way to enable/disable some of the available signatures, but few systems allow for the dynamicinclusion of new signatures at execution time. In addition, the ad hoc nature of existing IDSs does not allow one todynamically configure a running sensor so that a new event stream can be used as input for the security analysis.

Another limitation of existing IDSs is the relatively static configuration of responses. Normally it is possibleto choose only from a specific subset of possible responses. In addition, to our knowledge, none of the systemsallows one to associate a response with intermediate steps of an attack. This is a severe limitation, especially inthe case of distributed attacks carried out over a long time span.

Finally, the configuration of existing IDSs is mostly performed manually and at a very low level. This taskis particularly error-prone, especially if the intrusion detection systems are deployed across a very heterogeneousenvironment and with very different configurations.

This talk describes a framework for the development of intrusion detection systems, called STAT, that over-comes these limitations. The STAT framework includes a domain-independent attack modeling language and adomain-independent event processing analysis engine. The framework can be extended in a well-defined way tomatch new domains, new event sources, and new responses. The resulting set of applications is a software familywhose members share a number of features, including dynamic reconfigurability and a fine-grained control overa wide range of characteristics. The main advantage of this approach is the limited development effort and theincreased reuse that result from using an object-oriented framework and a component-based approach.

STAT is both unique and novel. First, STAT is the only known framework-based approach to the developmentof intrusion detection systems. Second, even though the use of frameworks to develop families of systems is awell-known approach, the STAT framework is novel in the fact that the framework extension process includes, asa by-product, the generation of an attack modeling language closely tailored to the target environment. This talkfocuses primarily on the STAT framework.

Paper presented at the RTO IST Symposium on “Adaptive Defence in Unclassified Networks”, held in Toulouse, France, 19 - 20 April 2004, and published in RTO-MP-IST-041.

Report Documentation Page Form ApprovedOMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.

1. REPORT DATE 01 NOV 2004

2. REPORT TYPE N/A

3. DATES COVERED -

4. TITLE AND SUBTITLE Designing and Implementing a Family of Intrusion Detection Systems

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Reliable Software Group Department of Computer Science University ofCalifornia, Santa Barbara Santa Barbara, CA 93106 USA

8. PERFORMING ORGANIZATIONREPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release, distribution unlimited

13. SUPPLEMENTARY NOTES See also ADM001845, Adaptive Defence in Unclassified Networks (La defense adaptative pour les reseauxnon classifies)., The original document contains color images.

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT

UU

18. NUMBEROF PAGES

56

19a. NAME OFRESPONSIBLE PERSON

a. REPORT unclassified

b. ABSTRACT unclassified

c. THIS PAGE unclassified

Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18

Designing and Implementing a Family of Intrusion Detection Systems

KN - 2 RTO-MP-IST-041

KN-1

Designing and ImplementingDesigning and ImplementingA Family of Intrusion Detection A Family of Intrusion Detection

SystemsSystemsRichard A. KemmererRichard A. Kemmerer

Reliable Software GroupReliable Software GroupComputer Science DepartmentComputer Science Department

University of California University of California Santa Barbara, CA 93106, USASanta Barbara, CA 93106, USA

http://http://www.cs.ucsb.edu/~rsg/STATwww.cs.ucsb.edu/~rsg/STAT//

STAT

KN-2

Intrusion DetectionIntrusion Detection

•• Analysis of the actions performed by users and applications Analysis of the actions performed by users and applications looking for evidence of malicious activitieslooking for evidence of malicious activities

•• Two techniquesTwo techniques–– Anomaly detectionAnomaly detection (statistics, profiles, specs) ((statistics, profiles, specs) (IDES, RST, ADAMIDES, RST, ADAM))

•• Detects previously unknown attacksDetects previously unknown attacks•• Difficult to configure (train), generates many false alarmsDifficult to configure (train), generates many false alarms

–– Misuse detectionMisuse detection (signature analysis) ((signature analysis) (NFR, Emerald, Snort, STATNFR, Emerald, Snort, STAT))•• Generates few false alarmsGenerates few false alarms•• Detects only known attacks, needs continuous updatingDetects only known attacks, needs continuous updating

•• Different domainsDifferent domains–– HostHost--basedbased–– ApplicationApplication--basedbased–– NetworkNetwork--based based

STAT

KN-3

Undesirable FormatUndesirable Formatfor an Intrusion Reportfor an Intrusion Report

STAT

KN-4

Intrusion DetectionIntrusion Detection

•• Intrusion detection is traditionally based on analysis of lowIntrusion detection is traditionally based on analysis of low--level events: network packets, system calls, audit recordslevel events: network packets, system calls, audit records

•• Intrusion detection has evolved in several waysIntrusion detection has evolved in several ways–– New analysis techniquesNew analysis techniques–– Multiple event sources, possibly introducing distributionMultiple event sources, possibly introducing distribution–– Abstraction: fusion/correlation of highAbstraction: fusion/correlation of high--level events, e.g., alertslevel events, e.g., alerts

•• Monitor and surveillance functionality always/still based on Monitor and surveillance functionality always/still based on sensorssensors

STAT

KN-5

Intrusion Detection Intrusion Detection Sensor LimitationsSensor Limitations

•• Sensors are developed in an ad hoc fashion to match Sensors are developed in an ad hoc fashion to match specific environments/domains/event sourcesspecific environments/domains/event sources

•• Sensors are hard to configureSensors are hard to configure•• Sensors are hard to controlSensors are hard to control•• Sensors are hard to extendSensors are hard to extend•• Configuration/control/extension is mostly executed staticallyConfiguration/control/extension is mostly executed statically•• Configuration is mostly done manuallyConfiguration is mostly done manually•• Identifying Identifying ““meaningfulmeaningful”” sensor configurations can be difficultsensor configurations can be difficult•• Number of sensors that can be easily managed is smallNumber of sensors that can be easily managed is small

STAT

KN-6

Solution:Solution:A Web of SensorsA Web of Sensors

•• Set of heterogeneous sensors that provide intrusion Set of heterogeneous sensors that provide intrusion detection functionality within a protected networkdetection functionality within a protected network–– STAT FrameworkSTAT Framework–– STATL and the STAT coreSTATL and the STAT core

•• Sensors controlled, coordinated, and configured by means of Sensors controlled, coordinated, and configured by means of a distributed infrastructurea distributed infrastructure–– MetaSTATMetaSTAT

•• Explicit modeling of component dependencies and current Explicit modeling of component dependencies and current sensor configuration supports automated sensor configuration supports automated ““meaningfulmeaningful””reconfigurationsreconfigurations

STAT

KN-7

A Web Of SensorsA Web Of Sensors

Module Database

Sensor Database

AlertDatabase

Sensor

Proxy

MetaSTAT

STAT

KN-8

OutlineOutline

•• STAT and STAT FrameworkSTAT and STAT Framework•• STAT Extension ProcessSTAT Extension Process•• MetaSTATMetaSTAT

STAT

KN-9

The STAT FrameworkThe STAT Framework

•• ObjectObject--Oriented framework for the development of intrusion Oriented framework for the development of intrusion detection sensorsdetection sensors

•• Based on the State Transition Analysis TechniqueBased on the State Transition Analysis Technique•• Provides a domainProvides a domain--independent attack modeling language, independent attack modeling language,

called STATLcalled STATL•• Provides a Provides a ““corecore”” domaindomain--independent event processing independent event processing

analysis engine that implements the STATL semanticsanalysis engine that implements the STATL semantics•• Supports a wellSupports a well--defined extension process defined extension process •• Supports flexible and dynamic response mechanismsSupports flexible and dynamic response mechanisms•• Provides a communication and control infrastructureProvides a communication and control infrastructure

STAT

KN-10

Set of IDS ApplicationsSet of IDS Applicationsis a Software Familyis a Software Family

•• A number of STATA number of STAT--based sensors have been developed based sensors have been developed leveraging the frameworkleveraging the framework

•• The result is a The result is a ““software familysoftware family”” whose members share a whose members share a number of featuresnumber of features–– Dynamic reconfigurationDynamic reconfiguration–– FineFine--grained control (response, scenarios)grained control (response, scenarios)–– Attack specification languageAttack specification language

•• Limited development effortLimited development effort•• High level of reuseHigh level of reuse

STAT

KN-11

State Transition State Transition Analysis TechniqueAnalysis Technique

•• STAT models penetrations as a sequence of state transitionsSTAT models penetrations as a sequence of state transitions•• Represents only key activities that lead from an initial safe Represents only key activities that lead from an initial safe

state to a final compromised statestate to a final compromised state–– Signature ActionsSignature Actions–– State AssertionsState Assertions

STAT

KN-12

State Transition DiagramsState Transition Diagrams

Attacker Attacker illicitly gainsillicitly gains

more privilegesmore privileges

Attacker hasAttacker haslimited limited

privilegesprivileges

state assertionsstate assertions

initialinitialstatestate

signature actionssignature actionscompromisedcompromised

statestate

STAT

KN-13

USTAT exampleUSTAT exampleftpftp--writewrite

•• ExploitExploit–– use ftp to create .use ftp to create .rhostsrhosts file in worldfile in world--writable ftp home directorywritable ftp home directory–– rlogin using bogus .rlogin using bogus .rhostsrhosts filefile

S0

create_file read_rhosts

S3S2

login

S1

STAT

KN-14

STATLSTATL

•• A STATL specification is the description of a complete attack A STATL specification is the description of a complete attack scenario (a signature) in terms of states and transitionsscenario (a signature) in terms of states and transitions

•• DomainDomain--independent languageindependent language–– Extensions for Extensions for

•• IP networksIP networks•• Solaris BSMSolaris BSM•• WinNT event logging facilityWinNT event logging facility•• Apache event logsApache event logs•• SyslogSyslog facilityfacility•• IDMEF AlertsIDMEF Alerts

•• Parameterized descriptionsParameterized descriptions–– Generic attacks customizable by installation or policyGeneric attacks customizable by installation or policy

STAT

KN-15

STATL Basic AbstractionsSTATL Basic Abstractions

•• ScenariosScenarios–– StatesStates–– Transitions (consuming, Transitions (consuming, nonconsumingnonconsuming, unwinding), unwinding)–– Signature actionsSignature actions–– AssertionsAssertions–– Global environmentGlobal environment–– Local environmentLocal environment–– Code blocksCode blocks

•• EventsEvents–– Defined as trees of generic events encapsulating domainDefined as trees of generic events encapsulating domain--specific specific

opaque eventsopaque events

•• TimersTimers

STAT

KN-16

USTAT exampleUSTAT exampleftpftp--writewrite

•• ExploitExploit–– use ftp to create .use ftp to create .rhostsrhosts file in worldfile in world--writable ftp home directorywritable ftp home directory–– rlogin using bogus .rlogin using bogus .rhostsrhosts filefile

S0

create_file read_rhosts

S3S2

login

S1

STAT

KN-17

ftpftp--write in STATLwrite in STATL

use ustat;

scenario ftp_write{

int user, pid, inode;string objname;

initial state s0 { }

transition create_file (s0 -> s1) nonconsuming{

[WRITE w] : (w.euid != 0) && (w.owner != w.ruid){

inode = w.inode;objname = w.objname;

}}

state s1 { }

transition login (s1 -> s2) nonconsuming{

[EXECUTE e] : match_name(e.objname, "login"){

user = e.ruid;pid = e.pid;

}}

state s2 { }

transition read_rhosts (s2 -> s3) consuming{

[READ r] : (r.pid == pid) && (r.inode == inode)}

state s3{

{string username = userid2name(user);log("%d: by user %s using %s", user, username, objname);

}}

}

STAT

KN-18

NetSTATNetSTAT exampleexampleUDPUDP--racerace

s1

ClientRequest

s3

s2

s5s4ServerReply

SpoofedReply1

SpoofedReply2

STAT

KN-19

UDPUDP--race in STATLrace in STATLtransition ClientRequest (S1 -> S2) nonconsuming{

[IPDatagram d1 [UDPDatagram u1]]<* ENDPOINT_PORTS a_c.interface, a_s.interface *> :(d1.src == a_c) && (d1.dst == a_s) && (u1.dst == x.port)

{request_ip_src = d1.src;request_ip_dst = d1.dst;request_udp_src = u1.src;request_udp_dst = u1.dst;

}}

transition ServerReply (S2 -> S4) consuming{

[IPDatagram d2 [UDPDatagram u2]]<* ENDPOINT_PORTS a_s.interface, a_c.interface *> :(d2.src == request_ip_dst) &&(d2.dst == request_ip_src) &&(u2.src == request_udp_dst) &&(u2.dst == request_udp_src)

}

action SpoofedReply{

[Message m2 [IPDatagram d2 [UDPDatagram u2]]]<* ENDPOINT_PORTS i_r, a_c.interface *><* CONSTRAINT ! exists_detached_path(m2.src, d2.src.interface) *> :

(d2.src == request_ip_dst) &&(d2.dst == request_ip_src) &&(u2.dst == request_udp_src) &&(u2.src == request_udp_dst)

}

transition SpoofedReply1 (S2 -> S3) consuming { SpoofedReply }

transition SpoofedReply2 (S4 -> S5) consuming { SpoofedReply }}

use netstat;scenario UDP_race{

Host server, racer;Service x;IPAddress a_s, a_c;Interface i_r;

IPAddress request_ip_src, request_ip_dst;Port request_udp_src, request_udp_dst;

<* CONSTRAINT( server in Network.hosts) &&(x in server.services) &&(x.protocol == "UDP”) &&(x.authentication == "IPaddress”) &&(a_s in x.ipAddresses) &&(a_c in x.trustedAddr) &&(a_c.interface in ProtectedNetwork.interfaces) &&(racer in Network.hosts) &&(racer != server) &&! (a_c in racer.ipAddresses) &&i_r in racer.interfaces

*>

state S3 { { log("compromised"); } }

state S5 { { log("under attack"); } }

STAT

KN-20

STATL Execution ModelSTATL Execution Model

•• A STATL scenario has a runtime representation in terms ofA STATL scenario has a runtime representation in terms of–– Prototype (global environment and STD definition)Prototype (global environment and STD definition)–– Instances (local environment, occurrence of an attack) Instances (local environment, occurrence of an attack)

•• Event matching and assertions determine which enabled Event matching and assertions determine which enabled transitions fire transitions fire

•• Scenario evolution determined by transition typeScenario evolution determined by transition type–– NonconsumingNonconsuming: New instance in new state : New instance in new state and and current instance stays current instance stays

in previous statein previous state–– ConsumingConsuming: Current instance changes its state: Current instance changes its state–– UnwindingUnwinding: Backtracking to ancestor instance, possibly removing a : Backtracking to ancestor instance, possibly removing a

subtree of the instance treesubtree of the instance tree

STAT

KN-21

The STAT Core ModuleThe STAT Core Module

•• Implements STATL basic Implements STATL basic abstractionsabstractions–– ScenarioScenario

•• StateState•• Transitions (consuming, nonTransitions (consuming, non--

consuming, unwinding)consuming, unwinding)•• Signature actionsSignature actions•• AssertionsAssertions•• Global environmentGlobal environment•• Local environmentLocal environment•• Code fragmentsCode fragments

–– EventsEvents–– TimersTimers–– Synthetic events

•• Defines general semanticsDefines general semantics–– Event matchingEvent matching–– Scenario processingScenario processing–– UnwindingUnwinding

Synthetic events

STAT

KN-22

STAT Extension ProcessSTAT Extension Process

•• STATL language and the core analysis engine are both STATL language and the core analysis engine are both extended to deal with a specific domain (host, network, extended to deal with a specific domain (host, network, application), event stream, or platformapplication), event stream, or platform

•• Can be dynamically extended to build a STATCan be dynamically extended to build a STAT--based sensorbased sensor–– Language extensions Language extensions –– Event providersEvent providers–– Scenario Scenario pluginsplugins–– Responses modulesResponses modules

•• Extensions contain data structures and code to operate on Extensions contain data structures and code to operate on the data structuresthe data structures

STAT

KN-23

STAT Extension Process STAT Extension Process Uses a Common FormatUses a Common Format

•• A common extension format: A common extension format: –– Saves a considerable amount of development timeSaves a considerable amount of development time–– Produces more reliable librariesProduces more reliable libraries–– Allows for interchangeable event producers/consumersAllows for interchangeable event producers/consumers

•• Uses C++ class hierarchyUses C++ class hierarchy–– Create, destroy, clone, dump, restore, type managementCreate, destroy, clone, dump, restore, type management

•• Subclass STAT framework C++ root classes:Subclass STAT framework C++ root classes:–– STAT_EventSTAT_Event–– STAT_TypeSTAT_Type–– STAT_ProviderSTAT_Provider–– STAT_ScenarioSTAT_Scenario–– STAT_ResponseSTAT_Response

STAT

KN-24

Language ExtensionLanguage Extension

•• Set of events and types that characterize the entities of a Set of events and types that characterize the entities of a particular domainparticular domain

•• All event types defined as subclasses of STAT_Event All event types defined as subclasses of STAT_Event •• All other types defined as subclasses of STAT_TypeAll other types defined as subclasses of STAT_Type•• Defined events and types can be used in writing STATL Defined events and types can be used in writing STATL

scenarios for the specific domainscenarios for the specific domain

•• Compiled into dynamicallyCompiled into dynamically--linked libraries (.so or DLL files)linked libraries (.so or DLL files)•• Loaded into the core whenever needed by a scenarioLoaded into the core whenever needed by a scenario

STAT

KN-25

Attack ScenariosAttack Scenarios

•• Written in STATL with the relevant language extensionsWritten in STATL with the relevant language extensions•• Automatically translated into a subclass of the Automatically translated into a subclass of the

STAT_Scenario classSTAT_Scenario class•• Compiled into dynamicallyCompiled into dynamically--linked libraries, called scenario linked libraries, called scenario

pluginsplugins•• Loaded into the core as neededLoaded into the core as needed

STAT

KN-26

Event ProvidersEvent Providers

•• Collect events from the environment Collect events from the environment •• Create STAT events as defined in one or more language Create STAT events as defined in one or more language

extensionsextensions•• Insert the events in the event queue of the STAT coreInsert the events in the event queue of the STAT core•• Created by Created by subclassingsubclassing the STAT_Provider classthe STAT_Provider class•• MultiMulti--threaded runtime supports the processing of multiple threaded runtime supports the processing of multiple

event streams event streams

STAT

KN-27

Response ModulesResponse Modules

•• Contain libraries of actions that may be associated with the Contain libraries of actions that may be associated with the evolution of one or more scenariosevolution of one or more scenarios

•• Created by Created by subclassingsubclassing the STAT_Response classthe STAT_Response class•• Compiled into dynamicallyCompiled into dynamically--linked libraries linked libraries •• Loaded into STAT core when neededLoaded into STAT core when needed•• One or more actions can be associated with any state One or more actions can be associated with any state

defined in a loaded scenario defined in a loaded scenario pluginplugin

•• Example actionsExample actions–– write to filewrite to file–– reset a TCP connectionreset a TCP connection–– email to Network Security Officeremail to Network Security Officer

STAT

KN-28

STAT Framework Class STAT Framework Class HierarchyHierarchy

STAT_Object

STAT_ResponseSTAT_ScenarioSTAT_ProviderSTAT_Extension

STAT_Event STAT_Type

NetSniffer

RemoteBufferOverflow

UDPFlood PortScan NetResponse

PortUDP

IP TCP

IPAddress

Framework Classes

Extension Classes

STAT

KN-29

The Framework At WorkThe Framework At Work

•• Define a Language Extension, i.e., the events, types, and Define a Language Extension, i.e., the events, types, and predicates to be used in a specific domainpredicates to be used in a specific domain

•• Compile the extension into a Language Extension ModuleCompile the extension into a Language Extension Module•• Develop an Event Provider that transforms external data into Develop an Event Provider that transforms external data into

events as defined by one or more Language Extensionsevents as defined by one or more Language Extensions•• Compile the Event Provider into a dynamically linkable moduleCompile the Event Provider into a dynamically linkable module•• Develop STATL scenarios that use the events defined in one or Develop STATL scenarios that use the events defined in one or

more Language Extensionsmore Language Extensions•• Translate/compile the scenario into a Scenario Translate/compile the scenario into a Scenario PluginPlugin•• If necessary, develop response libraries to be used with the If necessary, develop response libraries to be used with the

scenarioscenario•• Link everything together (shake well) and run your sensorLink everything together (shake well) and run your sensor

STAT

KN-30

Creating a SensorCreating a Sensor

Attack ScenariosAttack Scenarios

Com

pila

tion

Com

pila

tion

STATLCore Language Application-

specificLanguageExtension

Intrusion DetectionSystem

Language

Application-specific

ExtensionModule

STATCore Module

IntrusionDetectionSensorScenario PluginsScenario Plugins

Com

pila

tion

Com

pila

tion

OffOff--line Processline Process RunRun--time Architecturetime Architecture

Com

pila

tion

Com

pila

tion

Event ProviderEvent Provider

STAT

KN-31

A Family Of SensorsA Family Of Sensors

•• USTAT (HostUSTAT (Host--based, Solaris, BSM auditing) based, Solaris, BSM auditing) •• NetSTATNetSTAT (Network(Network--based, Linux/Solaris, network traffic)based, Linux/Solaris, network traffic)•• WinSTATWinSTAT (Host(Host--based, Windows 2000, Security event logs)based, Windows 2000, Security event logs)•• LinSTATLinSTAT (Host(Host--based, Linux platform, Snare auditing)based, Linux platform, Snare auditing)•• WebSTATWebSTAT (Application(Application--based, UNIX, Apache logs)based, UNIX, Apache logs)•• AlertSTATAlertSTAT ((CorrelatorCorrelator, UNIX, IDMEF alerts), UNIX, IDMEF alerts)

STAT

KN-32

A Family Of SensorsA Family Of Sensors

•• LogSTATLogSTAT (Host(Host--based, UNIX OS, based, UNIX OS, syslogsyslog files)files)•• ftpSTATftpSTAT (Application(Application--based, extension of based, extension of LogSTATLogSTAT))•• aodvSTATaodvSTAT (Network(Network--based, Linux, Wireless Adbased, Linux, Wireless Ad--Hoc routing Hoc routing

protocol events)protocol events)•• AgletSTATAgletSTAT (Application(Application--based, Linux, Aglets mobile code based, Linux, Aglets mobile code

system)system)•• SnortSTATSnortSTAT (Application(Application--based, UNIX, Snort based, UNIX, Snort pluginplugin))•• SienaSTATSienaSTAT (WAN (WAN CorrelatorCorrelator, UNIX, SIENA events), UNIX, SIENA events)

STAT

KN-33

OK, You Can Develop OK, You Can Develop Your Own IDS, But...Your Own IDS, But...

•• What if one wants to change the configuration of a sensor at What if one wants to change the configuration of a sensor at run time, without having to stop the whole thing?run time, without having to stop the whole thing?

•• How can one be sure that all the pieces (extensions, How can one be sure that all the pieces (extensions, providers, scenarios) fit together?providers, scenarios) fit together?

•• What if one wants to control a multitude of sensors deployed What if one wants to control a multitude of sensors deployed throughout the network?throughout the network?

•• What if one wants to aggregate/fuse/correlate the alerts What if one wants to aggregate/fuse/correlate the alerts produced by the deployed sensors?produced by the deployed sensors?

STAT

KN-34

MetaSTATMetaSTAT

A communication and control infrastructure for STATA communication and control infrastructure for STAT--based based sensorssensors

•• CommSTATCommSTAT communication infrastructure allows for the communication infrastructure allows for the exchange of alerts and control commands over secure exchange of alerts and control commands over secure connectionsconnections

•• MetaSTATMetaSTAT Controller dispatches commands to the sensorsController dispatches commands to the sensors•• The STAT Proxy mediates communicationThe STAT Proxy mediates communication

–– Performs local module management (installation/configuration)Performs local module management (installation/configuration)–– Relays commands to sensors (loading/activation)Relays commands to sensors (loading/activation)

STAT

KN-35

MetaSTATMetaSTAT

•• MetaSTATMetaSTAT ConfiguratorConfigurator manages sensorsmanages sensors–– Database of available modules and corresponding dependenciesDatabase of available modules and corresponding dependencies–– Database of current sensor configurationsDatabase of current sensor configurations–– Allows the security officer to submit reconfiguration requestsAllows the security officer to submit reconfiguration requests–– Checks for the meaningfulness of reconfigurationChecks for the meaningfulness of reconfiguration

•• MetaSTATMetaSTAT Collector component aggregates sensor alerts in Collector component aggregates sensor alerts in a centralized database to support analysis and correlationa centralized database to support analysis and correlation

STAT

KN-36

MetaSTATMetaSTAT

STAT

KN-37

MetaSTATMetaSTAT: Main View: Main View

STAT

KN-38

MetaSTATMetaSTAT: Table View: Table View

STAT

KN-39

MetaSTATMetaSTAT: Tree View: Tree View

STAT

KN-40

Module DatabaseModule Database

•• Models and stores the information about Models and stores the information about –– The available The available modules modules (Language Extensions, Event Providers, (Language Extensions, Event Providers,

Attack Scenarios, and Responses)Attack Scenarios, and Responses)–– A number of A number of external componentsexternal components (e.g., a specific auditing facility)(e.g., a specific auditing facility)

•• Models and stores the dependencies between modules and Models and stores the dependencies between modules and componentscomponents–– Activation dependencies: Activation dependencies: Module A needs module B in order to be Module A needs module B in order to be

loaded and activatedloaded and activated–– Functional dependenciesFunctional dependencies: Module A needs module B in order to : Module A needs module B in order to

produce meaningful results or any results at allproduce meaningful results or any results at all

STAT

KN-41

Module ManagementModule Management

•• Each Module may be Each Module may be –– InstalledInstalled–– LoadedLoaded–– ActivatedActivated

•• A STAT sensor configuration is uniquely defined by a set of A STAT sensor configuration is uniquely defined by a set of installed/activated modules and available external installed/activated modules and available external componentscomponents

•• A configuration is A configuration is validvalid if all the activation dependencies are if all the activation dependencies are satisfiedsatisfied

•• A configuration is A configuration is meaningful meaningful if it is valid and all the if it is valid and all the functional dependencies are also satisfiedfunctional dependencies are also satisfied

STAT

KN-42

Module Database SchemaModule Database SchemaBinary

binmodule id

module idstate name

Response Function

module id1:1

module id

module id

module id

parameter filepathmodule id

module idfunction name

module id

module id

module id

N:1

N:1

N:1

1:N

1:N

1:N

module id1:N

Activation Dependency

module idinput typeinput id

module id

output idoutput type

module iddep module id

Functional Dependencymodule idexternal component id

Module Output

Module Input

Plugin Parameter

Plugin State

Dependency Information

typenameversion

description

module id

os platform

Module Index

STAT

KN-43

Sensor DatabaseSensor Database

•• Models and stores information about the current Models and stores information about the current configuration of a Web of Sensorsconfiguration of a Web of Sensors–– Installed modules (at each STAT Proxy site)Installed modules (at each STAT Proxy site)–– Loaded/Activated modules (in each STAT Sensor)Loaded/Activated modules (in each STAT Sensor)–– Available external components (at each host)Available external components (at each host)

STAT

KN-44

Sensor DatabaseSensor Database

sensor idsensor addresssensor port

Sensor IndexExternal Componentsensor idexternal component id

sensor idmodule idfunction namestate nameplugin idscenario prototype id

module type

sensor idmodule id

sensor idmodule id

module idsensor id

prototype idparameter filepath

Activated module

Activation information

<sensor id, module id>

1:N

sensor id

Activated response function

sensor id

1:N

Activated plugin

Installation Index

N:1

N:1

sensor id

sens

or id

N:1

STAT

KN-45

MetaSTATMetaSTAT ConfiguratorConfigurator

•• Intrusion Detection Administrator (IDA) requires highIntrusion Detection Administrator (IDA) requires high--level level reconfigurationreconfiguration

•• The The MetaSTATMetaSTAT ConfiguratorConfigurator–– Determines the required sensor configuration by examining the Determines the required sensor configuration by examining the

Module DatabaseModule Database–– Determines which modules are already available using the Sensor Determines which modules are already available using the Sensor

Database Database –– Determines the steps that are necessary to complete the Determines the steps that are necessary to complete the

reconfigurationreconfiguration•• The The MetaSTATMetaSTAT Controller sends the appropriate control Controller sends the appropriate control

messagesmessages•• STAT Proxies perform the installationSTAT Proxies perform the installation•• STAT Sensors reconfigure accordinglySTAT Sensors reconfigure accordingly

STAT

KN-46

ExampleExample

•• Intrusion Detection Administrator (IDA) wants to deploy FTP Intrusion Detection Administrator (IDA) wants to deploy FTP monitoring scenariosmonitoring scenarios

•• The Module Database is searched for suitable modulesThe Module Database is searched for suitable modules•• A subset is selectedA subset is selected•• The Module Database is examined for possible activation The Module Database is examined for possible activation

dependenciesdependencies•• The Module Database is searched for possible functional The Module Database is searched for possible functional

dependenciesdependencies•• Results trigger a new series of queriesResults trigger a new series of queries

STAT

KN-47

Dependency GraphDependency Graph

ftp FTP PROTOCOL

wu-ftp-bovf

lang ext event

scenario

ftp-protocol-verifyscenario

O

tcpipftplang extlang ext

A

A A

STREAM

netproc

network-drivertcpip

A

syslog

ftpd-quote-abuse

SYSLOG

syslog2

syslog syslog

win-app-event

winevent NTlogging

E

O

I

OOOlang ext

lang ext lang ext lang ext

scenario

event

event provider

event provider

lang ext

event

external component

external componentexternal componentsyslogd syslogd

AE

AE

A

I A

E

I

external component

event providerevent providersyslog1

STAT

KN-48

ExampleExample

•• ConfiguratorConfigurator determines the complete set of dependenciesdetermines the complete set of dependencies•• ConfiguratorConfigurator compares required modules with compares required modules with

installed/activated modules as stored in the Sensor installed/activated modules as stored in the Sensor DatabaseDatabase

•• ConfiguratorConfigurator compiles a compiles a deployment plandeployment plan•• Plan passed to the ControllerPlan passed to the Controller•• Controller ships messages to the ProxiesController ships messages to the Proxies•• Proxies perform installations and forward loading/activation Proxies perform installations and forward loading/activation

messages to the sensorsmessages to the sensors•• Detection begins...Detection begins...•• Possible custom responses are shipped/installed/activatedPossible custom responses are shipped/installed/activated

STAT

KN-49

HiHi--DRA ArchitectureDRA Architecture

Control

Notifications

Global Command and Control

Aggregator

Aggregator

STAT-based Sensors

Network Discovery and Verification

Notifications

Control

Network Sensors

univ.edu

digi.com

devel.gov

Aggregator

Aggregator

&

Coordination Server

Coordination Server

Coordination ServerCoordination Server

Coordination Server

Coordination Server

Coordination Server

Internet

Gateway

Attack ScenarioNetwork ModelDatabase

Network Traffic Slicer

STAT

KN-50

Advantages of the Advantages of the ApproachApproach

•• Fast development of intrusion detection sensor for different Fast development of intrusion detection sensor for different platforms/domainsplatforms/domains

•• Highly customizableHighly customizable•• Dynamic reDynamic re--configurabilityconfigurability•• Support for the management of a very large number of Support for the management of a very large number of

sensorssensors•• Separation of analysis mechanisms from domainSeparation of analysis mechanisms from domain--dependent dependent

elements and response functionalityelements and response functionality•• Modules can be reused across sensorsModules can be reused across sensors

STAT

KN-51

Advantages of the Advantages of the ApproachApproach

•• Multiple Language Extensions and Event Providers can be Multiple Language Extensions and Event Providers can be used within the same sensorused within the same sensor

•• Responses can be associated with intermediate steps in Responses can be associated with intermediate steps in attack scenariosattack scenarios

•• Support for alert collection and distributionSupport for alert collection and distribution•• ThirdThird--party tools can be easily integrated through STAT party tools can be easily integrated through STAT

ProxiesProxies

STAT

KN-52

People InvolvedPeople Involved

•• Richard KemmererRichard Kemmerer•• Giovanni Giovanni VignaVigna•• Steve Steve EckmannEckmann•• William Robertson William Robertson •• Fredrik Fredrik ValeurValeur•• JingyuJingyu ZhouZhou

•• Per Per BlixBlix, Jacob , Jacob CopenhaverCopenhaver, Marco , Marco CovaCova, Chris , Chris KruegelKruegel, , Darren Darren MutzMutz, , RahulRahul NirmalNirmal, Siva , Siva SankaridurgSankaridurg, , TirthendraTirthendraSanyalSanyal, , VishalVishal KherKher, , SunitaSunita VermaVerma

STAT

KN-53

PapersPapers

•• ““NetSTATNetSTAT a Networka Network--based Intrusion Detection Approach,based Intrusion Detection Approach,””14th Annual Computer Applications Conference, Dec. 199814th Annual Computer Applications Conference, Dec. 1998

•• ““NetSTATNetSTAT a Networka Network--based Intrusion Detectionbased Intrusion Detection System,System,””Journal of Computer Security, Vol. 7, No. 1, 1999Journal of Computer Security, Vol. 7, No. 1, 1999

•• ““The STAT Tool Suite,The STAT Tool Suite,”” DiscexDiscex 2000 , Jan. 20002000 , Jan. 2000•• ““Attack Languages,Attack Languages,”” Third Info. Third Info. SurvSurv. Workshop, Nov. 2000. Workshop, Nov. 2000•• ““STATL: An Attack Language for StateSTATL: An Attack Language for State--based Intrusion based Intrusion

Detection,Detection,”” Intrusion Detection and Prevention Workshop, Intrusion Detection and Prevention Workshop, Nov. 2000Nov. 2000

•• ““Designing a Web of HighlyDesigning a Web of Highly--Configurable Intrusion Detection Configurable Intrusion Detection Sensors,Sensors,”” RAID01, Oct. 2001RAID01, Oct. 2001

STAT

KN-54

PapersPapers

•• ““Automated Translation Between Attack Languages,Automated Translation Between Attack Languages,””RAID01, Oct. 2001RAID01, Oct. 2001

•• ““Intrusion DetectionIntrusion Detection””, IEEE Security and Privacy Magazine, , IEEE Security and Privacy Magazine, April 2002April 2002

•• ““StatefulStateful Intrusion Detection for HighIntrusion Detection for High--Speed NetworksSpeed Networks””, IEEE , IEEE Symposium on Security and Privacy, May 2002Symposium on Security and Privacy, May 2002

•• ““STATL: An Attack Language for StateSTATL: An Attack Language for State--based Intrusion based Intrusion Detection,Detection,”” Journal of Computer Security, 2002Journal of Computer Security, 2002

•• ““Designing a Family of Intrusion Detection Sensor,Designing a Family of Intrusion Detection Sensor,”” ESEC ESEC 2003, Oct. 20032003, Oct. 2003

•• ““A A StatefulStateful Intrusion Detection System for WorldIntrusion Detection System for World--Wide Web Wide Web Servers,Servers,”” ACSAC 14, Dec. 2003ACSAC 14, Dec. 2003