next-generation intrusion detection expert system (nides

. ,

3UFYe 1i eftwodd Aven4i • + 44 361-ft6-2Oi'l + FAX:(413) 32B-55th : Te19x 3344861

'This reportwas pnrpnred for th e Oaper4nant of the Navy, Space and Naval Warfare Systems Command,under Contract NOa030-92-C-OD15

-- E3~ ~1 'V

Next-generation Intrusion Detection Expert System (NIDES)A Summary'

Debra AndersonThane FnvoldAlfonso Valdes

Computer Science LaboratorySRI-CSL-95-07 , May 1995

Case 1:05-cv-00405-SLR Document 29-2 Filed 06/16/2005 of 47

77S1010101111131313131315161617171818202021

2 Software Prototypes2 1 Alpha Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 2 Alpha-patch Release . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . .2 .3 Beta Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 .8. 1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 .9.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 .3 .2 . 1 Optimization of Profile Structure . • • - • • • • • -2.3 2.2 Analysis Configuration (Real-time and Batch) . . . _ . . . .2 3 .2.3 Status Reporting - . . . . . . . . . . . . . . . . . . . . .2.3.2.4 Data Management Facility - - . . . . . . . . . . . . . . .2 3 .2.5 Expanded Rulebase - • • • . • - . . . . . . . . .

2.4 Beta-update Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.4 .1 Bug Fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.4.2 Performance Improvements . . . . . . . . . . . . . . . . . . . . . . .2 . 4.3 New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 .4 .3.1 Perl Script ages Utility . . . . . . . . . . . . . . . . . .2 .4 .3 .2 UNIX agen Ethernet Enhancement . . . . . . . . . . . . . .2 4 .3.3 Updated Rulebase and event Fa ct Template • • • - • -2.4.3 .4 Expanded Audit Record Codes - • • • • • -2.4 .3 .6 Updated Installation Procedures and Documentation . . . .

2 .5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _2.5. 1 Components . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 5.1.1 Persistent Storage . . . . . . . . . . . . . . . . . . . . .

Contents

1 Introduction1 . 1 Previous work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 .2.1 Advisor Project . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 .2.2 FBI FOIMS-IDES Project . . . . . . . . . . . . . . . . . . .

. . . . .

1 .2.3 Safeguard Project . . . . . . . . . . . . . . . . . . . . . . . . .. . . .

1 .2 .4 NIDES Training Course . . . . . . . . . . . . . . . . . . . . . . . .1 3 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i23S444b


36Bibliography

2. 5 . 2 . 2 Agend . . . . . . . . . . . . . . . . . . . . . .2 .5.1 .9 Agen . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.5.1 .4 Arpool . . . . . . . . . . . . . . . . . . . . . . . . . . .2.5-15 Statistical Analysis Component - - - • . . . . .2 .6.1 .6 Rulebased Analysis Component • • • • • • -2.5.1 .7 Resolver . . . . . . . . . . . . . . . . . . . . . .2 .5.1 8 Archive r . . . . . . . . . . . . . . . . . . . . . . . . .2.5 .1 .9 Batch Analysis . . . . , . . . . . . . . . . . . . . . .2.6.1.10 User Interface . . . . . . . . . . . . . . . . . . .

2.5 2 Ope rat ion . . . . . . . . . . . . . . . . . . . . . . . .2 .5.21 Real-time Operation . . . . . . . . . . . . . . . . . .2 .5.2.2 Batch Operation . . . . . . . . . . . . . . . . . . . . . . . .

3 Future Directions31 Technology Transfer and Operational Evaluation • • - • -3.2 User Support and Training . . . . . . . . . . . . . . . . . . . ,

3.2 . 1 NIDES Maintenance - . . . . . . . . . . . . . . . . . .3 .2 .2 Training . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . .3 .2 .3 Telephone and On-site Support3.2.4 Configuration Mana gement • - • • - - • - - - - • -

3.3 Security Goals • . . . . . . . . . . . . . . . . . . . . . . .3 4 Network NIDES • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , .

3.4 .1 Data Collection - - •-•3 .4. 2 Rulebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.4 .3 Statist ical Measuxea . . . . . . . . . . . . . . . . . . . . .

3 .5 Intru sion-Detection Teetbed • - - • -3.6 Rulebase Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 .? Profiling Other E ntities . . . . . . . . . . . . . . . . . . . . . . . . . .38 Enhanced Component Independence - • - • • -

212122222223232323232425

27272828282829293131313232333334


id

List of Figures

2. 1 NIDE5 Process Graph [teal Mme} . . . . . . . . . . . . . . . . . . . . . 242.2 NIDFS Process Graph (Batch Mode) . . . . . . . . . . . . . . . . . . . . . 26


iv

List of Tables

2. 1 NIDES Nod, ~e Profile Strtxt+ue Size Comparison . . . . . . . . . . . . . . I I2 .2 NOES Default Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 .3 Bata Release Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 162,4 NIDES Audit Record Action Codes Comparison Beta and Beta -update Releases 192 .6 NIDES Audit Record Source Codes . . . . . . . . . . . . . . . . . . . . . . 20


Existing security mechanisms protect computers and networks from unauthorized usethrough access controls, such as passwords . However, if these access controls am compro-mised or can be bygaeeed, an abuser may gain unautbnrized access and thus can cause greatdamage and disruption to system operation .

Although a computer syatemh primary defense is its access controls, it is clear fromnumerous newspaper accounts of break-ins, viruses, and computerized thefts that we cannotrely on aeons control mechanisms in every case to safeguard against a penetration or insiderattack. Even tie most secure systems are vulnerable to abuse by insiders who misuse theirprivileges, and audit trails may be the only means of detecting authorized but abusive useractivity.

Other modes of protection can be devised, however. An intruder is likely to exhibit a be-havior pattern that differs markedly from that of a legitimate user . An intruder masqueradingas a legitimate user can be detected through observation of this etattstically unusual behav-ior. This idea is the basis for enhamciag system security by monitoring system activity anddetecting atypical behavior . Such a monitoring system will be capable of detecting intrusionsthat could not be detected by any other means, fior example, intrusions that exploit unknownvulnerabilities . In addition, any computer system or network has known vulnerabilities thatan intruder can exploit. However, it is more efficient to detect intrusions that exploit theseknown vulnerabilities through the use of explicit expert system rules than through statisticalanomaly detection,

While many computer systems collect audit data, most do not have any capability forautomated analysis of that data . Morewar, those systems thatch collect audit data generallycollect large volumes of data that are not necessarily security relevant . Thus, for securityanalysis, a security officer (SO) must wade through stacks of printed output of audit data .Besides the pure tedium of this task, the sheer volume of the data makes it impossible for thesecurity officer to detect suspicious activity that does not conform to a handful of obviousintrusion scenarios. Thus, the capability for automated security analysis of audit trails isneeded

Chapter 1

Introduction


'All product names u sed in this manual are teademszks of their reepacfsva holders.

IVIDES Final Report

The Next generation Intrusion-Detection Expert System (HIDES) is the result of researchthat started in the Computer Science Laboratory at SRI International in the early 19808 andled to a series of increasingly sophisticated prototypes that resulted in the current HIDESBeta release. The current version, described i.%L this final report and in greater detail in[l, 2, 3], is designed to operate in real tune to detect intrusions as they occur . HIDES is acomprehensive system that uses innovative statistical algorithms for anomaly detection, aswell as an expert system that encodes known intrusion scenarios .

1 ,1 Previous WorkOne of the earliest works on intrusion detection was a study by dim Anderson [4], whosuggested ways of analyzing computer system audit data . His methods use data that arecollected for other reasons (e .g., performance aaalYsie) and were designed for 'batch" modeprocessing-, that ie, a days worth of audit data would be analyzed at the end of the day.

Subsequent to Anderaord study, early work focused on developing procedures and algirrithnne fir automating the offlme security analysis of audit trays . The aim of such algorithmsand procedures was to provide automated tools to help the security officer in a daily assess-ment of the previous dad computer system activity. One of these projects, conducted atSRI, used existing audit trails and studied possible approaches for building automated toolsfor audit trail security analysis [5] . This work involved performing an extensive statisticalanalysis on audit data from IBM systems running MVS'and VM . The intent of the studywas to develop analytical statistical techniques for screening computer system accountingdata to detect user behavior indicative of intaneidnne . One result of this work was the devel-opment of a high-speed algorithm that could accurately discriminate among users, based ontheir behavior profiles .

Another such project, led by Teresa Lust at Sytek [6], considered building special securityaudit trails and studied possible approaches for their automated analysis . These projectsprovided the first experimental evidence that users could be distinguished from one anotherthrough their patterns of computer system use 151, and that user behavior characteristicscould be found that could be used to discriminate between normal user behavior and avariety of emulated intrusions [7, 8, 9, 10, 11, 12] .

The evidence of the early Sytek and SRI studies was the basis for SRE real-timeintrusion-detection system, that is, a system that can continuously monitor user behaviorand detect auspicious behavior as it occurs . This system, NIDFS, is based on two approaches :(1) intniaiane, whether successful or attempted, can be detected by flagging departures fromhistorically established norms of behavior for individual users, and (2) known intrusion ece-narioe, known system vulnerabilities, and other violations of a ayetend intended securitypolicy (i.e., a priori definition of what is to be considered suspicious) are best detectedthrough use of an expertByatem rulebase .


This project was sponsored by Rome Laboratory, and SRI was a subcontractor to TrustedInformation Systems. SRI added specific new functionality to NIDE9 to support the cve-tomizatian and use of HIDES with Trusted Xenix hosts . Changes made to HIDES in-cluded an analysis cugtomizatian facility whereby the statistical component could be tunedand specific measures enabled and disabled, and the rulebase could be customized by en-ablingldisabling rules and introducing new rules in the running system . A test facility wasadded whereby a candidate NIDF3 configuration could run alongside the real-time NIDF.Ssoftware. An archival facility was developed that supports archival and retrieval of auditrecords and result data. The HIDES audit record structure was expanded to include fieldsthat store security label and integrity information for user ids and file objects . New mea-sures were added to the NIDFS statistical analysis component to support the new securitylabel information. SRI performed an additional task to study the feasibility of introducing aneural network component into the NIDES analysis. See [14] for a description of thin neuralnetwork study.

Introduction

Largely as a result of the pioneering work at SRI, several other intrusion-detectionprojects are under way at other institutions. For a survey of these, see [3. 3] .

1 .2 Related WorkDuring the period of the HIDES work funded under this contract, four related efforts wereundertaken that uhhzed the HIDES software prototype These projects benefited from thework performed under this contract and also contributed to the improvements made to theHIDES software prototype :

. Advisor Project -- Under contract to Trusted Information Systems (TIC, SRIhelped to develop a modified version of NIDEB to support the monitoring of TrustedXenix systems .

. FBI FOAMS-IDES Project - SRI provided customized versions of the NIDESprototype to the FBI to support analysis of database transaction logs from the FB I-F7IM5 database application.

• Safeguard Project - Under contract to TES, SRI performed a study to analyze theeffectiveness of the NIDES statistical analysis component in recognizing masqueradingapplications .

• 1JIDFS Training Course - SRI developed and hosted a four-day, intensive, hands-on training course offered free of charge to NIDES users

1.2.1 Advisor Project


MDES Final Report

. Rulebased analysis configuration

1 .2.2 FBI FOIMS IDES ProjectUnder this FBI-sponsored project, an application of NIDES was developed to support evalua-tion of database transaction logs generated by the FB3A FOIMS application. Cuetom izatiaaamade by SRI included development of specific expert system rules , statistical parameters ,and audit data conversion routines to map the FOIMS audit trail data to the NIDES canoni-cal audit record format. Several versions of the FOII4iS -HIDES system were installed at FBIheadquarters for evaluation. In addition , a study was performed that considered the securityimplications anticipated in the use of NCIC-2000. The results of this study are discussed in[l5]•

1.2.3 Safeguard ProjectUnder contract to Trusted Information Systems ('I'IS), SRI evaluated the ability of HIDESto detect the use of computer systems for other than authorized applications .

The principal goal of the Safeguard Audit Data Analysis task was to explore methodsof detecting and reporting attempts, by those whose use of exported computer systems inrestricted to approved applications or classes of applications, to bypass or defeat softwareexecution restrictions. As part of this task, audit trail analysis echniques were consideredas potentially useful in detecting misuse of restricted technology.

In the paradigm explored by SRI [1f,, 17, 18, 19, 201, the subjects were considered tohave been computer users . For the Safeguard study, the NEDES methodology was adaptedto consider applications as subjects . The methodology as adapted for Safeguard would beuseful in the detection of trojan horses and other masquerading applications . The analysissoftware developed for this project was a straightforward adaptation of the current HIDESstatistical analysis component

Overall. the HIDES statistical component was successful in its efforts to detect mas-querading appliccatinne, whether these were special resource-intensive applications or Stan-dard applications run through historical profiles other than their own . Simulated maequerad-mg applwations were detected 101 times in 130 opportunities, with a false positive detectionrate of 1.3% .

For additional information on the Safeguard project, see [21, 221 .

1.2.4 NIDES Training CourseIn August of 1994 SRI hosted a training course attended by ten students . The course taughtby Debra Anderson, Thane Frivold, and Al Valdes was designed to give students a hands-onintroduction to the NIDES Beta release . The following topics were covered :

. System installation and configuration

* Real-time ope ration


- Software teat report [23]- Used manuals [2, 24, 25]Design documents [3, 18]

- Requirements specification (1]

Technology transfer plan [26]

Introduction

• Statistical analysis configuration

• Target host configuration

. Audit data concepts and sources

. Performance tuning

. Experimentation

Students completed course evaluations indicating that they were pleased with the coursecontent and pacing . The rulebase sessions were the moat popular . Severel students success .fully wrote, installed and used realistic rules during this rulehesed configuration exercises . Bylearning about all the key features of NIDES the students were able to gain a comprehensiveunderstanding and appreciation for the eyetano d utility and flexibility.

1.3 Project OverviewProgress on this project concentrated on the rearchitecting of the IDES software prototypeinto the MODES prototype and the subsequent refinement and enhancement of the NIDESsoftware. Key achievements were

. IDES prototype rearchitected to become NII?ES

• First NIDES release delivered (NIDFS alpha)

• Alpha patch release delivered with performance improvements

• Beta release delivered with greatly expanded configuration features and system moni-toring functions

. Beta update release delivered with additional performance improvements and usercustomization of audit data sources for NEDES analysis

• Reports completed


The first HIDES release was a rearchitected version of the previous IDES prototypes [l6]. Thearchitecture was based on core components and iafraetructural facilities [18] . The NIDEScore components included the user interface, the resolver, the statistical, the rulebased, theaudit data collection, and the audit data generation components . The HIDES infrestruc-turalfacilities included process management, iaterpraceea communication, and graphicaluser interface facilities . The rearchitecting process imposed a modular design on the NIDE5

Chapter 2

Software Prototypes

SRI developed four major versions of the NIDLS software prototype, each with increasedfunctionality and performance :

• February 1993 -- NIDES Alpha Release: A rearchitected prototype was com-pleted and christened HIDES alpha . This prototype incorporated a client-server ar-chitecture and modular design into the functionality of the IDES prototype [1 6). AnX•windows user interface using the MOTIF toolkit was also incorporated .

• October 1993 - NIDF.g Alph&-patch Release : An updated version of the HIDESAlpha release was delivered with performance improvements, primarily involving thestatistical analysis component.

• May 1994 - NIDES Beta Release: A greatly enhanced version of NEDES wasreleased with numerous now features, including real-time reconfiguration of HIDESanalysis, system status reporting functions, and a greatly expanded ttseid manualAn expanded nflebese was also developed . Thirty copies of the Beta release weredietri'buted.

• November 199 -HIDES Beta-update Release : An updated version of theNIDFS Beta Release was developed to address reported bugs and to incorporate im-proved statistical algorithm, enhanced perfor••,pnce and a Per1 scripted agen .

2.1 Alpha Release


The ICES Alpha-patch release was developed in response to userfeedback regarding NIDESperformance. Three key changes were made to improve system performance and increaseconfiguration capabilities. To expedite the completion of the Alpha-patch release, no ad-ditional changes were made to the NIDES user interface . Because the user interface wasunchanged, the three configuration features added to NIDES for the Alpha-patch versionwere accessed either ma an external configuration file that a user could edit to make configu-ration changes or via UNIX environment variables that would be configured prior to runtungIJIDES. Since the NIDES user interface was scheduled to be enhanced with the next (Beta)release we incorporated user interface support for the new configuration items at that time .Only two NIDES components were modified for the Alpha-patch release - the statistical

8 IVIDES F'r:nai Report

components, and functional interfaces for each component were specified [18} and developedThe algorithms for the rulebased analysis component were unchanged, and the algorithmsfor the statistical analysis component were enhanced . The rulebased and statistical analysiscomponent interfaces to all other NIDES functions were modified to support a strict client-server model and a modular design . The alpha release also included a comprehensive userinterface that supported access to all NIDES capabilities and contained a context-sensitiveon-line help system for all NIDFS functions A complete NIDES user manual [24] was in-cluded with the alpha release as well Automated installation procedures were added tothe first release to facilitate ease and success of system iwstallation . All subsequent releases(alpha-patch, beta, and beta-update) were based on the architecture developed for the initialNIDES offering. See Section 2.5 and [8] for more information on the HIDES architecture .

Statistical Analysis Algorithm EnhancementsUnder the HIDES Alpha release the statistical algorithms were modified so that they couldbetter model not just historical modes of behavior but also individual deviations about thesehistorical modes . With the Alpha release and all subsequent releases the algorithms wereno longer dependent on parametric distributions and a better representation for multimodalbehavior was developed that could comprehend the behav ior of subjects who, for example ,might spend part of the ir computer activity in document preparation with intermittentperiods of something significantly different such as financial analysis .

Some of the key changes made were :

. Enhancement of the definition of the transform from Q to S, permitting scoring of useractivity by how unusual it is rather than by where it is on the range of possible activity

. Introduction of intensity and audit record distribution measures

. 'lreatment of formerly continuous measures as categorical from a computational stand-point

2.2 Alpha-patch Release


Software Prototypes 9

3. Profile Cache Size for Statistics C lient

analysis component (etats-client) end the batch analysis component (batch-analysis)

The three configuration features added to the Alpha-patch release were

1. File/Directory Categorical Measures

The statistical analysis component includes two categorical measures that store file anddirectory-related activity as bs#s. It was discovered that these lists could become verylarge, possibly on the order of several thousand items, and computations performed onthese lists would become more time-consuming as the list grew . We also observed thatmany of the files and directories in these late were of a transitory net= and thereforeof little interest to the statistical analysis Hence, the following changes were made tocombat these problems:

• Category List Processing AlgorithmsThe processing algorithms for category lists were improved so that the entire listneed not be traversed each time the corresponding measure was observe d, thusspeeding up the per-audit-reoard processing in the statistical component . As aresult, some computation had to be "pushed bacY'to the profile updating process,and hence the profile updating process takes a little longer . Because this processoccurs only office a day, the performance difference at update time is negligible .

• Temporary File ConfigurationA new feature was added to allow a NIDES system administrator to configure alist of transitory files and directories . These files are ignored by the statisticalcomponent and hence reduce the number of files and directories in the categorybets for the relevant measures . For the Alpha-patch release this list of temporaryfiles was stored in a file called top_config located under the $IDES_ROOT/etcdirectory .With the Alpha-patch release the default tmp couf ig file contained two defaultentries /tmp/ and /var/tmp/ . Additional entries defined in the tmp_cantig fileare automatically added to the list. Duplicate values are eliminated, and the final]yet is sorted so that pattern searching can be done efficiently . The tmg conf igfile was replaced by user interface support in the NIDES Beta release,

2 Timestamp Profile Update ModeA second feature included in the Alpha-patch release was the ability to have the real-time NIDES optionally update profiles based upon the audit record tLmeetannps in-stead of the system clock (the original Alpha release updated profiles using the systemclock only) The user can configure the updating mode via the environment variableIDES_USE_TIIMFSTAMPS. If this variable is not set, the system clock value is used todetermine when profile updating should occur . The environment variable configurationof this value was replaced by user interface support in the Beta release .


20

One of the primary areas of overhead processing in NIDE3 is the management of thestatistical profiles A caching mechanism was added to the Alpha-patch release toenhance profile management, and allow a HIDES system administrator to set the fuzeof this cache as appropriate . If an organization has a large number of users or if thetarget systems generate a large number of file- or directory-related audit data activixtp,setting the size of this profile cache to a number smaller than the total number ofusers in the monitored environment reduces the size of the statistics process . This mayimprove performance because NIDES processes should not swap as frequently . Forthe Alpha-patch release the size of the profile cache m set via an environment variableNIDES_STAT_CACHE_9IZE. The default cache size for the Alpha-patch release is20, which is used if the environment variable is not set_ The environment variableconfiguration of the profile cache was replaced by user interface support in the Betarelease.

*Optimized profile storage structure

@ Real-time configuration of NODES analysis

• Configuration of NIDES batch analysis

*Expanded status reporting

• Data management facility

• Expanded rulehaga

MMES Final Report

2.3 Beta ReleaseThe first version of the Beta release represented a significant increase in the functionalityprovided by IVIDFS.

2,3.1 Documentation

Along with the updated software, an updated and greatly expanded user manual [2b] wascompleted. Subsequent to the delivery of the release, an updated software design documentwas also completed [3].

2.5 .2 Features

These key features were addedd to the HIDES prototype in the Beta release :


1 1

2.3.2.1 Optimization of Profile Structure

Some the NIDES user community expressed concern about the storage needed for subjectprofiles used by the statistical analysis. Moat of these users had large numbers of subjects ,and NIDES generates two files for each subject in which statistical information (the currentor short-term profile and the historical or long-term profile) is stored.

An analysis of the data structures used to store the statistical profiles was made todetermine i f fields could be removed or reduced in size, The HIDES Beta release achieved amore compact profile representation than the Alpha releases by elimin tYng excessive use ofthe type double as well as by removing some large matrices that were no longer used . Byreducing the number offields in the structures and reducing the size of several fields we wereable to reduce the baseline size of the two files by 62%. Table 2 .1 shows the sizes for theAlpha version versus the sizes for the Beta version . The benefits realized by this reductionwere that the amount of d isk space needed to store subject profiles and the process size of thestatistical analysis were reduced, thus increasing performance by decreasing the amount ofswapping . Because the profile structures were modified , profiles generated under the HIDESAlpha releases cannot be used in the Beta releases.

Alert Reporting Configuration As with the Alpha release, the user can configure themethod used to report anomalies. Current options are e-mail reporting and popup windowreporting . With the Beta release the user can add or delete e-mail recipients at any timeduring NII?ES operation via the user mterface

Software Prototypes

Table 2 . 1: NIDES Baseline Profile Structure Size Comparison

2 .8.2.2 Analysis Configuration (Real-time an d Batch)

The NIDEB Beta release represented the first HIDES version that supported user configura-tion of most aspects of the NIDFS analyses pro cess. The follow ing items became configurableunder the HIDES Beta release For a more complete discussion of the releaseh configurationoptions refer to [25] .

Target Host Target hosts can be added or deleted from the list of available target basteat any time during NIDES execution . The Beta release user interface contains a completefacility for editing the target host list and configuring each target boat .


Remarks For each instance created , the user can enter or update information in a log .The recorded information could include experiment notes and configuration changes

12 IVIDESFinal Report

Alert Filter The configuration of alert filters is a new concept introduced with the Betarelease. Users may suppress real-time alert reporting for selected subjects by configurationof alert filters . Rulebased and/or statistical alerts can be filtered for any subject known toNIDES

StatisticalAnalysis Most parameters of the NIDES statistical analysis component areconfigurable under the Beta release . All the statistical configuration items are accessedthrough the HIDES user interface . The following statistical items can be configured :

r Measure parameters -Scalar, half-life, QMAX, minimum effective-N, and measurestate (On or Ofd

. Global parameters - training period, profile half-life, cache size, red and yellow thresh-olds, and rare category probability isum

. Category class lists

. Profile management functions - copying, replacement, and deletion of subject profiles

* Profile updating --- update trine determination (audit record timestampa or systemclock, updating state (ON or OFF) globally or on a subject-by-subject basis (real-time analysis only)

. Profile aynchmnxzation - under the batch mode of operation subject profile updatetimes can be synchronized with the audit data used for the batch run

Rulebased Analysis Two new features were added to the Beta release that allow the userto modify the rulebased analysis component during runtime. New rules may be compiled,installed, and then added to the real-time or batch analysis processing . Rules already avail-able to NIDES may be turned ON or OFF dynamically during runtime (real-time analysis)or during the test configuration process (batch analysis mode) .

Result Filter Each NIDES analysis result is assigned one of three levels, SAFE, WARN-ING, or CRITICAL. With the result filter configuration option a user can determine whichlevel 6f results is written to the NIDES result database. By restricting the results that arearchived, the user can reduce the amount of disk space required to store the analysis resultsand improve HIDES performance .


13

2 .8.2.3 Status Reporting

Many users of the initial Beta release provided SRI with valuable comments on the software .Some of the feedback described bugs which we attempted to correct in the Beta-updateversion. These bug fixes occurred in the following areas :

Software Prototypes

With the NIDES Beta release the status reporting functions provided under the Alpha releasewere greatly enhanced in response to user feedback . The Beta release provides status reportson three areas :

• System StatusNIDES reports the state (ONlOM and throughput numbers for the NIDSS analysisand archival processes . Numbers reported include audit record and alert counts sincea process state change and during the most recent hour .

• Target Most StatusNIDES reports the configuration (ON/OFT) and the status (UP/DOWN) of eachknown target hook Audit record and alert counts for each target boot since its ectirra-tian and during the most recent hour are also reported .

• Experiment StatueFor each active batch analysis process the number of audit records processed and alertsgenerated are reported periodically (approximately every 10 seconds) .

2 .3 .2 .4 Data Management Facility

A comprehensive data management facility was incorporated in to the Beta release to supportarchival and retrieval of audit record and result record data . The Beta release user interfacecontrols data archival and review of the contents of the various HIDES databases . The batchanalysis facility can use data stored in the audit record database .

2 .8 .2 .6 Expanded RulebaseThe number of alert-generating rules was increased from 21 for the Alpha release to 39 for theBeta release . Rules added to the Beta release detect auspicious FTPITFTP use, paranoiduser behavior, suspicious remote execution, and truncation of log files . Table 2.2 ebnwa therules included with each IJII)E5 release .

2 .4 Beta-update ReleaseThe final release, the NIDE4 Beta-update, includes bug fixes, performance improvements,and expanded features .

2.4.1 Bug Fixes


HIDES Mmal Report14

Table 2.2: NIDES Default Rules


is

2.4.2 Performance ImprovementsNIDES users reported performance degradation on certain types of data fiZee. These userssupplied samples of audit trails that appeared to exacerbate the performance degradation,and SRI performed an analysis of those audit trails . It was discovered that the audit trailscontained examples of single users who had accessed on the order of 100,000 to 300,000unique files over a four day period . The slowdown was attributed to the statistical analysiscomponent. For each file a user accesses, a file category is created . While the daily profileupdating removes moat rarely seen file categories from a used profile, the daily processingof each file category was too much for NA}E5 .Over 90% of the files seen would normally notremain in a ueei profile after the daily updating was completed . SRI devised a method forpreventing these files from becoming categories if it was likely that they would be droppedfrom the profile the same day they were added .

We implemented a temporary list of newly observed categories ; the members are pro-moted to become actual categories in a ueezi profile only after they are observed enoughtimes to indicate that they are likely to enter the permanent category list at the next update .This lot is bounded in size and drops categories for winch the observations are too few and/ortoo distant in time, so that the category list will not grow without bound . NIDES dropscategories for which the historical probability falls below the system constant MINPROB .In situations where explosive growth in new categories is observed, most new categories donot achieve high enough counts to make their probability exceed MINPROB, and thereforethe categories axe dropped at the first update after their initial observation. However, thesecategories severely cluttered the short-term profile until the next profile update . To solvethis problem, a temporary category is created that is not promoted (i.e., added to the ac-tual short-term profile) until its observed count exceeds the product of MINPROB and thehistorical effective n . This causes the promotion of just those categories that are likely tobecome part of the historical profile at the next update . Other newly observed categoriesare kept in the temporary list, with a provision for being removed from the list once it isfull. Removal is based on category rank, which is based on observation count and time oflast observation, with higher ranks corresponding to categories that an seen more frequentlyand recently When a profile update occurs, the temporary category list Is cleared and anew list is started

SRI performed some initial experiments to evaluate the performance gain realized by theimprovemeate made to category management functions . In cases where the audit trail did

Software Prototypes

• Audit data set functions

• Test Setup & Exec Menu option

• Profile update processing

. Confirmation windows

• audit2ia utility program


not contain a large number of unique files, performance improvements were slight. However,during running of the audit trails that had initially brought the problem to light, perfor-mance improvements were dramatic, and in some cases experiments that would not run tocompletion on a minimally configured Sun workstation because of memory limitations wouldeasily complete in a matter of hours .

Table 2.3 shows some of the statistics collected during our performance testa .

Previous versions of A1IbE8 relied upon agen processes written m C and compiled for thetarget architecture (namely Sun SPARC) . Thus, the number of different platforms thatHIDES could monitor was severely limited . In an effort to permit both the monitoring of

16 N1DES .gnat Report

Table 2 3 : Beta Release Performance

An additional benefit to th is enhancement was that the sizes of user pro filea were reduced ,in some cases by a factor of 100, which improved fife UQ performance and hence NIDESperformance, and the size and growth of the NIDES statistical analysis process was reduced ,in some cases by a factor of 5 .

2.4.3 New FeaturesSeveral new features added to the Beta-update release of HIDES gnmarily focused on pm-viding a mechanism by which users could customize NIDE5 to use any source of audit data :

• Per] script agen utility

s UNIX agen monitor for Ethernets in promiscuous made

*Expanded rulebase event fact template

. Expanded audit record source codes

. Expanded audit record action codes

*'Updated installation procedures and user documentation

2.4.3.1 Pert Script ages Utility


With the addition of an audit data cus tomization feature using Perl scripts, changes weremade to the rulebaeed analysis component to support user development of P erl scriptedassns .

The event fact template used to store NIDES audit records was updated and expandedto include all data fields available in an audit record , Prior versions of the HIDES rulebasesoftware provided only a subset of the audit record fields available in NIDES, namely, the


multiple platforms and substantial site customization, we have developed a working agenprocess written in Pert

Perl is a powerful scripting language that provides access to many routines normallyaccessible only through compiled system libraries . Furthermore, Per] is available for free,easy to install, and operational on a large number of different operating systems and hardwareplatforms.

The Perl ages has table driven audit source customization that is simple and flexible.Users may enter multiple audit data sources in the Perl agen configuration file and thensimply writs a script to convert each data source into HIDES audit records. Library func-tions, which generate HIDES audit records, are included with the software to facilitate userdevelopment of data conversion scripts.

Versions Developed for Bets update Release To aid users in development of theirown ages Pert scripts, SRI hoe provided two realistic sample scripts for TCP-wrapper dataand UNIX accounting data file formats . The TCP-wrapper writes log entries using thestandard UNIX ayelog facility . Three types of records are generated by the TCP-wrapper- connections, refused connections, and miBmatched host name lookups . The UNIX ac-counting data file ie fairly standard for most UNIX systems ; therefore, the Pert ages forUNIX accounting files is comparable to the regular compiled agars program that can processUNIX accounting logs on a Sun workstation The Pexl script version allows users to ana-lyze comparable data from target heats that are not guns . For the TCP-wrapper data, twoHIDES rules were written to serve as examples of how the new data might be used . Onerule looks for TCP wrapper log records that report refused connections; the other rule looksfor mismatched host names and addresses .

2.4.3.2 UNIX assn Ethernet Enhancement

The Sun version of assn was modified to determine whether the hoed Ethernet is m promu-creaus mode, which could indicate the presence of a network 'kriiEfer`that could capture users'passwords or other sensitive data Hassn discovers that the Ethernet controller is in promis-cuous mode, a special audit record is generated and passed into arpool and to be checkedfor by the rulebaeeci analysis component so that an alert can be generated if appropriateThe assn process checks the Ethernet controller every 10 seconds and reports an event toarpoal each time the controller is in promiscuous mode .

2.4.3.3 Updated R alebasa and event Fact Template


To accommodate both existing and new NIDES users, the installation procedures and userdocumentation were updated for the fiats-update release .

Installation scripts and procedures were modified to accommodate changes made to theMDL$ directory tree and configuration changes to HIDES nilebase files . Procedures wereoutlined for Beta users on how to reuse data with the Beta-update version . Installation ofBeta-update software is sim ilar to that of previous HIDES install scripts . The user speci-fies the IDESROOT directory, and the NIDES release is installed in that directory . TheID$S_ROOT directory specified should not already eri ,at, and is created during the instal-lation process. Some post-installation stags are required for Beta users who want to reuseHIDES data or instances created under the HIDES Beta release . All NIDE3 audit data setsand archives are compatible between the two Beta versions. Users can transfer any aud itdata seta or archives to their new IDES-ROOT Area. For existing instances, profiles are com-patible and can be copied to Beta -update instances. Because of rulebase fact format changes,existing rulebaeee are not compatible with the Beta -update release . Any user-developed rulesmust be modified to take into account the modified event fact format.

Minor corrections were made and ne w material was added to the Beta release uee tmanual iZ6] , and a new version of the manual was produced [2) . A new chapter was addeddiscusses the new Perk scripted assn facility . The instaHation section was also updated .

18 NIDES Finn! Report

fields most commonly used under SunOS auditing systems . With the addition of user auditdata customization facilities in the Beta-update release it was deemed necessary that allfields in the audit record be made available to the rulebased component so that users wouldhave complete flexibility in their use of that component and the audit record format . Becausethe structure of the event fact was modified, existing rulebaeee (pre Beta-update release)are not compatible with the Beta-update release of NODES. Instances createdd and modifiedunder the earlier Beta release cannot be used with the new software . In addition, any user-developed rules that access fields in event facts muet be modified to refer to the fields bytheir new semen. The Beta-update user manual describes in detail the differences betweenthe old event fact template and the updated event fact template .

2.4.3.4 Expanded Audit Re cord Caries

To accommodate users custom ization of the NIDBS audit data sources using the new PERLscripted ages , the audit record action codes and source codes available to HIDES wereexpanded. The audit record action codes indicate the type of action represented in the auditrecord. Table 2 .4 shows the action codes available under the HIDES Beta and Beta-updatereleases . These codes are defined as an enumerated e'type.

The audit data source c odes indicate the source of the audit data. Table 2 5 shows the oldand new source codes available under NIDES . These codes am also defined as an enumerated"type .

2.4.3.6 []plated Installation Procedures and Documentation



Table 2.4 : NIDFS Audit Record Action Codes Comparison Beta and Beta -update Releases


1V7DES Final Report20

• Persistent storage

• Agency

• Agen

• Arpool

Table 2 .5 : NIDE$ Audit Record Source Codes

2.5 ArchitectureIn the HIDES Alpha release and all subsequent releases, the architecture follows a client-server model. Each NOES component now has a modular design that pies a well-definedinterface for other NIDF3 components while keeping algorithms and specific processing re-quirements hidden .

HIDES analysis runs on a host we refer to as the HIDES host, which is not monitored.The NIDES host monitors usage on a number of computers connected via an Ethernetnetwork. These monitored systems, called target hosts, communicate their audit data (in asystem-independent form called HIDES Audit Records) to the NIDES host. All interactionswith NIDES are performed on the HIDES host via the NIDES user interface Only oneuser interface rune on the HIDES host at any time . Different hosts can have the role of theNIDFS host at different times ; they cannot effectively collect data from overlapping sets oftarget hosts .

2.5.1 ComponentsHIDES comprises several components that interact via remote procedure calls (RPCs) orlibrary calls. The key HIDES components are


21

2.5.1.1 Persistent Storage

The agen process runs on each target host system that is actively providing audit data toNEDES fur analysis. The agen program reads native audit record data, converts it intoHIDES audit records, and delivers these records to the argovl process. The IDES Beta-update release comes with a UNIX version of assn , which supports three native audit datatypes - Sun OS BSM version 1, Sun OS C2, and standard UNIX accounting - and aPerl script functionality that allows users to develop their own assn scripts for other data

Software Prototypes

: Statistical analyaie

• Rulebased analysis

• Resolver

r Archiver

• Batch analysis

• User interface

The persistent storage component comprises a complete set of library-based functions thatprovide data management services to NIDES processes . The persistent storage data includethe audit recor d archive, the result archive, user statistical profiles, and analysis configu-ration information. A separate set of results data, user profiles, and analysis configurationinformation is stored for each NIDES instance .

Instances NEDES uses a storage concept called an instance to separate different versions ofthe same type of information. For example, each user-executed test has a name representingan instance of a NEDES test. All results, user profiles, and configuration information for aparticular test are identified by the name of the instance associated with the feet Each testmust have an instance associated with it, and test instances may be reused (i.e., used formultiple tests). NIDES has a special instance coiled 'teal time", which is reserved for thestorage of NIDES real-time operation (results, profiles, and configuration) information .

2 .6 .1 .2 Agend

The agend process is a daemon that should constantly run on all HIDES target host systems .The agend program is normally started at system boot-up by aII hosts that am to be moni-tored by 1JIDE3. Agend runs as an RPC server process and listens on a "well-known porefor requests to start and stop the native audit data conversion program, agen . The HIDESuser interface is responsible for sending start and stop requests to the agand processes onthe target host systems .

2.6.1 .8 Agen


The NIDES rulebased analysis component uses rules that characterize known intrusion typesto raise an alarm if observed activity matches any of its encoded rules . This type of analysisis intended to detect attempts to exploit known security vulnerabilities of the monitoredsystems and intruders who exhibit specific patterns of behavior that are known tube sus-picious or in violation of site security policy . Observed activity that matches any of thesepredefined behaviors is flagged. Starting with the NIDES Alpha release the rulebaee could beconfigured via a file rb conf ig, which supports ueeid conSgurataon of existing NEDES rulesRulebase customization capabilities were increased with the NTDES Beta release ; new rulescan be defined and compiled into the running system, and existing rules can be turned ONor OFF. Although NIDES comes with a basic rulebase designed for Sun UNIX operating eys-teme, users should customize the rulebase for their own environments and continually updatethe rules accomodate changing vulnerabilities of new system releases and newly discoveredvulnerabilities of current releases .

22 MIDES Final Report

sources. When started, the default behavior for ages is to process all available types of auditdata Typically, Sun OS target hosts have one or perhaps two (either BSM or C2, and UNIXaccounting) audit data sources . Agen is normally started by agend when the user initiatestarget host monitoring through the NiDES user interface .

2.5.1 .4 Arpool

The N1DLS arpool process c ollects audit data from the various target hosts and providesthe data to the analysis components for analysis and anomaly dete ction.

,x,6.1.6 Statistical Analysis Component

The NUDES statistical analysis component maintains historical statistical profiles for eachuser and raises an alarm when observed activity departs from established patterns of use foran individual. The historical profiles are updated regularly , and older data 'hged"out witheach profile update, so that IVIDES adaptively learns each used behavior. This component isintended to detect intruders masquerading as legitimate users. Statistical analysis may alsodetect intruders who exploit previously unknown vulnerabilities and who cannot be defeatedby any other means. StatietiwaY anomaly detection can turn up interesting and unusual event sthat could lead to secuntp-relevant discoveries upon investigation by a security officer. Thestatistical analysis is customizable: several parameters and thresholds can be changed fromtheir default values , and specific intrusion-detection "Inesaures" (the aspects of behavior forwhich statistics are kept) can be turned ON or OFF. For more detailed information on thestatistical algorithms see 120, 21] .

2.5.1.6 Rulebsaed Analysis Component


23

2.5.1.7 Re solver

HIDES runs on moat Sun 9PARCstationa . A target host computer can be any type ofsystem that can communicate with the HIDES host and has audit data conversation andtransmission software supporting its native audit record format HIDES can operate eitherin real time, for continuous monitoring and analysis of user activity, or in batch mode forperiodic analysis of audit data.

Software Prototypes

The NIDE3 resolver component screens the alarms generated by the statistical and rulebasedcomponents before reporting them to the security officer . Because typically tens to hundredsof audit records can be generated by a single user action, an unusual action could result intens to hundreds of alarms being reported by statistical analysis, in rapid sequence . Toavoid flooding the security officer with redundant alarms, the resolver filters the alarms toremove such redundancies. Alerts can be reported to the NIDES console or to a list of e-mailrecipients. Some user-configurable filters are also provided. For example, the security officercan turn off alert reporting for specific users, if it is known that they will be doing somethingunusual and would otherwise generate a lot of false alarms . Although filtered alerts are notreported, they are still logged .

2.5.1.8 ArcLiver

The NIDES archiver process stores audit records, analysis results, and alerts Browsing ofthe archive is supported through the user interface .

2.5 .1.9 Batch AnalysisThe NIDEB batch analysis facility allows a security officer to experiment with new statisticalparameter settings or new ntlebaee configurations before committing them to the real-timeHIDES operation. The HIDES user may construct test data sets from the audit recordarchive for a specific time window and set of user names . The candidate rulebase andstatistical parameters can then be tested against these test data sets concurrent with real-time HIDES operation. Test results are archived for comparison.

2.5.1 .10 User Interface

A HIDES user accesses all HIDES capabilities through the HIDES user interface . TheHIDES user interface is written using the MOTIF taolkit to operate under the X-Windowsystem. Access to the various NIDF.S funedons is provided via pulldowa menus, point-and -clw.k selections, and occasional text entry . An extensive multitiered context-sensitive helpsystem is included. The user interface includes a system monitoring facility that displaysinformation on monitored systems, the status of the audit data amhiver, an hourly summaryof system throughput, and an hourly summary of alert generation .

2.5.2 Operation


AIDES Final Report

2.5.2.1 Real-time Operation

The primary mode of HIDES operation is to analyze data and report suspicious activityin real time. HIDES can monitor numerous, possibly heterogeneous, machines. Figure 2.1shows how the various HIDES components interact under real-time operation.

Ta" mod"MWMIng 'w -------- 11.sYstMn +~ .y+tNn

binue

r ,.1"^°

aidl CI 1a

DES/Doormum oft

WI 3In"OIL ~

WAS" CAnstpis

a

~Revolver

, ra, bMAM*f*PAI"

The flow of data starts with the target boats (top of graph) . The agen process convertsdata in the target hosts native audit record format to a generic audit data format used byNIDFS and traneonits the HIDES-formatted audit data to the arpaol process running onthe HIDES boat. The arpool process takes data received from multiple target hosts andcoalesces them into a single audit record stream, assigning a unique sequence number toeach record during this process . Because IDES uses a generic audit record format, it is

24

NKMIwMd\ wMdwA

nn* .aN.yrrnuft

lbar IMutae

figure 2 . 1 : NIDE$ Process Graph (Real Time)


NIDES provides a batch mode of operation that allows the user to run NIDES testson arcLived audit data, with user-specified NIDES configurations. One or more NIDESbatch aaalye is processes may run concurrently with the re al-time mode of operation . Auser can initiate a NIDES batch run from the NiDES user interface or from the UNEC com-mand line. Figure 2.2 shows how a batch analysis process operates Once this process bagbeen started through the NIDES user interface or the UNIX command line, t he uses-epeci5edconfiguration is read from the NIDES instance database. The aucht data used for the batchrun is specified when the batch process is invoked. The batch analys is process reads auditdata from the specified archive, analyzes the audit data using the IDES statistical andrulebased analysis functions, and writes the result of the analysis to the result archive . Ifthe reporting flag is set when the batch job is started, the batch _analysis process willperiodically report its status to the user interface .


easily adapted to monitor new system types by writing a simple audit data mapping routineor using Pert scripts. The rulebaeed and statistical analysis components obtain audit datafrom the arpool process. Arpool provides an audit record to all its consumers (i .e., thoseprocesses that have made a connection to arpool for the purpose of obtain audit data)and then discards it. After the analysis components have analyzed a single audit record, theresults of the analysis are reported to the resalver .. The resolver analyzes the rulebaaedand statistical results to determine if an alert should be reported . The resolver reportsan alert to the user interface, provided the user has turned ON at least one of the alertreporting mechanisms (Le,, e-mail or popup window) . Alerts generated by the resolver inalso archived in the NMES result archive.

The NIDES user interface initiates and terminates NIDFS boat processes and the agenprocesses (via the agend daemon) .

2.5.2.2 Batch Operation


IVIDES Final Report26

u,i.rIt"

Figure 2 .2: NIDES Process Gr aph (Batch Mode)

T.at confturtlonInfonntton

R~sYI!DOM

AV& DIU

Rs~e~lt ~fi~~ Avdlt DNAJ1rchkv IlrabAr.


27

Chapter 3

Future Directions

The current HIDES prototype is a well-architected system that contains a large numberof features facilitating component rouse and configuration. The NIDES technology couldcontinue to grow and contribute to the improvement of system security in many arses . Thefollowing tasks could improve upon the current prototype and make NIDE5 a more usefultool to system security personnel :

• Technology transfer and operational evaluations

• User training and support

. Enhance HIDES security

. Network inftmmon detection

+ Intrusion detection teethed

• Comprehensive rulebase

+ Profile other entities

• Enhance component independence

3.1 Technology Transfer and operational valuationThe current NIDFS prototype software has been delivered to more than thirty sites , manyof which are U S. government agencie s. The final prototype version of NIDES, described inthis report, is the most usable and mature HIDES to date.

The NIDFS technology represents the culm ination of many years of research and softwareprototyping in the computer intrusion-detection field. Now that the HIDES technology hasmatured, the next step is to begin transfer of the technology into user environments. Theimpetus behind this technology transfer is to discover how the advanced technology developedin the laboratory applies to an end-user environment . By introducing advanced prototype


SRI can provide installation support and on-site hands-on assistance as requested . Tele-phone and email support to answer user questions and address problems is also essential .In addition, SRI can assist HIDES users in tailoring the HIDES statistical, rulebased, andagen components to best suit their environments .

28 NIDES Final Report

versions of NIDES into end-user communities, we can discover how the basic and appliedresearch that has led to the prototype has succeeded and where its methods can be improved-Technology transfer issues related to N[DES are discussed in detail in [26) .

3.2 User Support and TrainingSRI has received valuable feedback from users of both the Alpha and Beta releases . As aresult, many changes were made to the software in the current Beta-update version. Asusers continue their experimentation with the Beta-update release, the need for furtherchanges will arise. For these sites to successfully use NiDFS, our continued availability formaintenance and support is needed . As our experience with NIDES continues, additionalbug fixes and feature improvements will result in a more usable and accepted system . Theefforts to support users can be divided into the four areas described below.

3.2,1 NIDES MaintenanceWe envision the need to provide bug fixes and performance improvements to NIDES, basedon user feedback. When appropriate, SRI can obtain samples of the user data in sufficientquantity to duplicate reported problems in our own laboratory . For problems related to thefalse-alarm rate, we can make corrections to the statistics, the rulebase, and/or the resolverfiltering and decision procedures so as to produce an acceptable false-alarm rate, while re-taining the ability to detect the events of concern . For periarmance-related problems, we canconduct experiments with user data and our own data to discover performance bottlenecksThe fixes that are made may be specific to the reporting user (ie ., tuning the HIDES com-ponents for beet results in a particular momtared community) or may apply to all HIDESusers (i .e., a specific enhancement or bu g fix) . In the former case, the fix/enhancement canbe provided to the reporting user. In the latter case, the fix/enhancement can form part ofa new NIDES release .

3.2.2 TrainingBased on the success ofthe our initial training course it is clear that HIDES users cam benefitgreatly from a comprehensive course . By exposure to all of NIDE5 in a classroom setting,users can have a high degree of success and be made aware of all the capabilities NMESoffers .

3.2.3 Telephone and On-site Support


Future Directions 29

. Goal 3: System integrity. HIDES must be protected from modification of itsproceduns and system data .

For more complex problems, where lengthy interaction is required, SRI can provide on-site support by sending NIllES-trained personnel to assist a NIDES user m solving a specificHIDES-related problem

3.2.4 Configuration Management

The HIDES software resides on a secure host in a locked room at SRI that is not connectedto any network or any other machine. This host wee prepared by completely erasing itsdisks and installing a pristine copy of the Sun operating system. Following the, we ins talledHIDES source code that had been inspected and checkpointed . All NIDE$ binaries are builton the secure machine . Updates to the NIDES source code are verified and checkpointedbefore inetaltation

3.3 Security GoalsNIDFS is itself a sensitive application and has security requirements in addition to those ofthe systems whose use is being monitored X27] .

Malicious tampering with the audit data or with the analysis system itself could lead tointrusions going undetected. Ifan intruder can read the HIDES rule6ase, then the penetratedsite and other sites using a substantially similar rulebase could be jeopard ized, espec ially ifsuch knowledge is shared among the intruder community .

As is any computer system, NIDES is potentially subject to attacts. For example , anattacker may try to break the security offices account, try to cause a core dump, or try toexploit potential weaknesses in the design and implementation. Once HIDES is comp rammed,the attacker may disable the system .

The HIDES rulebaee represents explicit scenarios that are indica tive of potential systemmisuse. An attacker who obtains the rulebaee may be able to devise attack strategies todefeat the rules , and thus evade detection . Therefore , it is vital to protect the rulebase fromdisclosure to intruders and from unauthorized modification.

We consider two types of threats - tampering and reverse engineering. Either type maybe critical in a given operating environment These threats may arise from authorized usersor unauthorized outsiders. The following are HIDES security goals :

• Goal 1: Target-system integrity. HIDES must not have adverse effects on theintegrity of the target systems . ICES should authenticate interactions with targetsystems. NlIIFS should continually validate the status of all monitored systems todetect involuntary shutdown.

. Goal 2 : Audit data security . NIDFS must protect the audit data transmitted fromthe target systems to MIDES --- from browsing, alteration, deletion, or apDOfing.


30

• Goal 7: User accountability. User activities must be logged and analyzed in suf-ficient detail for the detection, by security officers and admimstratora, of maliciousmisuses of NIDES and its data, and of intrusions by unauthorized personnel

• Separation of roles

s Interpincese and server authentication

• Detection of and protection against denials of service

. Improved target system integrity/availability

Arpool target host authentication

. Smokescreen detection

• Logging of NII]FS user actions

Improvement of NMES processes integrity/security

*Improve alert reporting integrity

• Authentication of NIDES users

. Restriction of TCPIIP services

9 Protection of the rulebase and software from reverse engineering

IVES Final Report

. Goal 4: Availability. NIDFS must be protected from malicious denials of service

. Goal b : Rulebase protection . The NIDES rnlebase must be protected from unde-sired reading and reverse engineering and from unauthorized modification.

.Goad 6: User access. Access to HIDES and its data must be restricted through userauthentication within, a tightly controlled set of authorized personnel.

With the current modular architecture of NIDES, enhancements could be easily mademake NIDFS more tamper-prod and resistant to reverse engineering. These en'hq cementswind include


31

3 .4 Network NIDES

The current HIDES rulebase can be extended to include rules specific to the domain of de-tecting suspicious network activity . Several types of scenarios cann be addressed, for example :

• Host Name Spoofing. An intruder can attempt to have his host masquerade as ahod that is trusted (e.g., for NI+'S (Network Re System) or remote login service) by a targetserver by having a domain name server show the intruding lwEd address as that of thetrusted host . An intrusion detection system could check for domain name server responsesthat claim to associate the name of a truste d host with some other host IP address

Future Dirr.ctrons

Current computing environments are, more and more, massively networked Bets of work-stations, servers, maiuaframes, supercomputers, and special-purpose machines and devices .Focusing on the vulnerabilities of any mangle host may prove inadequate in such a distributedenvironment. Detection of intruders will require a comprehensive view of a network, possiblyextending to other networks gated to the local network, to detect itinerant intruders - thosewho move through many machines in many autonomous administrative domains. Applyingintrusion-detection technology to a networked computing environment will require expand-ing its scope to include the ability to detect network intrusions as well as intrusions intothe individual host machines, and to recognize patterns of activity that are spread amongmany home. The current NIDES technology could be easily extended to perform networkmonitoring and intrusion detection in three key areas -- network data callectina, rulebasedanalysis, and statistical analysis In addition, the NIDES architecture could be extendedto support multiple cooperative NIDES processes that would each be responsible for a localdomain, with a higher-level NIDES process responsible for the network that supports all thelocal domains .

3 .4.1 Data CollectionHIDES currently uses the audit data available to track both successful and failed attemptsto use network services . For example , under Sub BSM module , certain telnet, rlvgin ,and ftp events are directly introduced into the system audit stream via system calls madeavailable to application programs . Moat other services (and their related server processes)provide little or no application-level audit ing (e .g., YPlMB, NFS, SMTP). The and accessto any network service iafarm atioa, abort of rewriting the concerned system processes, isto directly monitor network packets and to synthesize network-level audit records for theexisting HIDES analysis modules . A network monitoring process could be incorporated intoNIDES to read network packets and produce canonical HIDES audit records for analysisPart of this process would entail substantial filtering of the network data prior to conversionto HIDES audit records .

8.4.2 Rulebase


2. Determine which existing technologies are most promising

82 NIDES MnaI Report

• IP Addre ss Spoofing . An intruder can have big host masquerade as a host that istrusted by $ target server by having its IP address pretend to be that of the trusted host. Anintrus ion -de tection system, if it can tell which physical network a packet comes from, couldlook for packets with IP addresses that should not have come from that network. Withina local network, the network intrusion-detection system could verify that IP addresses arein fact assigned to the host with the physical (e.g., Ethernet) addressee from which theyoriginate.

. Doorknob Twisting. Doorknob tvvisting;'refers to service access attempts thatmaybe harmless individually, but taken together probably represent a break-in attempt.

For example, an a network that allows remote connections (or connections to certain servicessuch as ingm) from only a limited set of hosts, a series of connection attempts within a shorttime fmm a variety of unauthorized hosts is likely to represent a serious break-in attemptrather thaa simply someone poking around. A network intrusion-detection system couldwatch for such patterns .

5.4.3 Statistical MeasuresThe NIDFS statistical component is easily adaptable to network intrusion detection with areinterpretation of subject and action but otherwise no algorithmic changes. For networkauditing, profiles entities can be network boats . For the NIDES statistical component, a setof statistical intrusion-detection measures th at are specific to network-level intrusions areeasily developed. For example, such me asures might profile the amount of traffic originatingor being received by local and remote hosts for given time s of the day and days of the weekThis information could be correlated with information receive d from audit trails, such asport number and network activity type, to build additional measures of interest .

3.5 Intrusion-Detection Testbed

Intrusion -detection technology research has been ongoing for many years, and numerousconcepts and prototypes have been developed [l3] . Many of these prototypes address specificsubsets of the security and privacy concerns of end users [28]. In addition, many securitytools have been developed both as freeware and as commercial products.

It is likely that a combination of the currently available tools can increase the securityof tode34 computer systems . The development of an intrusion- detectaadsecuritp teat6edwould be very beneficial toward the development of an intrusion -detection/security archi-tecture that oout4 provide greater protection from both external abuse and internal misuse,while still permitting the required amount of local and remote access . The goals of anintnidan-detection teethed would be to

1. Develop filters for inelgng data from different tools intemperate


33

5. Determine goals for future systems based on observed deficiencies

The Safeguard study [Z2, 22] has demonstrated the adaptability of NIDES to profile enlatiesother than users . To expand upon this, NIDES could monitor different entities at variouslevels. For example, in addition to user monitoring, NIDES could also monitor hosts, trustedprograms, user groups, and networks. Information from a single audit record could contributeto the pmffiea of different kinds of subject entities . To heffitate this prflCliug, a more flexiblemechanism for mapping between audit data and statistical measures is needed . HIDES could

Future Directions

3 . Determine appropriate tool sets for specific monitoring and performance needs

4. Compare performance and detection capabilit ies of different tool sets

The types of tools that could be evaluated and incorporated include real-time monitor-ing tools (e .g ., TCP wrapper, NID, Stalker), state evaluation tools (e .g., COPS, Tripwire ,TAM[J}, firewalls, application gateways, and other well-known network management proto-cols (e .g., DNS, RIP , SNMP)-

The NIDES Beta-update release represents one of the moat powerful intrusion detectionprototypes developed to date. With the addition of a user -configurable audit data translationutility , NIDES is now able to import data from other audit data sources for its analysis .Within the architecture of an intrusion detection testbed, the NIDES analysis componentscould analyze data generated by all or most of the teatbed systems, perform an integratedanalysis of all data collected, and determine which data are of most va lue in the detectionof anomalies .

3.6 Rulebase ExpansionThe existing NIDFS default rulebaee includes 39 rules that detect anomalies and generatealert reports . The rulabase has evolved and been expanded to address a variety of knownUNIX system vulnerabilities The rulebase development has been undertaken with the intentto provide a good baseline set of rules serving as an example of what the HIDES rulebasedanalysis can detect . The next progression for the NIDES UNIX-oriented rulebase would beto perform a comprehensive survey and analysis of known UNIX vulnerabilities; and developrules to address as many of these weakness tie existing or potential audit trails enppart .Many computer communities could contribute to the development of thi s list of weaknesses .Current NIDES users who have experience and responsibilities for system security would bevaluable sources of intrusion scenarios ; existing response teams -- CERT, for example -could provide knowledgeable insights into current vulnerabihfiea. System security manuageir sand administrators should be surveyed for their inputs and views on potential weaknesseson UNIX platforms . Operating system vendors may also provide valuable inputs.

3 .7 Profiling Other Entities


NIDES Anal Report34

3. Easy incorporation of HIDES analysis into other security systems

To achieve separation of the HIDES analysis components, the following modificationscould be made to the existing NID$,S software-

• Allow the NIDES user interface to be started or stopped without interruption of on .going real -time analysis

• Allow users to select which type of analysis is used for both real-time and batch pro .Being

• Enhance the software modules for the statistical and rulebased components to allowfor command hue invocation without use of the NiDES user interface

• Provide 'L" libraries that permit statistical and/or mlebased analysis an individualrecords

be adapted to allow a configurable mapp ing between audit data and statiatical measures, thusallowing users to configure NIDFS to profile many different types of entities simultaneously .

3.8 Enhanced Component IndependenceUnder the current architecture of HIDES [3] the real-time analysis components must be ma-nipulated via the user interface component . The user interface provides an easy mechanismto manipulate HIDES analysis and review system data. However, it would be beneficial tohave command-line or compiled library access to the separate analysis components (statis-tical and rulebased) without use of the user interface. Separate access would provide thefollowing benefits:

1. Reduced system load achieved when only desired analysis components are executed

2. Improved recovery procedures in the event of a system error, if only the componentthat caused the error needs to be restarted, all other active HIDES processes couldcontinue to operate


35

Bibliography

[2] Teresa F. Lust and Debra Anderson. Software requirements specification: Nextgeneratwan intrumn detection expert system. Final Report A001, SRI International,333 Raveavawoad Avenue, Memo Park, CA 94025, April 1994.

(2) Debra Anderson and Thane Frivold Alfaneo Valdee . Next generation intrusion detectionexpert system (NIDES): Software users manual;- computer system operators manual(beta-update release). Manual, SRI International, 333 R,avenewood Avenue, MenlaPark, CA 94025, December 1994.

[3] Debra Anderson, Thane Firivold, Ann Tamara, and Alfoneo Valdes . Next generationintrusion detection expert system (NIDES) : Software design document and version de-scription document Document A002 and A005, SRI International, 333 RaveaewoodAvenue, ll?eyato Park, CA 94025, July 1994 .

[4] J. P. Anderson. Computer security threat monitoring and mwR2lanc& Technical report,a P. Anderson Company, Fort Washington, Pennsylvania, April 19W .

[6) H. S. Javitz, A Vatdes, D . E. Denning, and P. G. Neumann. Analytical techniquesdevelopment for a statistical intrusion detection system (SIDS} based on accountingrecords. Technical report, SRI International, Memo Park, California, July 1986 . NNotavailable for distribution .

E6) T. F. Ltmt, J. vas H,orne, and L . Halals . Automated analysis of computer system audittrails. In Proceedings of the Ninth DOE Computer Secunly Group Conference, May1986.

[7] T. F. Lunt, J. van Home, and L Halme . Analysis of computer system audit trails --initial data analysis . Technical Report TE-86009, Sytek, Mountain View, California,September 1985.

[S] T. F. Lent, J. van Hoxne, and L. Halme. Analysis of computer system audit trails -mtrusion characterization. Technical Report TR-85U12, Sytek, Mountain View, Cali-fornia, October 1985.


AWES Mnal Report36

(2U] Harold S . Javitz and Alfonso Valdes . The NIDES statistical component description andjustification- Annual report, SRI International, Menlo Park, CA, March 1994

191 T. F. Lent, J, van Horse, and L Halme . Analysis of computer system audit trails -feature identification and Selection. Technical Report TRr854f&, Sytek, Mountain View,California, December 1985.

[].D] T . F. Lust, J , van Horse , and L Halme. Analysis of computer system audit trails- design and program classifier . Technical Report TR •660U6, Sytek, mountain view.California , March 1986 .

(11) J. van Home and L Halme . Analysis of computer system audit trails - training andexperimentation with classifier. Technical Report TR-85x06, Sytek, Mountain View,California, March 1986 .

[12j J . van Home and L. Halme . Analysis of computer system audit trails - final report .Technical Report TR.86007, Sytsk, Mountain View, California, May 1986 .

[13] T . F . Lust. Automated audit trail analysis and intrusion dete ction: A survey. InProceedings o/ the 11th National Computer Security Conference, October 1988 .

[14] Aviv Bergman. Intrusion detect ion with neural networks . Technical Report A012, SRIInternational, 333 Ravenewoad Avenue, Menlo Park, CA 94025, February 1993

1161 Peter G . Newness. Security and integrity controls for federal, state, and ]Deal computersaccessing NCIC. Technical report, SRI International, 333 $avenawood Avenue , MemoPark, CA 94025, June 1990.

[16] Teresa Lust, Ann Tamara, Fred Gilham , R . Jagannathan , Caveh Jalali, Harold Javitz,Alfonso valdes, Peter Neumann, and Thomas Garvey . A real -time intrusion-detectionexpert System (IDES). Final technical report, Computer Science Laboratory , SRI In-ternational, Memo Park, CA 94025, February 1992

[17] H S. Javitz and A . Valdea . The SRI statistical anomaly detector . In Proceedings of the1991 IIEEE Symposium on Research in Security and Plriuaey, May 1991 .

[1S] R. Jagannathan, Teresa Lust, Debra Anderson, Chris Dodd, Fred Gilham, Caveh Jalali,Hal Javitz, Peter Neumann, Ann Tamara, and Alfoneo Valdea. System design document-Next-generation intrusion detection expert system (NIDES). Technical Report A007,AOQB, A009, A010, A012, A014, SRI International, Menlo Park, CA, March 1993 .

[19j Harold S. Javitz, Alfonso Valdes, Teresa F . Lunt, Ann Tamara, Mabry Tyson, and JohnLowrance. Next generation intrusion detection expert system (HIDES ); L• Statistics]algorithms rationale ; 2: Rationale for proposed resolver . Technical Report A016, SRIInternational, 333 Rsvenawood Avenue, Menlo Park, CA 94025, March 1993


[2f] Alfonso Valdes and Debra Anderson . Statistical methods for computer usage anomalydetection using NIDES . In Conference on Rough Sets and Soft Computing November1994 .

[22] Debra Anderson, Teresa Lent, Harold Javitz, Ann Tamaru, and Alfansa Valdes . Safe-guard final report : Detecting unusual program behavior using the NIDFS statisticalcomponent. Final report, SRI Internateoaa1,11+lenlo Park, CA, December 1993.

[23] Debra Anderson . Next generation intrusion detection expert system (Hides) : Softwaretest report. Technical Report A004, SRI International, 333 Ravensavaod Avenue, MenloPark, CA 94025, October 1994 .

[24] Debra Anderson, Christopher Dodd, Fred Gilhnm, Caveh Jaleai, Ann Tamara, andMsbry Tyson. Next generation intrusion detection expert system (NIDW: User man-ual for security officer user interface (SOUi) . User manual, SRI International, 333Ravenewood Avenue, Menlo Park, CA 94025, March 1993 .

[25] Debra Anderson, Thane Frivold, Ann Tamara, and Alfianaa Valdes. Next generationintrusion detection expert system (NIDF.S): Software users manual ; computer systemoperators menuaj. Manual A006 and A007, BE International, 333 Ravenswaod Avenue,Menlo Park, CA 94025, June 1994 .

[26) Debra Anderson, Teresa Lunt, and Peter Neumann. Next generation intrusion detectionexpert system (Hides): Large network architecture. Technical report, SRI International,333 Asveaswoad Avenue, Memo Park, CA 94025, November 1992 .

(2'1] D .B. Denaing and. P.G . Neumann. Requirements and model for IDES - a real-timeintrusion-detactiaa expert system . Document A005, SRI International, 333 RavenswoodAvenue, Menlo Park, CA 94025, August 1985 .

12a) Teresa Lust. Detecting intruders in computer systems . In 1993 Conference on Auditingand Computer Technology, 1995.

Bibliography sz


SRI-CSI-9a-o6, July 1994GLU PmgrammeA Guide Version 0.9. IL Jagarmn#hen and Chris Dodd

Computer Science LaboratorySRI INTERNATiUNALTechnical Reports - 1995

8R1-0SL96-01, Mareh 1995Formal Methoa e and their Role in the Certification of Critical Systems, John Ruabby

SRI-CSL4)642, January 1095Adaptive Fault-Reaiotant Systems, Jack Goldberg, Li Gong, Ira Greenberg, Raymond Clark, B.Douglas Jeaeen, Kane Kim, and Douglas'AL Wells

sax-csL-8543, January 1996Merles Farmal Verification - Seven Papers, David Cyduk Pstrzk T---An Stem P. NEhw,Pa3ieth Nsrandran. Sam Owre. Sseersnga Ral an, John Buehby, Natstgjsn Shsntar, Jeoe Ulr&Bkakbebeek Mandayam Smaa and Pbedrich van Henlne

SRI-C9Ir86 04,July 1995Formal Verification of a Commercial 11fieroFrocessox . Steven P Miller and Minds7am srivaeSRI-CSires -oa, July isasExecution Driven Distributed Simulation of Parallel ArcbitACturea, Lvia 'Ricm+ilh , Patrick Lin-ok and Joe& Mm gtrez.

SRI-C$1,96-48, May 1995Detecting Unusual Program Behavior Using the Statistical Component of the NextgenerabonIntrusion Detection Expert System {IUDES), Debra Anderson, Teresa F. L=t, Harold isvitr,Ann Tom, and Atronso Valdes.

SRI-CSI,-96-07, May 1995Next Generation Intrusion Detection Expert System (NIDES) . A Summary Debra Anderson,Thane F*mtd, and A1{aaea Valdes

SRI-C9ir96 -08, June 1995Correct Schema TvaneFarmstiaoa. ]Ciaotei $ian.

SRU,4L-96 -09, June 1995query Folding, ]Gaelai Qian_SRI.CSGeb-11, June 1996Architecture and Technique s for Fast ComputerTomography. Iskepder Ap.

Technical Reports -1987 -1 95 .1

SW-C91rB4-41, January 1994General Logica and la gicd Frameworks, Nardw MestE-Qhet and Joeb Mer eguer.

SRI-CSL-94-0S, April 1994Semantic Intsmperaban: A Query Mediation Approach, 7Ciaolei Cpsa and 'lewA a LunL

SRI-05L94-08. March lostElements of Trusted Multicaehng, li Gong and Nachum $harbam.

SRI-CSIr84 .O4R, March 1899, Revised October 1994Adaptive Faul t Tolerance: Two Papers Jack Goldberg, Li Gong, Ir a Greenberg, and ThomasLawrence.

3RI-CSI.-8 4-0G, April 199 4A Formal Apparaech to Correct Refinement of Software Architectures, Mark Monmu, AmoleiQiaTk and FA Riemenechneider


SRI-CS1,94-07, April 1994Action and Change in Rewriting Logic, Naesaeo Marti-Oliet and Jae6 Meseguer

SRI-C31,94-08, May 1994Authentication, Key Dist:ibubna, and Secure Broadcast m Computer Networks Using No En-cryption or Deeayp4n . Li GongAlso mctuded: Using One-Way FunctLona for Authentication, la GongSecure, Keyed, and Callisianful Hash Functions, Thomas A Hereon, U Gong, and T Mark AI+mmaa .

SRI-CSI.-94-10, October 19947.kandvrmatinns in High level Synthesis : Formal Specification and Efficient Mechanical Verifi-cation. P. Sieeranga Rgjsn.9RI-C9I.-8A-11, May 1994Specification, 'lyranedhsmabon, and Programming of Cancuva+ent Systems in Rewriting Logic,Pack Lincoln, Narcieo Marti-Oliet and Joan Meoeguer .

SRI-CS&94-12. Aug. 1994A Policy Framework for Multilevel Relational Databases, Xiaotm Qian and Teresa F LuckSRU-CSIrB4-U, Oct. 1994Fall-Stnp Frobocala: An Approach to Designing Secure Prabocal8, La GongSRI-CBIrB4-16, Oat. 1994Rificient Network Authentication Arotoaols: Lower Bounds and Optimal Implementations, UGong .SRI-CBIr98-01, March 1993Critical System Properties. Survey and Taxonomy. John Rushby.

SRI-CSL-88-08, March 1993A Formally Verified Algorithm for Interactive Consistency under a Hybrid Fault Model, PatrickLincoln and John Ruehb3'-8R31-CS488-03, December 1993Multidimensional Problem Solving in Lucid, AA Faustiui and R . JagannathanSRI-CSL-93-04, May 1993Eight Papers on Formal Verification, Patrick Lincoln . Sam Owre, Natsreiaa 8 henkar, JohnRuahbY, end Friednch von HonksSRI-CST.-98-06, Auguet1998Rewriting Logic as a Logical and Semantic Framework Naraeo Maxti-Uhet and Jog Meseguer .SRI-C9Ir9S-0B, November 1993A Model-TLeoretic Semantics of the Multilevel Secure Relational Model, ]Ctaolei Qiaa .

SRI-C91,83-07, November 1993Formal Methods and the Certification of Critical Syatema, John Ruahby .SRI-C8Ir98-08, December 1993A Lazy Approach to Compositional Verification, by N. ShankarSRI-CST.,-93-09, December 1993Abstract Datatypea :n YVS, by N. Shanicnr

SRI-CSIr98-l0, December 1993A Duration Calculus Proof Checker. Using PV5 as a Semantic Framework, by J .U. 8ltakkebmkand N. SheulcarSRI-CSL-89-i1, December 1993Linear Lopc and Proof Theory: Three Papers, by Patrick Lincoln, Andre 5cedrav, Natarejan56aakar~ and Timothy Winkler


SRI-M"3.12, December 1993Mirmpmoesear Verification in P'V3 : A Methodology and Simple Example, by David Cyrluk

SRI-CSl.r88-1S, December 1993The Complexity and Campoeatrility of 8ecm Yatemperataon. by Li Gong and Xinaki fan .

SRI-C5L9&Ol, July 1992Formal vanficati oa of an anal lunges a%Pnthm car Interactive Cbnaceacy~ by John Ruabbr-

51RI•CSIreP.-02, July 1992Nomatsdereaoe,'!'raneitivity, and Channel-Coatso] Security Pobriee, by John RWehby.

SRI-08498-N, March 1992Introducing OBJ, by Joseph A Goguen, Timothy Rliflk3ar, doeE Meeaguer, Bobchi Futatsup ,and Jean-Raft JouannaulL

SRI-C8L~9l-04. March 1992Survey of Obiect•Dtieated Aoa]TaialDaeoign Metbadolopsa and Future CASE Framework@, byDonu.sn Hmah

8RI-C$L-9Z-05, April 1992A Real-Time Iatrvoon-Detection Expert System O DEBf, by Teresa F. Lunt, Ann Tsma% FredGilbaw, R JageoAathan. Csveh Jalali, and Peter 0. Neumann.

SRI-CA1 9Y--08, May 1992Maltiparadigm logic Rwgrnmmine, by Joel Meeeguer .

SRI-CSL-92-07, July I992Simulation and Pedatmenoe Frhmation for the Rewrite Rule Machine, by Hituaba Aide . JosephA aoguen, Sang I.ewvvand, Patrick LiaQala, .load Meeegner, Babak Taheri, and Timothy Wm•Idea.

SRI .CSI,•9t-08, July 1 992A l aoical Theory of Concurrent Objeete and its Reahxsboa m the Maude Language, by JoshMOGRUMSRI-C61Ir9Z-08, Sept. 1992On the 3emantce of PIaceI!'reneitian Petri Nets, by Josh Meeeguar, Ugo Moret aneri, andVladim:a Saeeone.

SRI-CSir9S 11,13Ypt .1992Umag Plawriting Iopa to Specify, Program, Tntepxta, and Reuse Open Concurrent Systems ofCooperating Aseat e, by dosE Mesaguer, ISnkwhi Pulsteui& end Timothy Winkler.

SRI-C8Ir8s-18, November, 1992Mechanized Verification of Itsd-Time Systems Using PVS, by N . Shankar.

BN-C3492-13, December, 1992dLu: A Hybrid Language for Parallel Applications Programming. by IL Jagannathan and AAFknetiai

8Al-C9I.-92-14, Detemher, 1992Solving the Inheritance Anomaly in Concurrent Object- Oriented Programming, by doed

9R]-CSIr9!-16, December, 1992A logical Semantico for 06ject-Orioutsd Databases, by Jaet Me.s6oer and ]Gao2ai man .

8S1-=41-41, Yebsuas7 199]Multilevel Security for Knowledge Based Syetem Q , by Thomas D. Garvey and Teresa F. bunt

SRI•CS"1-0l, February 1991An 1ntr adadfan to Fbrwal Specification and Verification Using FoK by John Ruebby, iriednchvon Heaka, and Sam Owre .


SRI-C6Ir8Y-OS, June 1991Formal Specification and Verification of a F'aulw Maeking and Transient-Reoovery Model forDigital Flight-Control System . by John Rushby.

CHI-CSlr91-04, dune 1991Mechanical Verification of a Schematic Protocol for Byzantine Fault-Tolerant Clock Synchro-nization. by N . Sbeakar

SR14211r91-06, February 1981Conditional Rewriting Logic as a Unified Model of CancurreacY, by Joe6 Meeeguer .

SRI-C8Ir81-08, March 1991Final Alpbae, CoeenmoQmvAahle Algeheae, and Degrees of Uneo}vabo'htY, by Lawrence 3_ Was,Joel Maseguer, and Joseph A. Goguea

SRI-CSIr91-07, April 1991From Petri Neta to wear Logic Through Categor ea: A Survey, by Narcieo Ma:t1-Ohet and .)osE

ff-SRI4)S[r91-08, November 1991Parallel programming m Maude, by Joeb Meseguer and Timothy Winkler.

SRI-Ca3ItY0-Ol, February 1990Duality in Closed and Linear Categories, by Nerciao Mart[•0fink and Jae6 Meaegver .

MU-CSIA0 Qtg, February 14390, Revised June Y990Rewrites as a Unified Model of Concurrency, by Joan Meseguer

SRI-C81,40- OSR, February 1990, Rev . Dec. 1990Compiling Concurrent Rewriting onto the Rewrite Rule Machine, by HiEoehi Aide, JosephGogue4 and Joe6 Mesegue:.

8EI-C81,90-64, Au6unt, 1989Secure Knawledgc•Bmd 8yeteme, by Tereea F. Lent and Jonathan IL Millen

SRI-C$1r9D-O8, Julie, 1990Ordtr-$arted Algebra Solves the Caaet3ucbax-Setectar, Multiple `Representation anti CoercionProblems, by Jae6 M+eaeguer and Joseph Goguen.

$W-CSl,-9D-07, July, 199DA Logical Theory of Concurrent Objeeta% by JoeE Msaeguer.

8RI-COLr9Q-a8, August, 1990Decision Problems for Psopaeitional Linear Lo gic, by Patrick Lincoln, John Mitchell. Andre8oedrov, and Natarejaa 8hsntnr .

SRI-C8T,r80-09, October, 1990On Location: Potato about Rsginne, by Judith S. Crow and Peter B . I.adkia

SRI-CSL-90-10, October 1990On the Design of Dependable Computer 3yeteme for Qitical Applicati ons, by Peter G. No

SRI-Gi3460-11, November 19BaThe OLD Programming Language . by R. d aganaat6an and AA. Fauatini

1381-CSIr90-}.2, November 1980Ariamnttsang the Algebra of Net Computations and Processes, by Pierpao3o Degano, Jaeb14keeeuer, and Ugo Maatgnsri. _

SRI-CSIr90-18, December 1990Semantic Sp eciCxmtane for the Rewrite Rule Machine, by Joseph A [3ogaea .

SRI-0SL-90-16, December 2990A Logic to Unify Semantic Network Knowledge Systems with Object-Oriented Database Model s,by Dnnovan Hmeh.


SRI-cstP9ais, December L9soItscluaane and 8nbtypee, by Netaea Mitt-Obet and Jaak Meesguer,

SR1-CS490.11. December 1990Architectural Design of the Rewrite Rule Machine Eneemble, by Hitoehf Aida, Sam Leis vend,end Jasi Meeeguer.

SRI-CAL-8S-1, January 1989An Inbsneional Parallel Rxnceetwg Language for Applications Progrsmmio6, by BA AeLeeaft,AA Fauetiui, and A. Jegeuanathnn

SSl-CAIr89-S. January 1989Dataflow-based Methodology for Goatee-Graua Multiprocessing an a Net work of Warlrstuboae,by R Js6annrtbaa , Alan Downing, William Znumen, and Roeaana Lee .

BBI-D.9L48-DB„ February 1889, Revised August 199]Formal YeriSeatiuA of the Interactive Convergence Clock Synchronization Algorithm usingEtmx, by John Rusbby and Friedrlch van Henke

88I4DSI,88-sR. Mareb 1989, Eev. .igne ]989Foam Petri Neta to Linear I+opc, by Narcieo Martl-0]iat and .lo eb Mesegner

SRI-C8L-89 6. March 1989.Genaa] I Vgk:e, by Joel hdeaeEuer

$SI-CSL-B9 -8, Much 196aThe Rewrite Rule Machine Project, by Joseph Gogtaeq JosE Maaeguer, Sany Leinwand, TimothyWinkler, and Iiitoebi Aide

9RI-08489-5, July 1989A Categoncal Manifesto. by Joseph A. Goguen.

SRI-C9"8-9, Sept . ]989A Practical Approach to Semantic Configuration Management, by Mark Morioom.

SRI-CBL-89-10, July 1989Order-sorted Algebra L Equaaonai Deducbcn LotMultiple Inheritanoo, Over]oading, E~cSepdoneand Partial Operatione, by Jaaep1i A. Goguen and Joe6 Meeeguor .

SxI-CBL$9-11, December 1588An Algebraic Aikimatirs4au of Linear Logic Modal s, by Tiuvso Mart{Obek and Joel llleeeguer

SRI-G4L88-I, January 1988Higbar Order Functions Considered Unnecessary fns Hag1wr Order Frogramoung, by JosephGoguen.BRI-CSL-88IR2, January 1988, Rev . 2, August 198$What Is UoMca13aa7 A Categormal View of BuDsbtutznn, Nquatton and Solution, by JosephOWUaSHI-C5488,IR, January 1988, Rev. June 1989Petri Nets Are MoaaQde, by JaeB Meascuer and U8Q Maa#aa ari .

SRI-CBIr8&4R2, Augu st 1988O&1 as a Theorem Praver with Appbcatiana to Hardware Verification, by Joseph Goguen.

SRI-CSIr68-G, May 1988A Deamptive and Prescriptive Model for Dataflow Semantics, by IL JagennetbanSRI-CSL-88-7R, Sept. 1988Quality Measures and Assurance for Al Software, by John Rushby .

SRI-GSL-89-10R, Sept. 1988, Rev. Jan 1989Cell, '1"i3e, and Ensemble Architecture of the Rewrite Rule Machine, by Joseph A. Gaguen, SanyLeinwand, and Timothy Wink]er


SRI-C9L-87-2, May 1987The Rewrite Rule Machine PYOje ct, by Joseph Cvguen, Claude Knd ner, Swop Wow" JoB6Meaepm. and '1'imuth,Y C. 11VsnIklcr.

S$i-CSL-B7-2, May 1987Cancwrsant Teem Itaavnting an a Model aE Computation, by Joseph [iogtteer~ Claude Kimhner,and Joel Mesaguer.

SRI-CSC.-87-8, May 1987An Abstract Machine for Fast Parallel Matching of Linear Patterns, by Ugo Montanari endJoseph Goguen.

SRI-CSIr87-7, July 1987Unifying F1nctms1. Object-Oriented and Relational Programming with Logical Scraftintice byJoseph Goguen and Joel Mcaeguar.

SRI-csI,sa-ii, sepL 1988Software for the Rewrite Rule Merbine, by Joseph A. Goguea and Jne6 Meseguer.

SRI-CSL-B&18, Oct 1988Relating Models of PolymozpLiem. by Job Mcacgues.

SRI•CSW8-14, Nov. 1988Reasoning about Design Changes, by Mark Moricom and Gail A Harriaan


next-generation intrusion detection expert system (nides

Documents