8/3/2019 00283931

1/16

Network Intrusion DetectionIntrusion detection is a new, retrofit approach for providing a sense ofsecurity in existing computers and data networks, while allowing themto operate in their current open mode.m m m m m m m m m m m

Biswanath Mukherjee, L. Todd Heberlein, and KarlN.Levitt

BIS WANATH MUKHER-JE E is an associate professorof computer science at theUniversity of Califomia,Davis.L. TODD HEBERLEIN is apostgraduate researcher inthe Computer ScienceDepartment at UC Davis.KARL. N . LEVIiT is aprofessor of computerscience at UCDavis.

IAuthentication is theprocess of determiningwhether or not an activityis a genuine one. It is aveiy desirable secur iv ser-vice and is an importantproperry of a secure net-work or computer system.Data and communica-tions integrjq can bedirectly built on authenti-cation mechanisms. Iden-tification is the process ofdetermining whethersomeone is truly theper-son who he says he is.

ntrusion detection is a new, retrofit approachfor providing a sense of security in existingcomputers and data networks,while allowingthem to operate in their current openmode.The goal of intrusion detection is to identi-f y ,preferably in real time, unauthorized use, misuse,and abuse of computer systems by both system insid-ers and external penetrators. The intrusion detec-tion problem is becoming a challenging task dueto the proliferationof heterogeneous computer net-works since the increased connectivity of comput-er systemsgives greater access o outsidersand makesit easier for intrud ers to avoid identification.Intrusion detection systems (IDSs) are based onthe beliefs hat an intruders behaviorwill be notice-ably different from that of a legitimate user andthat many unauthorized actions are detectable. Typ-ically, IDSs employ statistical anomaly and rule-based misuse models in order to detect intrusions.A number of prototype IDSs have been developedat several institutions, and some of them havealso been deployed on an experimentalbasis inoper-ational systems. In this paper, several host-based andnetwork-based IDSs are surveyed, and the char-acteristics of the corresponding systems are iden-tified. The host-based systems employ th e hostoperating systems audit trails as the main sourceof input to detect intrusive activity,while most of thenetwork-based IDSs build their detection mecha-nism on monitored network traffic, and some employhost audit trails as well. An outline of a statisticalanomaly detection algorithm employed in a typi-cal IDS is also included.Introduction

secure computer or network system should pro-A ide the following services-data confidentiality,data and communications integrity, and assuranceagainst denial-of-sewice [1,21.Data confidentiali-ty service protects data against unauthorized dis-closure. Release of a messages conten t to un-authorized users is a compromise which this ser-vice should protect. Data and communications ntegri-ty service is concerned with the accuracy, faith-fulness, non-corruptibility, and believability of

information transfer between peer entities (includ-ing computers connected by a network). This ser-vice must ensure correct operation of the systemhardware and firmware, and it should prot ectagainst unauthorized modification of dat a andlabels. Denial-of-service is a threat, and assur-ance against denial-of-service is an impor tantsecurity service [3].A denial- of-service conditionis said to exist whenever the system throughputfalls below a pre-established threshold, or whenaccess to a (remote) entity sunavailable.While suchattacks are not completely preventable, it is oftendesirable to reduce the probability of such attacksbelow some threshold.The conventional appro ach to secure a com-puter or network system is to build a protectiveshield around it. Outsiders who need to enterthe system must identify and authenticate them-selves- ommonly known as the Identification& Authentication (I&A) problem. Also, theshield should prevent leakage of informat ionfrom the protected domain to the outside world.Mandator y access control techniques (e.g. ,cryptography-based) might be used in the designof such secure systems [l].There are a number of limitations to this pre-vention-based approach for computer and net-work security, as outlined below.It is difficult, perhaps impossible, to build anuseful system which is absolutely secure. Th atis, the possible existence of some design flaw ina system with a large number of componentscannot be excluded. In addition, one cannotrule out the occurrence of administrative flawssuch as misconfiguration of equ ipment whenbought fromvendor, errors due to backward com-patibility of vendor equipment, and poor admin-istrative policies and practices.It is impractical to assume that the vast existing

infrastructure of (possibly nsecure) computer andnetwork sys tems will be scrapped in favor ofnew, secure systems since a tremendous invest-ment into our current infrastructure has alreadybeen made.The prevention-based security philosophy con-strainsausers activities; the current openmo de

26 0890-8044/94/$04.000 994IEEE IEEE Network MayiJune 1994

8/3/2019 00283931

2/16

of operation of most systems is regarded by manyto be a highly-useful environment for promot-ing user productivity.Crypto-based systems cannot defend againstlost or stolen keys, and against cracked passwords.Finally, a secure system can still be vulnerableto insiders misusing their privileges since it can-not fully guard against he insider threat, i.e., userswho abuse their privileges. (Systems withmandatory access controls, however, can reducethe risks of some kinds of insider attacks.)Around the mid-80s, an alternative approach,called intrusion detection, for providing a differ-ent no tion of security in compute r systems wasproposed [4]. The basic arguments in favor of thisconcept are those outlined in t he previous para-graph, namely, that not only abandoning theexisting and huge infra structure of possibly-insecure computer and network systems isimpossible, but also replacing them by totally-secure systems may not be feasible or cost effec-tive. That is, our computers a nd networks maybe under at tack; but an intrusion detect ion sys-tem based on a retrofit technology should be ableto dete ct such attacks, preferably in real time(i.e., when the attacks are in progress). Typically, anintrusion detection systems (IDS) alerts a systemsecurity officer (SSO) when it detects an attack.

This approach is gaining increasing momentumand acceptance, and a number of prototype IDSs- ome for a single host and others for severalhosts connected by a network- ave been builtat several institutions.Intrusion detection is defined to be the prob-lem of identifying individuals2who are using acomputer system without authorization (i.e.,crackers) and those who have legitimate accessto the system but are abusing their privileges (i.e.,the insider threat). Generally, an intrusionwould cause loss of confidentiality, loss of integri-ty, denial of resources, or unauth orized use ofresources. Some specific examples of intrusionsthat concern system administrators include:Unauthorized modifications of system files soas to permit unauthorized access to either sys-tem or user information.Unauthori zed access or modifications of userfiles/information.Unauthorized modifications of tables or othersystem informa tion in network compon ents(e.g., modifications of router tables in an inter-net to deny use of the network).Unauthorized use of computing resources(perhaps through the creation of unauthorizedaccounts or perhaps through the unauthorized useof existing accounts).Anexample ntrusion scenario s included at the endof this section.Detecting attacks requires the use of a modelof intrusion, namely, what should the IDS lookfor? Currently, two types of models are employedin IDSs. The first model hypothesizes its detectionupon the profile of a users (or a group of users) nor-mal behavior. It statistically analyzes parametersof t he users current session, compares them tothe profile representing the users normal behav-ior, and reports significant deviations to a SSO.Here , significant is defined as a threshold set bythe specific model or by the SSO. A typical IDSmay report th e Top Ten most suspicious

sessions to the SSO [5]. Because it catches ses-sions which are not normal, it is referred t o as ananomaly detection model.The second type of model bases its detection uponacomparisonof parameters of the userssession andthe users commands to a rule-base of techniquesused by attackers to penetrate a system. Attacksignatures (i.e., knownattackmethods) are what thismodel looks for in the users behavior. Since thismodel looks for patterns known to cause securityproblems, it is called a misuse detection model.A number of IDSs base their design on analyz-ing the host operating system (0S)s audit trails.Their examples include AT& Ts Computerwatch[6], TRWs Discovery [7,8] , Haystack Laborato-rys HAYSTACK system [ 5 ] ,SRI InternationalsIntrusion Detection Expert System (IDES) [9,10,111, Planning Research Corporations Informa-tion Security Officers Assistant (ISOA) [12, 131,Nation al Security Agencys Multics Intru sionDetection and Alerting System (MIDAS) [14],and Los Alamos National Laboratorys Wisdom& Sense (W&S) [ 1 5 ] and Network AnomalyDetection and Intrusion Reporter (NADIR) [16].Some of the basic algorithms employed in thesesystems include evaluation of a weighted multi-nomial function to detect deviations from normalbehavior, a covariance-matrix-based approach for

profiling normal behavior, and rule-based expert sys-tem approach to detect violations of security policy.Early IDS modelswere designed o monitor a sin-gle host. However, more recent models accom-moda te the monitoring of a number of hostsinterconnected by a network, e.g., ISOA, IDES, andUC Davis Network Security Monitor (NSM) andDistributed Int rusion Detection System (DIDS).Some of these systems (ISOA and IDES) transferthe monitored information (host audit trails)from the monitored hosts to a central site forprocessing. Other s (NSM, DIDS) monitor thenetwork traffic flow as well, as part of their intru-sion detection algorithms.AnExample Intrusion ScenarioA description of a real attack that occurred severalmonths ag o and was detected by our NetworkSecurity Monitor (NSM) [17] provides a goodexample of the types of attacks that occur regu-larly and must be detected. Pertinent facts includethe following:At least ten different computers were involved.The computers were managed by eight sets ofsystem administ rators distributed over sevendifferent sites, three states, and two countries.The attack exploited a number of different vul-nerabilities in a number of different computersystems.The attack took place in several stages over sev-eral days.1) The initial phase of the attack included: aseries of doorknob-rattling operations (namely,the use of common account-name/passwordcombinations to break-in) from COMPANY1 com,resulting in a successful break-in intoshark. C H O O L 2 .edu by exploiting a flaw;importing a Trojan login program fromomen. CHOOL3 edu and installing it in shark;and followed (on the next day) by a login fromrevir.SCHOOL1.edu~toshark.SCHOOL2.eduby the Trojan login program installed the previ-

.....Detectingattacksrequiresthe useof a modelof intrusion:what shouldthe IDSlook for?

2 Typically, these indiv idu-als are users, but they maybe hosts orprograms (incase of machine attacks)as well.

IEEE Network MayiJune 1994 27

8/3/2019 00283931

3/16

. . . B .

TheComputer-Watch audittrail analysistoolprovides asignificantamount ofaudit datareductionand limitedintrusion-detectioncapability.

ou s day. Apparently this attempt is merely testingif the Trojan still existed, and the intruder quickly2) The second element of the atta ck observedisanother login to sharkexploiting theTrojanloginprogram; however, this login comes from

b e a r . S C H O O L 4 . ed u. Although this attackcame from a different place, we ar e confidentthat this is the same person. This is based on twofacts: the Troja n horse was installed only thenight before; and the special password used was spe-cific to s h a r k , i.e., although other Trojan horseshave been discovered, he password selected and setthe night before is unique to s h a r k . The intrud-er thenuses s h a r kas aplatformfromwhich to attackother computer systems.3) The intruder exploits a hole in a . h o s t sfile on acomputer at awell-known school on the eastcoast, n e x t . SCHOOL6. ed u, and logs in asuucp. Once on nex t, the intruder executes a pro-gram granting him root privileges.4) As root, the i ntrud er is able to exploit thefact that anothe r computers file system,k ro p o t k i n . S C H O O L 7 . edu,ismountablebynext.Once the intruder is able to mount kr o p o t k i n ,he is able to examine and manipulate the file sys-tem without having to login to k r o p o t k i n . T heintruderinstallsanotherholeintok ro p o t k i n hatallows anyone to login to th e account t a m ifrom anywhere.5 ) As it turns out , the home directory for usert a m i on kro po k i n s the sameon twoother hostsat SCHOOL7, wombat . S C H O O L 7 . e d u a ndSCHOOL7 ed u. This fact g ives the in truderaccess to these machines as well. After moving aboutthe different SCHOOL7 computer systems, theintruder returns to s h a r k at SCHOOL2.6 . The intrude r next attacks a computer atSCHOOLS, called S C H O O L 5 . edu, by exploitinga Trojan login program previously installed.7. Using SCHOOL5 as a platform, the intruderattacks acomputer n Canada, p o l y v .C O U N T R Y 2 ,by exploiting a Trojan login program the re aswell. The i ntruder notices the system administra-tor currently active, and he exits po ly v.8. After extensively examining SCHOOLSSfile system, the intruder returns again to s h a r kat SCHOOL2.9. From s h a r k , the intruder breaks into acomputer at COMPANY2, p r e v i o u s . COMPA-N Y 2 . com, y exploit ing a + + in the . h o s t sfile for the accountme.The intruder, apparentlysat-isfied that this hole is still intact, returns back tos h a r k .10.The intruder againbreaks into poly v .com-T R Y 2 , and once again, his visit is short.11.Finally, after more than six hours of attack-ing various computer systems, the intruder exitssha rk to return to bea r . SCHOOL4 .edu.

logs off.

Host-Based Intrusion DetectionSystemsn early abstra ct model of a typical IDS wasA roposed in [4] . Since then, a number ofIDSs have been designed and deployed. A largenumber of IDSs employ their host OSs audittrail as the main source of input for detectingintrusions. Such systems are surveyed in this sec-

tion. For each IDS surveyed, we provide a noverview of the system, an outline of the systemsorganization, and a discussion on how the systemoperates.Coznpu erWatchOverview- he Computerwatch audit trail anal-ysis tool provides a significant amount of auditdata reduction and limited ntrusion-detectioncapa-bility [6]. The a mount of da ta viewed by an SSOis reduced while minimizing the loss of any infor-mational content. Data reduction is performed byproviding a mechanism for examining differentviewsof the audit data based on information relationships.Computerwatch, designed or the SystemV/MLSoperating system, was written to assist, but n otreplace, the SSO. The tool uses an expert systemapproach to summarize securitysensitiveevents andto apply rules to detect anomalous behavior. Italso provides a method for detailed analysis ofuser actions in order to track suspicious behavior.System Organization- udit trail records canbe analyzed either by the SSO interactively, or inbatch mode for later review, i.e., Computerwatchdoes no real-time analysis of events. There are threelevels of det ecti on statistics, namely, system,group, and user. Statistical information for sys-tem-wide events is provided in a summary report.Statistical information for user-based events isprovided by detection queries. Statist ical infor-mation for group-based events will be a laterenhancement [6].System Operation- omputerwatch providesa System Activity Summary Report for the SSO.This report contains summary information describ-ing the sec urity-releva nt activities occ urring onthe system. The report can indicate what types ofevents need closer examination. The SSO canalso perform his own analysis on the data. Expertsystem rules ar e used to detect anomalies or sim-ple security breaches. The rules a re fired when anequation is satisfied and when the rules in its pre-decessor list have been fired as well.The detection queries that are provided have beendesigned to assist the SSO in detecting simplesystem security breaches. These security breachesmay involve intrusion, disclosure, or integrity sub-version. The detection queri es display similarsecurity-re levant system activities as those tha tare described in the summary report , but at auser level. A SQL-ba sed query language is pro-vided to allow the SSO the capability to designcustom queries for intrusion detection.DiscoveryOverview- iscovery is an expert system tooldeveloped by TRW for detecting unauthorizedaccesses to its credit database [7,8].The Discoverysystem itself is writte n in COBO L, while theexpert system is written in an AI shell. Both runon IBM 3090s. Thei r goal is not to detect attackson the operating system, but to detect abuse s ofthe application, namely, the credit database.System Organization- RW runs a databasetha t contains t he credit histor ies of 133 millionconsumers. It is accessed more tha n 400,000times a day using 150,000 different access codes,

28 IEEE Network MayIJune 1994

8/3/2019 00283931

4/16

many of which are used by more than one person[7,8], but these numbers are expected to haveincreased by now. Th e datab ase is accessed inthre e ways: on-l ine access by TRW customerswho query consumers credit information, month-ly updates from accounts receivable data receivedonmagnetic ape, and modifications o correct errorsand inaccuracies. The Discovery system examineseach of these processes for unauthorized activity.Discovery is a statistical inference systemwhich looks for patterns in the input data. Its tar-gets include hackers, private invest igators, andcriminals. It is designed to detect three types ofundesired activity,namely, accesses by unauthorizedusers, unauthorized activities by authorized users,and invalid transactions. Processingof the audit datais performed in daily batches.System Operution- ) Customer Inquiries .Discoverys pr ocessing se quen ce is as follows.First, records with invalid formats are discarded.Valid records are thensorted andprocessedbyapat-tern recognition module. Inquiries are comparedto both the standard inquiry profile and a modelof illegitimate access. Access codes which are sus-pected of having been misused can also be flaggedfor tighter scrutiny.Th e system produces a user profile for eachcustomer by type-of-service and access method .These profiles are updated daily. The system gen-erates statistical patt erns based on the variablesin each inquiry (e.g., presen ce or absence of amiddle initial), access characteristics (e.g., time ofday), and characteristics of a credit record (e.g., geo-graphic area).Each variable has a t olerance, established byaccumulated patterns, within which the dailyactivity should fall. Thre e types of comparisonare made: each inquiry with the global pattern,each subscribers daily pattern with the globalpattern, and a subscribers patte rn with an indus-try pattern. The systems output is an exception datafile that lists the reasons fo r the exceptions, aswell as a report module. Investigative data is alsostored in a database and may be retrieved using aquery language.Initial production runs of the expert systemproduced large numbers of exceptions. Some ofthese were traced to variations due to time of day,etc. Heuristics based on analysis of actual casesare also being included in the expert system.2) Database Update. Several actors in the incom-ing data from customers a re measured by aCOBOL program. Data is entered into thedatabase only if statistical comparisons with pre-viously reported data are within a pre-definedtolerance. Data that is rejected by the statisticalanalysis is submitted to an expert system forfurther validation, and is entered into the databaseif passed by the expert system.3) Database Maintenance. The credit databasemay be modifiedby TRW operators to correct errorsand inaccuracies.Anexpert system designed o mon-itor the maintenance process performs statisticalanalysis of maintenance transactions and analyzeseach credit records maintenance history.Discovery has detected and isolated unauthorizedaccesses to the dat abase, masqueraders, andinvalid inqui ries. It has also provided investiga-tors with concise leads on ill egitimate activity.

Several of the deviations that have been discov-ered were found to be caused by customers chang-ing their access methods and systems. The expertsystem allows TRW to applya consistent securitypolicy in the update process. Abeneficial side-effectof the system is th e compilation of purchasingpatterns for each custo mer, which is useful formarketing purposes.HAYSTACKOverview- AYSTACK was initially designedto be a system for helping Air Force SecurityOfficers det ect misuse of Unisys 1100/2200mainframes used at Air Force Bases for routineunclassified but sensitive data processing [ 5 ] .HAYSTACK software reduces voluminous systemaudit trails to short summaries of user behaviors,anomalous events, and security incidents.Thisreduc-tion enables detection and investigation of intru-sions, particularly by insiders (authorized users).In addition to providing audit trail dat a reduc-tion, HAYSTACK attempts to detect severaltypes of intrusions: attempt ed break-ins, mas-querade att acks, penetration of the security sys-tem, leakage of information , denial of service,and malicious use. HAYSTACKS operatio n isbased on behavioral constrain ts imposed byofficial security policies and on models of typicalbehavior for user groups and individual users.System Organizution -The initial HAYSTACKsystem consisted of two program clusters, oneexecut ing on the Unisys 110012200 mainframe,and the oth er executing on a 386-based PC run-ning MS-DOS and the ORACLE database man-agement system [ 5 ] .Data is transferred from themainframe to t he PC by magnetic tape or elec-tronic file transfer over a communications line.Performancewise, it has been found tha t a typicaldays worth of audit data can be processed withina few hours on the PC.The preprocessor porti on of HAYSTACK(which runs on the mainframe) is a straightfor-ward COBOL application t hat selects appropri-ate audit trail records from the Unisys proprietaryaudit trail file as input, extracts the requi redinformation, and reformats it into a standardizedformat for processing on the PC. Software on thePCiswritten in C, embeddedSQL,and ORACLEtools. It processes and analyzes the audit trailfiles, helps the SSO maintain the databases thatunderlie HAYSTACK, and gives the SS O addi-tional support for his investigations.System Operution- AYSTACK helps anSSO detect intrusions (or misuse) in three differ-ent ways.1) Notable Events. HAYSTACK highlightsnotable single events for review. Events thatmodify the security state of the system are report-ed, along with explanatory messages. This includesboth successful and unsuccessful events thataffect access controls, user-ids, and group-ids.2) Special Monitoring. The SSO may tag particul ar security subjects and objects forspecial monitoring. This is analogous to settingan alarm to go off when a parti cul ar user-id isactive,or when a particular ile or program s accessed.This alarm may also increase th e amount ofreporting of the users activity.

.....MYSTACKsoftwarereducesvoluminoussystem audittrails toshortsummariesof userbehaviors,anomalousevents, andsecurityincidents.

~ ~

IEEE Network May/June 1994 29

8/3/2019 00283931

5/16

.....The overallgoal ofIDES is toprovide asystem-independentmechanismfor thereal- imedetectionsecurity

of

violations.

3) Statistical Analysis. HAYSTACK performstwo different kinds of statistical analysis. The firstkind of statistical analysis yields a set of suspi-cion quotients. These are measures of the degreeto which the users aggregate session behavior resem-blesone of the target intrusionswhichHAYSTACKis trying to detect.About two dozen features (behavioral mea-sures) of the users session are monitored on theUnisys system, including time of work, number offiles created, number of pages printed, etc. Givena list of the session features whose values wereoutside the expected ranges for the users securitygroup , plus the es timate d significance of eachfeature violation for detecting a target intrus ion,HAYSTACK computes a weighted multinomialsuspicionquotient which signifies how closely thatsession resembles a target intrusion for the userssecurity group. The suspicion quotie nt is there-fore a measure of the anomalousnessof thesession with respect to a particular weighting offeatures. HAYSTACK emphasizes that such sus-picions are not smoking guns, but are rat herhints or hunches to th e SSO that the session maywarrant fur the r investigation. Such a statisticalanomaly detection algorithm is treated in greaterdetail in the section on an intrusion det ectio nalgorithm case study later in this article.

The second kind of statistical analysis detectsvari-ation within a users behavior by looking for sig-nificant changes (t rends) in recent sessionscompared to previous sessions.Intrusion-DetectionExpert System [IDES)Overview- he Int rusion-Detection ExpertSystem (IDES) developed at SRI International isa comprehensive system that uses complex statis-tical methods to detect atypical behavior, as wellas an expert system that encodes known intrusionscenarios, known system vulnerabilities, and thesite-specific security policy [9-111.The overall goal of IDE S is to provide a sys-tem-independentmechanism for the real-time detec-tion of security violations. These violations can beinitiated by outsiders who attempt to break into asystem or by insiders who attempt to misuse theirprivileges. IDES runs indep endently on its ownsystem (currently a Sun workstation) and pro-cesses the audit d ata received from the systembeing monitored.System Organization -The IDES prototypeuses a subjects histo rical profile of activity todetermine whether its current behavior is normalwith respect to past or acceptable behavior. Subjectsare defined as users, remote hosts, or target systems.A profile is a descrip tion of a subjects normal(i.e., exp ected) behavior with respect to a set ofintrusion-detection measures. IDES monitorstarget system activity as it is recorded in auditrecords generat ed by the target system. Due tothe fact that these profiles are updated daily,IDES is able to adaptively learn a subjects behav-ior patterns; as users alter their behavior, the pro-files change o reflect he most recent activity. Ratherthan storing the tremendous amoun t of auditdata, the subject profiles keep only certain statis-tics such as frequency ables,means, and covariances.IDES also includes an expert-systemcomponentthat is able to describe suspicious behavior that is

independent of whether a user is deviating frompast behavior patterns.The expert system containsrules that describe suspicious behavior based onknowledge of past intrusions, known system vul-nerabilities, or the site-specific security policy.The IDES comprehensive system is consideredto be loosely coupled in the sense that th e deci-sionsmadebythe twocomponentsareindependent.While the twocomponents share the same source ofaudit records and produce similar reports, their inter-nal processing s done separately. The desired effectof combining these two separate components is acomplementary system in which each ap proachwill help to cover the limitations of the other.System Operation- he system has two majorcomponents as discussed below.1)The Statistical Anomaly D etector (IDEWSTAT)[ l l ] . n order to determine whether or not cur-rent activity is atypical, IDES/STAT uses a deduc-tive process based on statistics. Th e process iscontrolled by dynamically-adjustable paramete rstha t are specific to each subject. Audited activityis described by a vector of intrusion-detectionvariables that correspond to the measures record-ed in the profiles. As each audit record arrives,the relevant profiles are retrieved from the knowl-edge base and compared with the vector of intru-sion-detection variables. If the po int defined bythe vector of intrusion-detection variables is suffi-ciently far from the point defined by the expectedvalues, with respect to the historical covariancesfor thevariables stored in the profiles, then the recordis considered anomalous. The covariance-matrix-based approach, however, has turnedout to becom-pute-intensive, and recent versions of IDES havedropped the covariance-based computations [MI.The procedures are not only concerned withwhether an audit variable is out of range, but alsowith whether an audit variable is out of range rel-ative to the values of the ot her audit variables.IDES/STAT evaluates the tot al usage pattern,notjust how the subjectbehaveswith respect to eachmeasure considered singly.2 ) The Expert System. The I DES expert sys-tem will make attack decisionsbased on informationcontained in t he rule-base regarding knownattack scenarios , known system vulnerabilities,site-specific security information, and ex pectedsystem behavior. It will, however, be vulnerableto intrusion scenarios that are n ot described inthe knowledge base.The expert system component is a rule-based,for-ward-chaining system.A production-based expertsystem tool (PBEST) has been used to produce aworking system. The PBEST translator is used totranslate th e rule-base into C language code,which actually improves the performance of thesystem over using an inter preter. As the size ofthe rule-baseincreases, the processing imewill alsoincrease since he functions hat implement the rulesmust search longer lists.InformationSecurity OfficersAssistant[ISOA)Overview- he Information Security OfficersAssistant (ISOA) is a real-time security monitorimplemented on a UNIX-based workstation thatsuppor ts automated as well as interactive audittrail analysis [12, 131.This monitor provides a sys-

30 IEEE Network MayiJune 1994

8/3/2019 00283931

6/16

tem for the timely correlation and merging of dis-joint details into an assessment of the cu rrentsecurity status of users and hosts on a network.The audit records, which are indicators of actualevents, are correlated with known indicators (i.e.,expected events) organized in hierarchies of con-cern, or security status.ISO As analysis capabilities include both statis-tical as well as expert system components. Thesecomponents cooperate in th e automated exami-natio n of various concern levels of dat a analy-sis. As recognized indicators (sets of indicators)are matched, concern levels increase and the systembegins to analyze increasingly detailed classes ofaudit events for the user or host in question.System Organization-The monitoring of eventsthat do not constitute direct violation of the securi-ty policy requires a means to specifyexpected behav-ior on a user and host basis. The expected behaviorcan be represented in profiles that specify thresholdsas well as associated reliability factors for discreteevents. The observed events can then be comparedto expected measures, and deviations can be iden-tified by statistical checks of expected versus actualbehavior. ISOA profiles also include a historicalabstract of monitoredbehavior (e.g., arecordofho woften each threshold was violated in the past), andinferences hat the expert system has made about theuser. Hosts aswell as individual users are monitored.Events that cannot be monitored by examiningthresholdsmake it necessarytoeffect a higher-orderanalysis hat is geared towards correlatingand resolv-ing the meaning of diverse events. The expert sys-tem analysis component can specify the possiblerelationships and implied meaning of diverse eventsusing its rule-base. Where statistical measurescan quantify behavior, the rule-based analysiscomponent can answer conditional questionsbased on sets of events.System Operation- he underlying processingmodel of ISOA consists of a hierarchy of concernlevels constructed from indicators. Analysis is struc-tured around these indicators to build a globalview of the security status for each monit oreduser and host. The indicators allow modeling andidentification ofvarious classesof suspiciousbehav-ior, such as aggregator, imposter, misfeasor, etc.Two major classes of measures are defined: real-timeandsession.Thereal-time measurewequire imme-diate analysis,while session measures equire (at mini-mum) start-of-session and end-of-session analysis.ISOA supports two classes of anomaly detection:preliminary and secondary. Preliminary anomalydetection takes place during the collection of theaudit data (i.e., in real time). Predetermined eventstrigger an investigation of the current indicator orevent of interest. If further analysis is warranted, thecurrent parameters a re checked against the pro-filesfor real-timeviolations r deviationsfrom expect-ed behavior.Secondary anomalydetectionis nvoked at theendof a user login session or when required for resolu-tion. The current session statistics are checked againstthe profiles, and session exceptions are determined.When the expert systemis notified that the stateof indicators has changed significantly, t attemptsto resolve the meaning of the current state of indi-cators. This is done by evaluating the appropriate

subset of the overall rule-base, which consists of anumber of individual rules that relate variousindicator states with one anothe r and with estab-lished threat profiles.The end result of anomaly res-olution is presented t o the SSO in the form of agraphical alert, an advice, and an explanation asto why the current security level is appropriate.Multics Intrusion Defection and AlertingSystem (MIDAS)Overview- he Multics Intrusion Detection andAlerting System (MIDAS) is an expert systemwhichprovides real-time intrusion and misuse detectionfor the National Computer Security Centers net-worked mainframe, Dockmaster, a Honeywell DPS-8/70 Multics computer system [14].MIDAS has been developed to employ the basicconcept that statistical analysis of computer systemactivities can be used to characterize normal systemand user behavior. User o r system activity thatdeviates beyond certain bounds should then bedetectable.System Organization- IDAS consists of sev-eral distinct parts. Those implemented on Dock-master itself include t he command monitor , apreprocessor, and a network-interface daemon.Those that areinstalled on aseparate SymbolicsLispmachine include a statistical database, a MIDASknowledge base, and the user interface.The command monitor capt ures commandexecution data that is not aud ited by the Multicssystem, the preprocessor transforms Dockmasteraudit log entries into a canonical ormat, and the net-work-interface daemon controls communications.The statistical database records user and systemstatistics, the knowledge base consists of a repre-sentation of the current fact base and rule-base,and the user interface provides communicationbetween MIDAS and the SSO.An expert system utilizes a forward-chainingalgorithmwith four tiers (generations) of rules. Thefiring of some combinati on of rules in one tiercan cause the firing of a rule in the next tier. Thehigher the tier, the more specific the rules becomein regards to the possibility of attacks.MIDAS keeps user and system-wide statisticalprofiles that record the aggregation of monitoredsystem activity. The users (systems) current sessionprofile is compared to the historical profile to dete r-mine whether or not t he current activity is out-side two standard deviations.System Operation -The logical struct ure ofMIDAS revolves around the rules (heuristics)contained in the rule-base.There are currently hreedifferent types of rules which MIDAS employs toreview audit data.1)Immediate Attack.These rules examinea smallnumber of data items without using any kind ofstatistical information. They are intended to findonly those audita ble events that are, by them-selves, abnormal enough to raise suspicion.2) User Anomaly. These ru les use statisticalprofiles to detect when a users behavior profiledeviates from previously-observed behavior p at-terns. User profiles are updated at the end of auserssession if the behavior has changed significantly, andare maintained for each user throughout the lifeof the account.

B W B B B

MIDAShas beendevelopedto employthe basicconcept thatstat sticalanalysis ofcomputersystemactivitiescan beused tocharacterizenormalsystemand userbehavior.

IEEE Network MayiJune 1994 31

8/3/2019 00283931

7/16

. . . B .

Wisdom andSense is ananomalydetectionsystem thatoperates ona Unix (IBMplatformand analyzesaudit trailsfromVAX/VMShosts.

RTPC)

3) System State.These rules are similar to the useranomalyrules, but depictwhat is normal for the entiresystem, rather than for single users.Wisdom and SenseCverview- Wisdom and Sense(W&S)is an anoma-ly detection system developed at the Los AlamosNational Laboratory [151. It operates on a U N I X(IBM RT PC) platform and analyzes audit trails fromVAXiVMS hosts. It is an anomaly detection sys-tem which seeks to identify system usage patternswhich are different from historical norms. It can pro-cess audit trail records in real time, although it ishampered by the fact that the operating systemmay delay writing the audit records.The objectives of W &S are to detect intru-sions, malicious or er roneo us behavior by users,Trojan horses, and viruses. The system is basedon the presumption that such behavior is anomalousand could be detected by comparing audit dataproduced by them with that of routine operation.System Organization- & S is a statistical,rule-based system. One of its major features isthat it derives its own rule-base from audit data.It receives historical audit dat a from the ope rat-ing system and processes it into rules. These rulesare formedintoaforest (i.e.,asetoftrees). Therulesare human-readable, and thus the rule-base maybe supplemented or modified by a human expertto correct deficienciesand inconsistencies.The rulesdefine patterns of normal behavior in the system.A W& S rule-base may contain between I O 4 and10h ules, which take 6 to 8 bytes each, and can besearched in about 50 ms. A typical generat ion ofthe rule-base takes less than an hour on an inex-pensive workstation.W&S views the univer se as a collection ofevents, each represented by an audit record.Audit log records contain data about the execu-tion of individual processes. Each record consistsof a number of fieldswhich contain information suchas the invoker (user), the name of the process, itsprivileges, and system resources utilized.Data is viewed primarily as categorical , i.e.,any field in a record can take one of a number ofvalues. Categorical data is represented as charac-ter strings. Continuous data, such as CPU time, ismapped into a set of closed ranges, and thentreated as categorical data.System Operation- ) Rules. Rules consist of aleft-hand side (LHS),which specifies he conditionsunder which the rule applies; and a right-handside (RHS) (also referred to as the rules restriction),which defines what is considered normal underthese conditions. The absence of a rule meansthat everything is considered normal.The LHS could consist of field values or valueranges, values computed from a series of records(e.g, mean time between events), or subroutinesreturning a Boolean value. A given rule fires onlyif an audit record has fields whose values matchthe LHS and if any subroutines in the LHS returntrue.The RHS may take the form of a list ofacceptablecategorical values for a record field, a list ofacceptable ranges of a continuous field, and a listof user-defined functions. Each rule has a grade,which is a measure of its accuracy. Rules which

are more specific, or which represent frequently-occurringpatternswith lessvariability,are given bet-ter (i.e., higher) grades.2) Constructing he Rule-Base.The historical datais first condensed, and then processed throughthe rule-base generator, which builds the forest ofrule trees. At each level, the rule-base consists ofnodes designating fields, and nodes designatingacceptable values of each field. The rules are gen-eratedbyrepeatedlysort ingthedataandexaminingthe frequency of field values. The t ree is prunedas it is being built by using a number of pruningrules to limit its size.3) Audit Data Analysis. The Sense part of W &Sanalyzes an activity file using the rule forest. Itlooks at a record, finds the applicable rules, and com-putes a figure of merit (FOM) for each field and eachtransaction. A transactions FOM is the normal-ized sum of the grades of failed rules.Anumberof transactionsmaybegroupedto forma t hread . Each thre ad belongs to a thread classthat is defined by values of specific audit recordfields. Some of the thread classes that a re usedinclude: each user-terminal combination, eachprogram-user combination, and each privilege evel.A set of opera tions may be defined fo r eachthread class and carried out whenever a record inthe class is processed. A FOM is computed foreach thread as a time-decayed sum of the FOMsof its transactions. A transaction, or a thread, isconsidered anomalous if its FOM is above a pre-defined threshold.The Sense module also provides an interactiveinterface to the configuration settings, rule-basemaintenance routines, and analysis ools.W& S offersseveral aids to the task of explaining the meaningand cause of anomalous events. It has undergoneoperational testing and has detected interestinganomalies even in data originally thought to befree of such events.Other Related WorkAdditional related work can be found in the liter-ature. Some areworthmentioning even though theymay not fit in cleanly with our def inition of anintrusion detection system. Recall that an IDSperforms passive monitoring of computing resourceusage, without changing the systemsservices per se.The AT&T Dragons Ap pro ach -The AT&TBell Labs work [19, 201 deviates from the abovedefinition of an IDS because i t replaces standardservers by a variety of t rap programs that look forattacks. However, this approach is relevant becauseit can detect intruders; study the attackers strate-gies, tools, and techniques; and alert the SSOaccord-in g1 . Sp eci ic a11y , these proxy servers ar eimplemented on AT&T Bell Labs Internet secu-ritygatewayresearch. a t t .com.Exceptforsomeservers such as mail, FTP, and telnet, othe r ser-vices are replaced by dummy servers. (This is part-ly justified by the widespread existence of securityproblems in current Internet software [2 1 ] . )Some of these dummies are packet suckerswhile others are quite specialized. All such serverslog the incoming request, attempt to trace i t back(namely, employ counter-intelligence approachesto learn more about the source of the attack, e.g.,via reverse fingers), and try to distinguish betweenlegitimate users and outside attackers. These

32 IEEE Network MayiJune 1994

8/3/2019 00283931

8/16

tools have detected a variety of attacks from sim-pledoorknob-rattling (suchasguest ogin) othemoredetermined (e.g., forged NFS packets). Finally, aninteresting chronicle on how an attacke r is luredinto the machine and how his actions a re studiedcan be found in [20].Signature Analysis-Some generic approaches forrepresenting and detecting attack signatures havebeen reported [22-241. One of these methods [22]employs sequential rules that characterize a usersbehavior over time. A rulebase store s patte rns ofuser activity,e.g., a rulecan characterize the sequen-tial relat ionship betwee n security-relevant auditrecords. The rules can be static (based on securitypolicy) or dynamic (based on time-based induc-tive learning techniques). Anomalies are detectedwhenever a users activity deviates significantly fromthose specified in the rules. The main strength ofthis approach is that it allows adjacent securityeventsto be correlated.Clustering Technique s- any of the IDSs dis-cussed above rely on featu res of system and userbehavior as inputs to their analysis algorithms whichthen dete rmine the likelihood of an intrusion.The choice of these features is quite arbitrary andis based solelyon the experience of an expert. Averyrelevant problem, called clustering, is to det er-mine importa nt featur es to be used in an effec-tive ID S design. This approac h could be basedupon an investigationofthe experimentally-derivedeffectiveness of the features at classifying users asattackers and non-attackers [25,26].Network-Based IntrusionDetection SystemsISOA and IDESEarly IDS models were designed to support a singlehost. However, more recent models accommodatethe monitoring of a number of hosts interconnect-ed by a network, e.g., ISOA and IDES. These sys-tems (ISOA and IDES) transfer the monitoredinformation (host audit trails) from multiplemonitored hosts to a central site for processing.Theyemploy the same algorithmsas in the host-based sys-tems. They do not monitor any network traffic.Network Anomaly Detection andIntrusion Reporter (NADIR)Overview -NetworkAnomalyDetection and Intru-sion Reporter (NADIR ) is a misuse detectionsystem designed for Los Alamos National Labo-ratory (LANL)sIntegrated Computing Network(ICN) [16]. It is an automa ted expert system,which streamlines and supplements the manualaudit record review performed by the SSO.NADI R comp ares weekly network activity ofindividual users and the ICN as a whole, againstexpert rules that define security policy andimproper or suspicious behavior. It reports suspi-cious behavior o theSSO,and provides ools o allowthe SSO to perform followup investigations.System Organizcrtion- he ICN is LANLs maincomputer network. It se rves nearly 9,000 usersand includes computing equipment from super-

computers to terminals, each of which connect toan ICN port. An ICN port belongs to one of fourpartitions, each defined to oper ate at a certainsecurity level. Th at is, a computer can accessother computers in its partition or in partitions inlower (less secure) levels. The partitio ns arelinked via a system of dedicat ed service nodes,namely, Network Security Controller (NSC) thatprovides user authentication a nd access controlonICN; CommonFileSystem(CFS)that storesdatafrom each partition separately and guards againstusers in lower-partition machines accessing filesstored in higher-partition machines; and SecurityAssurance Machine (SAM) that authenticatesand records all attempt s to down-partition fileswithin CFS.NSC, CFS, and SAM send raw audit records inhome-grown format to NADIR, which is runon a SUN SPARCstation11.NADIR is implementedusing the Sybase relationa l database manage-ment system.System O peration - ADIR receives raw auditrecords from NSC, CFS, and SAM, and it gener-atesweeklysummaries ofbothindividualuser activ-ityand aggregateICN activity.(Anexample aw auditrecord from NSC would contain the partition andICN number of th e machine from which theauthentication att empt is generated, plus the par-tition, classification level, and network compo-nent that the user wishes to access.) NAD IR hasa set of built-in expert rules for misuse detection;these rules ar e developed through audit analysis andconsultationwith security experts.NADIR comparesweekly summaries with these rules, and assigns alevel-of-intere st o eac h rule that is triggered.A users suspicion level is the sum of the level-of-interest of all rules it triggers. NADIR graphicallyshows its weekly reports on network usage, and italso highlights the most suspicious users. It canalso provide more detailed reports on raw or pro-filed audit data t o assist the SSO.Network Security Monitor (NSM)Overview (Advantages of Monitoring NetworkTraffic)- he Network Security Monitor (NSM)has been developed at the University of Califor-nia, Davis. The NSM is different from the ID Ssdiscussed earl ier in that it does not analyze audittrails [17, 27-29]. Th e NSM analyzes traffic on abroadcast LAN to detec t intrusive behavior. Thereasons for this dep arture from the standardintrusion detection methods a re outlined below.First, although most IDSs are designed with thegoal of supporting a number of different operat-ing system platforms, all present audit-trail-basedIDSs have only been used on a single operatingsystem at any one time. These systems are usual-ly designed to transform an audit log into a propri-etary format used by the IDS [5 , 9,141. In theory,audit logs from different operating systemsneed onlyto be transformed int o this proprietary form forthe IDS to perform its analysis.AnIDS that cansimul-taneously support multiple operating systems s desir-able. On the othe r hand, standard networkprotocolsexist,e.g.,TCP/IP ndUDP/IP,whichmostmajor operati ng systems support and use. Byusing these network standards, the NSM canmonitor a heterogeneous set of hosts and operat -ing systems simultaneously.

a . . . .

NetworkAnomalyDetectionand IntrusionReporteris anautomatedexpertsystem thatstreamlinesandsupplementsthe manualaudit recordreview per-formed bythe SSO.

~~~~~ ~ ~

IEEE Network MayiJune 1994 33

8/3/2019 00283931

9/16

1 Connection-IDInitiator-addressReceiver-addressService

- . .. . . .

Start-timeDelta-time

Connection-state

Security-state

Initiator-pktsInitiator-bytes

Reciever-p kts1 Receiver-bytes' Dimension

Ij Initiator_>(j Receiver-xI

Unique integer used to reference this particular connection.The internet address of the host which initiated theconnection.The internet address of the host to which the connectionwas made.An integer used to identify the particular service (i.e., telnetor mail) used for this connection.The time stamp on the first packet received for thisThe difference between the time stamp of the most recentpacketof this connection and the Start-time.The state of the connection. States for a connection includeinformation such as: NEW-CONNECTION, CONNECTION-fN-PROGRESS, and CONNECTION-CLOSED.

connection.

The current evaluation of the security state of thisconnection.The number of packets the host which initiated theconnection has placed on the network.The number of bytes, excluding protocol headers, contained

The number of packets the host which received thein the packets.connection has placed on the network.

The number of bytes, excluding protocol headers containedin the packets.Thedimensionof the Initiator-X and the Receiver-X vectors.This value is the number of strings patterns being lookedfor in the data.

Initiator-bytes.A vector representing the number of strings matched in

9 ector representing the number of strings matched inReceiver-bytes.Table 1. Cut7tirctron PC or

Second. audit trails arc often no t available in iitimely fashion. Some IDSs arc designed to pcr-form their analysis o n a separate host, 5 0 theaudit logs must be transferred from the sourcehost to a different machine for data analysis [S I .Fu r h e rmor e. th e operating s y s t e m c;In oft e ndelay the writing o f audit logs by several minutes[ I SI.The broadcast nature o fa LAN. however, givesthe NSM nearly-instant access to dl data a s soonas this data is transmitted on thc network. It isthen possible to immediately start the att ackdetection process.Third, heaudit t ra i lsareoftenvulnerable . Insoniepast incidents, the intruders have turned off auditdaemons or modified t he audit trail. Th is actioncan either prevent the detection of the intrusion,or t can remove the capability to perform account-ahi l i tv(whoturnedoff theat1di t daemons'!) anddam-age control (whatwas seen, modified. or destroyed?)The N S M . on the othe r hand, passively listens tothe network, an d is therefore logic~illy rotected fromsubversion. Since th e N S M i 4 invisible t o theintruder, t cannothe turned of f (assuming t is phys-ically secured) . and the d ata it collects cannot bemod f ed,Fourth, the collection of audit trails degrades

the performance of a machine being monitored (typ-ically bctwc cn 5 an d 20 percent). IJnless audittrails are being used for accounting purposes, sys-tem administrators often turn off auditing. I fanalysis of these audi t logs is also to be per-formed on the host, added degradation will occur.I t the audit logs are transferred iicrcxs ii networkor ;I communication channel to a separate hostfor analysis, loss of network bandwidth as well as lossof timeliness of thc data will occur. In many envi-ronments, the degradation of monitored hohtsor theloss of network bandwidth may discouragc admin-istrators from using such an IDS. I ~ h clternative,namely. the N SM architecture, does not degradethe performance of the hosts being monitored.Th e monitored hosts are not aware o f th e N S M .so the effectiveness o f the NSM is n o t dependcnto n t i e system ad m n s rat or's configuration ofthe monitored hosts.And. finally, many o f the more seriously docu-mcnted c a s e s o f computer int rusions have uti-lized ;I network :it some point during the intrusion,i.e.. the int ruder w a s physically separat ed fro mthe target . With the continued proliferation ofnetworks and interconnectivity, the use of net-works i n attacks will only increase. Furthermore,the network itself. being an important componentof ;I computing environment, can be the object o fa n attack. The N S M can take advantage of theincrease of network usage to protect the hostsattached to the networks. I t can monitor attackslaunched against the network itself, an attack thathost -h as d audit t ra an a y ze rs W O IId probah I ym i s s .System Organization (TheNSM M o d e l )- heNS M niodels the network and hosts being monitoredin 21 hie r I rc 1 I c i 11y - s ru c LI re d I n t e co nn e c e dComputing tkvirontnent Model (ICER.1).The ICEh4i s composed of six layers, the lowest being the bitstream 011 the network. and the highest being arcprcscntation for the state of the ent ire net-worked system.The bottom-most,or first, layer is the packet layer.pt s as input ahi t stream from a broad-cast L A N . e.g., Ethernet. Th e bit stream i s divid-ed up into coniplete Ethernet packets, an d a times tamp s attached o the packet. This ime-augmentedpacket is then passed up to th e second layer.Application of the NS M too the r LAN environmentsis strnightfonwird.T h c newt layer, called the thread layer. acceptsasinput the t imc-;iugmentedpackctsfrom thepack-et layer. These packets are then correlated in tounidirectional d a t a streams.Each stream consists ofthe data ( w i t h the differe nt layers of protocolhe ade rem w e d he ng transfer re d from onehost t o another host by a particular protocol (e.g..TCP!IP or U D P A P ) , through ;I unique set (forthe particular sc t of hosts and protocol) o f ports.This stream of datu. called a th read. is mappedintoathreadvector. All the threadvectorsarepasxcrlup to the third layer.The connection layer. which is the third layer,accepts as input the thread vectors generated h ythe thread layer. Each threadvectorispaircd. ifpos-sible, to anoth er thread vector to represent abidirectional stream ofdata (i.e., a host-to-host cownection). These pairs of thread vectors are repre-sented by a connection vector generated by the

34 I E E E Network MayIJune 1004

8/3/2019 00283931

10/16

-C O mb i n ;I t io n of t h e ind iv d u a 1 t h r e i d vectorsEach connection vector is analyzed, and a reducedrepresentation. ii reduced connectionvector. is passedup to the fourth Iiiycr.Layer 3 is the host layer. which accepts a s inputthe reduced connection 1ectors generatedby the con-nection layer. The connection vectors are used tobuild hust v c c [ ( i r s . Each host vcctor rcprescntsthe network activities o f ;I single host. These hostvectors are passed up to the fifth layer.'The conne cted -net ~~orkayer is th e next layerin thc ICEM hierarchy. It accepts as input thehost vectors gcner:ited b! the host layer. The h o s tvectors a r e transformed into a graph G by treat-ing th e Data-path-tuples of the hos t vectorsas an adjacency list. I f G(hostI,host?,scrvI) is notempty. then there isaconnection,orpath, from host1t o host2 by service s e r v l . The value for locationG(hostI,host7.sen.l) is non-empty if the host vec-tor for host 1 h a s (host2.servl in itsDa a-pa th-t ;;ples. his layer can build rhc con-nected sub-graphso f G.called a connected-nehvorli,orkvector, and compare these sub-graphs against his-toriciil connected s ubg rap hs. This layer can alsoaccept questions from the user abou t the graph.For example, t h e user m a y ask if there i, s o m epath between two lio\ts- hrough a n y numberof intermediate hosts - y B specific service.This se t of connected-nctwork vectors is passedu p to the sixth a n d f i n a l layer.The top-most layer. called the syctem layer. acceptsas input the set of ccinriccted-network vectorsfrom the connected-network l ayer . The s e t ofconnccted-network vectors i, t i sed t o build a sin-gle system vector representing the behavior of theentire system.

I Host-state

System Operation (Detecting ntrusive Behavior)-The traffic on t h e network is analyied by ;Isimpleexpertsystciii.The ypesofinputs o theexpertsystem are descrihcd helow.The current traffic c a s t i n t o the ICEM vectorsas discussedahove is the first type of input .Current ly,only the connection vector? an d the host vectorsare used. The coniponents for these v t i to rs- ar epresented in Tables I a n d I I .The profiles of cxpectcd traffic hehavior arc thesecond type of input. The profiles consist of expcct-ed data paths (namely. which systems are expectedtoestablish communicatioii paths to which other sys-tems. and by which \crvicc'!) and service profiles( namely . what is ;I typical tclnet, mail. finger. etc..expected to look like'!) Combining profiles andcurrent network trxffic gives the N SM the abilityto detect anomalous hehavior o n the network.The knowledge ahout capabilities of e a c h 0 1the nctwork serviccs i \ rhc third type o f i n p u t(e .g . . telnet prcnides the user M,ith more capabili-ty t h a n FT P does) .The level o f ;iiithcntication required for eachof th e services i s thc tourt h type of input (e.g..finger req ti re s n o a it h e n t i ;i ion , in B I re qucs sauthentication but docs not verify i t . and telnetrequires verified authentication).The levcl o f security l o r each of the machines isth e fifth t ypeof inpu t . ~ l ' t i i s c~ inbcasedonthe Nation-al Computer Security ('enter (NCSC)rating ofma -chines,histoiy of past d i u s e son different machines,rating received after running system evaluation soft-ware such a s Security Profile Inspector (SPl) [ 3 0 ]

The state of the host. States include: ACTIVE, NOT-ACTIVE.

I Host-ID /Unique integer used to refere r host. jI Host-address ]The internet addressof this host. I

Security-state!------ata-path-nu rnbeihost. The tuple consistsof: Other-host-address,Service-ID, Initiator-tag, and Security_state(of the datapath). ~

Table 2. Host iwtor.or COPS, orsimplywhich machines theSSOhassomecontrol o v e r and which machines the SSO has n ocontridover (e.g..a host from outside the monitoredLA N environment would d t l l in the sccondcatcgory).l ' h c sixth typeo f input issignaturesotpast attacks.Thedata from these sourccsi\used toiden tifvthelikelihood that a particular connection representsintrusive hehavior, o r if ;I host has hecn compro-mised. Th e security-state. r suspicionlevel. of ii particular connection is a function offour factors: the abnormality o f the connection,the security level of the service being used for theconnection. the direction of the connection senxi-t i v i t y level, and the matched signatures of attacksin the data stream for that conncction. We elaborateo n these components of the security-statein the following paragraphs.The abnornmality of a connection is l i ased on theprobability of that particular c onncction o c c u r -ring and th e hehavior of the connection itself. If iiconnection from hostA t o host H by service Cisra rc ,thcn the ~ibnor mal i tyo f tha t connec t iu r ishigh. Fur-thcrmore. ifthe profile of t hat connection comparedto a typical connection I?? the same typc of serv i ceis tin~isuale.g.. the nuinher of packets o r bytes isunusually high in one dircction for ;I FT P connec-t i o n ) . the ahnormality of that connection is high.

I h c security level of the service is liased o n thecii pali i t es of that sc rv ce an d the a i1 hen t ic i ionrequii-edby that service. TheT F T P servicc, for exam-ple. h as great capabilities with no authentication,so the sccurity level f o r TFTP is high. 'The telnetscrvice, o n thc other hand, a l s u h as grcat capabil-ities. but it ;ilsorcquiresstrong authentication. There-fore. the security level f o r telnet is l o w e r thanthat of TFTP.The direction of connection sensitkit y level ishiised o n the sensitivity levels o f the two machinesinvolvedancl o n which host initiated the connection.I f ;I lo\~,-sensitivity-levelo s t connects to o ra t tempts t o connec t to a high-sensitivity-levelh o s t . the d r e c ion of c o n n cc t o n sensitivity leve1o f that conncction is high. On the o t h e r hand, if ahigh-sensitivity-level host connects t o a low-levelhost. the direction ofconnection security level is low.T h e m a t c h e d sign atur es of attacks consist oft h c v c c t o r s I n i t i a t o r ~ X a n d R e c e i v e r ~ Xhicha re simply lists of counts for thc nurnbcr o f timess o m e predetermined strings being searched for inthe data is matched.The connection vectors are essentially treated as

_ .

IFFt NctworL hl,iv J u n i l Y Y 4 35

8/3/2019 00283931

11/16

Figure 1. DIDS arget environmentrecords in a database, and presentation of the infor-mation may be made as simple requests into thedatabase. The default presentation format sorts theconnections by suspicion level and presents thesorted list from highest suspicion level to the lowest.Presentations can also be made by specifying timewindows for connection, connections from a specifichost, connectionswithaparticular stringmatched, etc.The security-state, r suspicion level, ofa host is simply the maximum security-stateof its connectionvectors over a particularwindow oftime. The host vectors are also treated as recordsinto a database, and they may be presented in asimilar fashion as the connection vectors.The NSM prototype has been deployed at UCDavis, Lawrence Livermore National Laboratory,and other D OE and Air Force sites. During aparticular two-month test period, the NSM analyzedmore than 111,000 connections on the ComputerScience LAN segment at U C Davis, and i t cor-rectly identified more than 300of these connectionsas intrusive. These security incidents spanne dmore than 40 different computers, at least fourdifferent hardware platforms, and at least six OStypes. The majority of these incidents were asso-ciatedwith attempted break-ins, and somewere suc-cessful aswell. Additional incidents include stealingof password files, running of password crackerson password files, accessing of closed accounts byex-students, reading of other peoples mail, look-ing around in oth er peoples directories, andusing other peoples accounts. It should beremarked that approximately only one percent ofthese security ncidentswere detected independentlyby the system administrators.Distributed Zntrusion Detection System(DZDS)Overview- he Distributed Intrusion DetectionSystem (DIDS) is a joint project between UC Davis,Lawrence Livermore National Laboratory, HaystackLaboratory, and the US Air Force [31,32]. It is anoutgrowth of the NSM project. DIDS is designedto guard against some of NSMs deficiencies,e.g., theNSM cannot monitor an attacker who enters a sys-tem via a dial-up line and hence may not generate

any network activity and the NSM can be spoofedvia encrypted traffic. Also, one would like to extendthe network intrusion detection concept from theLAN environment to arbitrarilywider areaswith thenetwork topology being arbitrary as well.In DIDS, each host in the monitored domain is alsoequipped with a host monitor. In the current DIDSdesign, these hosts are assumed to be connected viaa LAN,which is monitored by a LAN monitor. Thus,network monitor data is augmented by data frommonitored hosts. Generalization of the monitoredenvironment beyond the local area is an open prob-lem, and a preliminarydesign has been proposed [33].In DIDS, the host and LAN monitors reportany interesting events, which may possibly leadto intrusive activity, to a centrally-located DIDSdirector. The director employs an expert systemto detect possible attacks. An initial prototype ofDIDS has successfully demonstrated its ability totrack users as they move around the network(possibly attempting to hide their true identities)and to identify doorknob rattling attacks [32,34].The DIDS architecture performs information aggre-gation so that even if the activity of a network-wide user may not be suspicious on a single host,the aggregate behavior may be suspect or unper-mitted. One of the strengths of this architectureis that it performs accountability by tying userswith their actions.System Organization The generalizeddistributedenvironment s heterogeneous, .e., the network nodescan be hosts or serversfrom different vendors (Fig. 1).The DIDS architecture combines distributed mon-itoringand data reductionwithcentralized data anal-ysis. This approach is unique among current IDSs.The components of DIDS are the DIDS director, asingle host monitor per host, and a single LAN mon-itor for each broadcast LAN segment in the moni-tored network. DIDS can potentially handle hostswithout monitors since the LAN monitor can reporton the network activities of such hosts. Th e hostand LAN monitors are primarily responsible for thecollectionofevidence of unauthorized or suspiciousactivity,while the DIDS director is primarily respon-sible for its evaluation. Reports aresent independentlyand asynchronously from the host and LAN mon-itors to the DIDS director through a communicationsinfrastructure (Fig. 2 ) . High-level communicationprotocols between the components are basedon theIS0 Common Management Information Proto-col (CMIP) recommendations, allowing for futureinclusion of CMIP management tools as they becomeuseful. The architecture also provides for bidirec-tional communication between the DIDS directorand any monitor in the configuration. This com-munication consists primarily of notable eventsand anomaly reports from the monitors. Thedirector can also make requests for more detailedinformation from the distributed monitorsvia a GETdirective,and issue commands o have the distributedmonitors modify their monitoring capabilities viaa SE T directive. A large amount of low-level fil-tering and some analysis is performed by the hostmonitor to minimize the use of network band-width in passing evidence to the director.The host monitor consists of a host event gener-ator (HEG) and a host agent. The HEG collects andanalyzes audit records from the hostsoperatingsys-tem. The audit records are scanned for notable events,

36 IEEE Network MayiJune 1994

8/3/2019 00283931

12/16

which are transactions that are of interest indepen-dent of any other records. These include, among oth-ers, failed events, user authentications, changes tothe securitystateofthesystem,and any networkaccesssuch as rlogin nd r sh .These notable events arethen sent to the director for further analysis. TheHE G also tracks user sessions and report anoma-lousbehavior aggregated over time through user andgroup profiles and the integration of the HA YSTACKintrusion detection algorithm [5]into DIDS. Thehost agent handles all communications betweenthe host monitor and the DIDS director.Like the host monitor, the LAN monitor con-sists of a LAN event generator (LEG) and a LANagent.TheLEGiscurrent1yasubset oftheNSM [17,27, 291. Its main responsibility is to observe all ofthe trafficonitssegmentoftheLANinorder tomon-itor host-to-host connections, servicesused, andvol-ume oftraffic. The LANmonitor reports on networkactivities such as rlogin nd telnet connections,the use of security-related services, and changesin network traffic patterns.The DIDS director consists of three major com-ponents that are all located on the same dedicatedworkstation- communications manager,anexpertsystem, and a user interface. Because the compo-nents are logically ndependent processes, hey couldbe distributed as well. The communications man-ager is responsible for the transfer of data betweenthe director and each of the host and the LA N mon-itors. It accepts the notable event records from eachof the host and LAN monitors and sends them to theexpert system. On behalf of the expert system or userinterface, it is also able to send requests to thehost and LAN monitors for more information regard-ing a particular user. The expert system is respon-sible for evaluating and reporting on the securitystate of the monitored system. It receives therepor tsfrom the host and the LAN monitors, and, basedon these reports, it makes inferences about the secu-rity of each individual host, as well as the systemas a whole. The expert system is a rule-based sys-temwith simple learning capabilities. The directorsuser inter face allows the SS O interactive accessto the entire system. The SSO can watch activitieson each host, watch network traffic (by setting wire-taps), and request more specific ypes of informationfrom the monitors.It is anticipated that agrowing set of tools, includ-ing incident-handling tools and network-manage-ment tools,will be used in conjunctionwith the intru-sion-detection functions of DIDS. This will give theSSOthe abilityto activelyrespond to attacks againstthe system in real time. Incident-handling tools mayconsist of possible courses of action to take againstan attacker, such ascuttingoffnetwork access,a direct-ed investigation of a particular user, removal of systemaccess, etc. Network-management tools that are ableto perform network mapping would also be useful.System Operation- ) The Network-user Iden-tification(NID) One of the challenges for intrusiondetection in a networked environment s to track usersand objects (e.g., files) as they move across the net-work. For example, an intruder may use severaldifferent accounts on different machines during thecourse of an attack. Correlating da ta from severalindependent sources, including the network itself,can aid in recognizing this type of behavior and intracking an intruder to his source. In a networked

Figure 2. Communications architecture.

environment,an intruder may often choose to employthe interconnectivity of the computers to hide histrueidentityandlocation.1tmaybethat singleintrud-er uses multiple accounts to launch an attack, andthat the behavior can be recognized as suspiciousonly if one knows that all of the activity emanatesfrom a single source. For example, it is not partic-ularly noteworthy f a user inquires aboutwho is usinga particular computer (e.g., using the UNIX whoor finger ommand). However, it may be indica-tive of an attack (or a preparation of an attack) ifa user inquir es about who is using each of th ecomputers on a LANand then subsequently ogs ntoone of the hosts. Detecting this type of behaviorrequires attributing multiple sessions, perhapswith different account names, to a single source.This problem is unique to the network environ-ment and has not been deal t with before in thiscontext. The solution to the multiple user identityproblem is to create a network-user identification(NID) the first time auser enters the monitored envi-ronment, and then to apply that NID to any fur-ther instances of the user [34].All evidence aboutthe behavior of any instance of the user is thenaccountable to the single NID. In particular, we mustbe able todetermine that s m ith@hos 1 s the sameuser as jones@host2, f in fact they are. Sincethe NI D problem involves the collection an devaluationof datafromboth the host and LA o n-itors, examining it is a useful method to under-stand the opera tion of DIDS.2) TheExpert System. DIDS utilizes arule-based(orproduction) expert SystemwritteninCLIPS. Theexpert system uses rules derived from a hierarchi-cal Intrusion Detection Model (IDM) . The IDMdescribes the transformation from the distributedraw audit data to high-level hypotheses aboutintrusions and about the overall security of the mon-itored environment. This unified view of the dis-tributed system simplifies he recognition of intrusivebehavior tha t spans individual hosts. The modelis the basis of the rule-base. T he IDM consists of

IEEE Network MayiJune 1994 37

8/3/2019 00283931

13/16

m m m m m

At thehighestlevel, themodelproduces anumericvaluebetween1and 100.The higherthe number,the lesssecure is thenetwork.

six layers, with each layer representing the resultof a transformation performed on the data.The objects at the first (i.e., lowest) level are theaudit records provided by the host OS,by the J A Nmonitor, or by any third-party auditingpackage. Theobjectsat thislevelarebothsyntacticallyandseman-tically dependent on the source. At this level, allof the activity on the host or LAN is represented.At the second level, the event (which has alreadybeen discussed in the context of the host a ndLANmonitor) is both syntactically ndsemanticallyindependent of the sourcestandard format for events.The third layer of the IDM creates a subject. Thisintroducesasingleidentificationforauseracrossmanyhosts on the network. It is the subject who is identi-fied by the NID. Upper layers of the model treat thenetwork-user as a single entity, essentially ignor-ing the local identification on each host. Similarly,above this level, the collection of hosts on the LANis generally reated as a single distributedsystem withlittle attention being paid to the individual hosts.The fourth layer of the model introduces he eventin context. There are two kinds of context: temporaland spatial.As an example of temporal context,behav-ior which isunremarkable during standard workinghours may be suspicious during off-hours [35].TheIDM, therefore, allows for the application of infor-mation about wall-clock time to the events it is con-sidering.Wall-clock time refers to information aboutthe time of day, weekdaysversusweekends and hol-idays, as well as periodq when an increase in activityis expected.In addition to the consideration of exter-nal temporal context, the expert system uses timewindows to correlate events occurring in temporalproximity. This notion of temporal proximity imple-ments the heuristic that a call to the UNIXwho om-mand followed closely by a login r logout is morelikely to be related to an intrusion than either of thoseevents occurring alone. Such related pattems of behav-ior are also referred to as attack signatures [23,24].Spatial context implies the relative importance of thesource of events. That is, events related to a par-ticular user, or events from a particular host, maybe more likely to represent an intrusion than sim-ilar events from a different source. For instance, auser moving from a low-security machine to ahigh-security machine may be of greater concernthan a user moving in the opposite direction.Themodel also allows for the correlat ion of multipleevents from the same user o r source. In both of thesecases, multiple events are more noteworthy whentheyhave acommonelement thanwhen they donot.The fifth layer of the model considers the threatsto the network and the hosts connected to it.Events in context are combined to crea te threats.The hreats are partitioned by the nature of the abuseand the nat ure of the target . In other words, whatis theintruder doing, andwhat is he doing it to?Abus-es are divided into attacks,misuses, nd suspiciousacts. Attacks represent abuses in which the stateof the machine is changed. That is, the file systemor process state is different after the attack thanit was prior to the attack. Misuses represent out-of-policy behavior in which the state of the machineisnot affected.Suspicious acts are events which, whilenot a violation of policy, are of interest to an IDS.For example, commands which provide informationabout the state of the system may be suspicious.The targets of abuse are characterized as being eithersystem objects or user objects and as being either

passive or active. User objects ar e owned by non-privileged users and/or reside within a non-privi-leged user's directory hierarchy. System objectsar e the complement of user objects. Passiveobjects are files, includingexecutable binaries , whileactive objects are essentially running processes.At the highest evel, the model produces a numer-ic value between one and 100which represents theoverall security state of the network. T he higherthe number, the less secure is the network. Thisvalueis a function of all the threats for all the subjectson the system. Here again we trea t the collectionof hosts as asingle distributed system. Althoughrep-resenting the security level of the system as a singlevalue seems o imply somelossof information, t pro-vides a quick reference point for the SSO. In fact,in thecurrent implementation, no informationislostsince the expert system maintains all the evidenceused in calculating the security state in its inter-nal database, and the SSOhas access to that database.In the context of the NID problem, we ar e con-cerned primarily with th e lowest thre e levels ofthemodel: the audit data, the event, and the subject.The gener ation of th e first two of th ese havealready been discussed; the crea tion of the sub-ject is the focus of the following subsection.3) Building the NID. With respect to UNIX, theonly legitimate ways to create an instance of a userare for the user to login from a terminal, a console,or an off-LAN source, to change the user-id in anexisting instance, or t o crea te additional instances(local or remot e) from an existing instance. Ineach case, there is only one initial ogin (system-wide)from an external device. When this original loginis detecte d, a new unique NID is crea ted. ThisNID is applied to every subsequent action generatedby that user. When a user with a NID crea tes anew login session, hat new session s associatedwithhis original NID. Thus, the system maintains asingle identification for each physical user.We consider an instance of a user to be the 4-tuple.Thus each login creates a new instance of a user. InassociatingaNIDwithaninstanceofauser, theexpertsystem first tries to use an existing NID. If noNID can be found which applies to the instance,a new one is created. Trying to find an applicableexistingNIDconsists of several steps. f a user changesidentity (e.g., using UN IX s s u command) on a host,the new instance is assigned the same NID as theprevious identity. If a user performs a remote loginfrom one host to another host, the new instance getsthe same NID as the source instance.When no appli-cable NID is found, a new unique NID is created.The actual association of aNIDwith auser instanceis through the hypothesis net-user. A new hypoth-esis is created for every event reported by the dis-tributed monitors. This new hypothesis, called asubject, is formed by anot her rule. The ru le cre-ates a subject, getting he NID from the net-user andthe remaining fields from the host audit record, ifand only if both the user-id and the host-id match.It is through the use of the subject that t he expertsystem corre lates a user's actions regardless ofthe login name or host-id.The re is still some uncertainty involved withthe NID problem. If a user leaves the monitoreddomain and then comes back inwith a different user-id, it isnot possible toconnect the twoinstances.Sim-ilarly, if a user passes through an unmonitored

38 IEEE Network MayiJune 1994

8/3/2019 00283931

14/16

W Figure 3. Statistical intrusion detection algorithms.host, there is still uncertainty that any connectionleaving the host is attributable to any connectionentering the host . Multiple connections originat-ing from the sa me host at approximately thesame time also allow uncertainty if the usernames do not provide any helpful information.The expert system can make a final decision withadditional information from the host andLANmon-itors that can (with high probability) di sam-biguate the connections. To deal with suchsituations, a new concept, called thumbprint-ing, which is a mechanism for identifying identi-cal network connections, is being developed [33].Case Study: An IntrusionDetection Algorithm

he intrusion detection algorithm used in theTHAYSTACK system is also the co re of thehost monitor used in DIDS. This algorithm isemployed here as an example to demonstratehow a statistical anomaly detection algorithm typ-ically operates.The LKYSTACKalgorithm (hereafter referred toas the algorithm) assumes that the audit trail gen-erated from a host has been converted to a canoni-calaudit rail (CAT) ormat. Even though differentma-chines may generate audit data in different formats,they can still be served by the same intrusion detec-tion algorithm by having their generated audit infor-mation converted to the CAT format. The algorithm

. . a . .

TheHAYSTACKalgorithmassumesthat theaudit trailgeneratedfrom a hosthas beenconverted toa canonicalaudit trail(CAT)format.

examines a CAT file to generate session vectors rep-resenting the activities of the users sessions (wherea user session includes all activities between a loginand a logout).These session vectors are then analyzedagainst specific ypes of intrusive activity, and anoma-ly scores for the sessions are calculated. When thescorescrosssome specific hresholds,warnings reportsare generated. The analysis of the session vectorsis the specific focus of our discussion here.Ausers activitiesare analyzedaccording to afour-step process. The first step is to generate a ses-sion vector represent ing the activities of the userfor a particular session. The second st ep is thegeneration of a bernoulli vector representing theattributeswhich are out of range for a particular ses-sion. The third step is the generation of a weight-ed intrusion score, for a particular intrusion type,from the bernoullivector and a weighted featurevec-tor. The fourth s tep is the generation of the suspi-cion quotient repr esenting how suspicious thealgorithm believes this session to be when comparedto all other sessions.This four-step process is shown in Fig. 3. BoxesF 1 hrough F 4 represent the functions for each ofthe above processes. Fig. 3 also shows the stepsGI through G3 ollowed by the IDES statisticallyanomaly detection algorithm [ l l ] , nd it indi-cates how the steps in the Haystack and t heIDESalgorithms parallel each other.W e restrict ourattention to the Haystack algorithm here. F1 , thegeneration of the sessionvector, s not covered. Func-tions F2 through F4 are discussed below.

IEEE Network MayiJune 1994I

39

8/3/2019 00283931

15/16

B . . . .

Intrusiondetection isa viable andpracticalapproachfor provid-ing a differ-ent notionof securityin our hugeand existinginfr astruc-ture ofcomputerand networksystems.

F2:Generating the Bernoulli VectorF 2 represents the function to generate the bernoul-li vector from the session and the threshold vec-tors. Each of these vectors, as well as the algorithmto calculate he bernoullivector, are describedbelow.The session vector X =

8/3/2019 00283931

16/16

Conclusionntrusion detection is aviable and practicalapproachI or providing a different notion of security inour huge and existing nfrastructure of (possible nse-cure) computer and network systems. Intrusion detec-tion systemsare basedonhost-audit-trailand networktraffic analysis, and their goal is to detect attacks,preferably in real time. Anumber of prototype intru-sion detection systems have been built, and this con-cept has been proven to be extremely promising.In the future, it is expected that the current proto-typeswill be developed further in order to turn theminto production-qualitysystems. Benchmarkingmech-anisms n order to test the effectivenessof IDSs shouldbe developed. Accurate approaches for represent-ing attacks and misuse (includingdevelopmentof mod-elsfor new attackmethods) as well as new and more-effective detection strategies must be investigated.In addition, much more research is expected to beconducted, e.g., how can the intrusion-detection con-cept be extende d to arbitrarily large networks(e.g., the worldwide Internet), how can the IDS itselfbe protected from attackers, etc.

AcknowledgementsThe intrusion detectionR & D work in the ComputerSecurity Laboratory at UCDavis is supported by theLawrence Livermore National Laboratory (LLNL),U.S.AirForceCrypto1ogicSupportCenter (AFCSC),National Computer SecurityCenter, Hewlett-Packard,Logicon-Ultrasystems, and the State of CaliforniaMICRO Program.We acknowledge he contributionsof our colleaguesat UC Davis, LLNL,AFCSC,and Haystack Labora-tories toward the NSM and DIDS prototypes. I t isthroughvarious discussionswith them as well as withpeople at NCSC (Becky Bace in particular) that ourunderstanding of intrusion detection has improved.

References111National Computer Security Center. Department of Defense, Trust-ed Compu ter System Evaluation Criteria, DOD 5200.28-STD.Dec.1985 (Oi ange Book).I21 National Computer Security Center, Dept. of Defense, TrustedComputer System Evaluation Criteria. DOD 5200.28-STD. July1987 (Red Book).[31V. L. Voydock and S. T. Kent, "Security in high-level network proto-cols," IEEE Commun. Mau.. vol. 23. no. 7, DD. 12-24.Julv 1985..141D. E. Denning, "An intrus&detection model. "lEEE Trdns. on Soft-

ware Engg., ol. SE-13, pp. 222-232, Feb. 1987.151S.E. Smaha , "Haystack An Intrusion Detection System," Proc..EEE Fourth AerospaceComputer SecurityApplicationsConference.Orlando, FL, ec. 1988.I61 C. Dowell and P. Ramstedt, "The COMPUTERWATCH da ta reduc-tion too1,"Proc.. 13thNational Computer SecurityConference, Wash-ington, DC. pp. 99-108, Oct. 1990.[7lW.T.Tener."Discovery: anexper t systeminthecommercialdatasecu-rity environment." Proc. Fourth IFlP TC11 Interna tional Confer-ence on Computer Security. North-Holland. Dec. 1986.181W.T.Tener,"AI&4GLAutomatedDetectionandlnvestigationTools,"Proc.FfihmPIntemulionalConferenceonComputerecurity,North-Holland. May 1988.[SI T. F. Lunt et al.. IDES: A Prog ress Report." Proc., Sixth AnnualComputer Security Applications Conf.. Tuscon. AZ. Dec 1990.1101 T. F.Lunt e tal., AReal-timeIntlusionDetectionExpertSystem(IDES),"Interim Progress Report,Project 6784, SRI nterna tional , May 1990.[ ll l H. S. Javitz and A. Valdez, "The SR I IDES Statistical AnomalyDetector," Proc.. 1991 IEEE Symposium on Research in Security

and F'rivacy, Oakland , CA, May 1991.11211 A. Winkler and W. I. Page, "Intrusion and Anomaly Detection inTrusted Systems". Roc .. Fifth Annual Computer Security Applica-

tions Co nference . Tucson, AZ. Dec. 1989.[131J. R. Winkler, "A UnixPrototype for Intrusion and Anomaly Detec-tionin SecureNetworks."Proc.13thNationalComputer SecurityCon-ference. Washington,D.C., Oct. 1990. 115-124.(141 M M. Sebring et al..Expert systems in intrusion detection: A casestudy."hoc.. 1lthNational Computer SecurityCod ., Baltimore. MD.Oct. 1988.

(151 H. S. accaro and G. E. Liepins, "Detection of anomalous com-puter s ession activity." Proc.. 1989 Symposium on Research inSecurity and Privacy. Oakland. CA, pp. 280.289. May 1989.

1161 J. Hochberg et al., "NADIR: a n autom ated system for detectingnetwork intrusion and misuse." Computers and Security. vol. 12,no.3, pp. 235-248. May 1993.[171 L. T. Heberlein et al..A network security monitor."Proc.. 1990Symposium on R esearch in Security an d Privacy. Oakland , CA,pp. 296-304, May 1990.

1181 T. F. Lunt. personal communication. 1992.[191 S.M. Bellovin, "There Be Dragons, " Proc., Third UNIX SecuritySymposium. Baltimore,MD. Sept. 1992.DO 1W.R. Cheswick,"Anevening with berferd, inwhic hacracker is lured.endured . and studied." Proc., Winter USENM Conference. San Fran-cisco, Ian. 1992.I211 S. M. Bellovin, "Securityproblems in the TCPflPprotocol suite,"

ACMComputer Commun .Review, vol. 19,no. 2, pp. 32-48,Apd 1989.(221 H. S. eng. K. Chen, and S.C.-Y. Lu, "Adaptive real-time anom a-ly detection using inductively generated sequential patterns."Proc.. 1990 Symposium on Research in Security and Privacy,Oakl and , CA, May 1990.1231S. . Snapp, B.Mukheqee, and K. N. Levitt, "Detecting intrusionsthrough attack signature analysis,'' Proc., 3rd Workshop on Com-puter Security Incident Handling, Hemdo n. VA, Aug. 1991.

[241S. . Snapp. SignatureAnalysis and Communicationlssues inaDis-tributed Intrusion