SAINT: A Security Analysis Integration Tool
Diego M. Zamboni
Computer Security Area
Direccio ´n General de Servicios de Co ´mputo Acade ´mico
Universidad Nacional Auto ´noma de Me ´xico
Apdo. Postal 20-059, 01000 Me ´xico D.F., Me ´xico
of Me ´xico that will allow integrated analysis of information gathered from various sources, such as secu-
rity tools and system logs. By simulating events occurring in the systems, and collected from the different
sources, SAINT will allow detection, or even prevention of problemsthat may otherwisego undetected due
to lack of informationaboutthem in any singleplace. SAINT’smodular and extensiblearchitecturemake it
feasible to add new modules for processing new data types, detecting new kinds of problems, or presenting
the results in different formats.
1Introduction — The Problem
the use of various security tools has been promoted as one of many ways of increasing Unix system security.
Until now, only freely available tools have been used, mainly because they cover most of the needs in this
particular academic and research environment.
The main set of tools used consists of COPS [FS90], TCP-Wrappers [Ven92], Passwd+ [Bis95], Crack
[Muf], TripWire [KS93, KS94a, KS94b] and SATAN [FV], although other tools (like Tiger [SSH93], S/Key
[Hal94, HA94] and the logdaemon suite [Ven]) are also used.
Experience has shown that, when need arises to diagnose a problem, the solution often comes after col-
lecting information from more than one source, including, but not restricted to, the tools mentioned above.
For example, to trace a suspicious su access to root, it may be necessary to match a wtmp record with a
sulog entry. To further trace it back to its origins, it may be necessary to match the wtmp record with a
TCP-Wrappers log entry, go to other systems and repeat the log analyzing and matching until all the needed
data is collected. The information is available, in many cases, but it is scattered all over several systems and
in different formats, and it has to be collected and analyzed manually to get something more useful than just
a collection of facts.
Therefore, the problem can be summarized in the following points:
To achieve acceptable levels of security, it is necessary—among many other things, of course— to use
several different tools, each one of them working in something specific (and, many times, even dupli-
Each one of these tools generates data on its own, and in different formats.
To have a more complete view of what is happening, the system and/or security administrator has to
read several reports and logs generated by the tools, often over a period of time.
The correlations and matching between related items in the different logs has to be done manually by
?Originally published in the Proceedings of the 1996 SANS (System Administration, Networking and Security) Conference, Wash-
ington D. C., May 12–18, 1996.
In Mexico (and other non-English speaking countries, for sure), the fact that all the generated informa-
tion is in English poses yet another problem. Although English is the lingua franca in computing, it is
still a barrier for people (including many Unix system administrators) using computers in Me ´xico.
This can, and does, lead to mis-utilization of the tools, which just sit there collecting mountains of data
that nobody never uses. Recently, some tools have been released that allow easier viewing of generated data
(most notably CIAC’s Merlin[CIA]), but the problemstill remains of making an understandablewhole of the
seemingly chaotic set of reports and log files.
That is why SAINT’s idea was born: to make a system that allows integrated analysis of data collected
from various sources, and tries to extract interesting information to be presented to the administrator in an
easy to read format.
ThispaperpresentsthedesignofSAINT,which isstillunderdevelopmentatUNAM’s ComputerSecurity
2 Related work
Log file analysis is not new. In fact, it has been used for many years. In the simpler end, there are tools like
searching for certain patterns and doing something when they are found. These tools are useful for looking
for very specific things, but since the search they perform is essentially stateless, their usefulness is restricted
to looking for specific things that may indicate problems.
HCMM92], which uses a rule-basedlanguage (called RUSSEL) to process audit trails generatedby a number
of systems. In a distributed environment, ASAX runs local “evaluator” processes on each monitored host,
which submit their local results to a master server, which in turn processes the consolidated data. Although
the modelisgeneralenoughtobe portedtoanytypeofsystem,the currentimplementationisorientedtowards
SunOS 4.1 with C2 security features, and uses PVM [GBD
ASAX is a very powerful package, and its rule-base analysis makes it able to detect complex event se-
quences that may indicate problems. However, its same complexity makes it difficult to use in a very het-
erogeneous environment like ours. The recommended (C2) audit mechanisms are not in place in most of our
systems, and compiling ASAX in very different versions of Unix proved difficult.
94] as the communication mechanism between
3 What is SAINT?
SAINT provides the framework for performing the following functions:
1. Cross-analysisof reportsand logs generatedby various security tools, as well as systemlogs, in several
Unix systems. The goal is trying to detect things (or sequences or patterns of things) that may indicate
problems of any kind.
2. If it is possible, obtain information about likely causes of detected problems.
3. Warning generation when appropriate (the most clear case would be when a flagrant security problem
is detected, but there are many other situations where opportune notifications are very useful).
4. If possible, suggest available solutions to detected problems.
5. In its first version, presentation of all the results in Spanish.
The main goals when designing SAINT were:
Make it extensible. It should be easy to add new modules to the system, to make it aware of new kinds of
available information (for example, a new tool), or to modify or improve its analysis capabilities.
More information about UNAM’s Computer Security Area can be found at http://www.super.unam.mx/asc/
Make it configurable. Securityisnotthe samefor everyone,andthe usershouldbeable tospecify, inamore
or less detailed fashion, what is important for him or her, and what is not.
Make it easy to use. OneofthesecuritytoolcursesthatSAINTistryingtoavoidis“youneedtobeanexpert
to use this”. Once it is in place (and it shouldn’t be too difficult to do that too), it should be easy to use
and to review the generated results.
Make it portable. If it is going to succeed, SAINT must be usable in heterogeneous environments with as
little changes as possible. Building on the experience of other tools like COPS, SATAN and Merlin,
as well as on the experience of the people working on it, most of SAINT (if not all) is being written in
Perl5 [WS92, Wal] (why not admit it, SATAN also inspired the name).
4What is SAINT not?
SAINT does not try to be a full-featured Intrusion Detection System (IDS), although SAINT reports can be
usedtodetectintrusions. IDStechnologyisbynowfaraheadofSAINT’sdesign. Advancedworkonthistopic
is being done, among others, by Crosbie and Spafford [CS95a, CS95b], Kumar and Spafford [KS94c, KS95]
and Kumar [Kum95].
SAINT is intended just as an information analysis tool. This point made, let’s proceed with SAINT’s de-
5 What does SAINT do?
SAINT’s operation can be divided in four big phases:
1. Data collection and homogenization.
2. Event sorting.
3. Event analysis.
4. Results presentation.
Each of this phases is described in detail next.
6Data collection and homogenization
SAINTneeds toprocessdata producedby varioustoolsand, possibly,variouscomputer systems. To facilitate
further processing, the first stage in SAINT’s execution consists in getting the data from all the sources that
will be used, and converting it to a common data format that makes it easier for the next stages to process.
This task presents the following problems:
1. The information produced by each tool comes from different places, and it is in different formats. The
process of converting to the common data format is different for each data type.
2. Data formats used by some tools may change in future versions of the same tool.
3. It must be possible to add support for new tools (or new versions of existing tools) without modifying
4. The common data format must contain all the information that may be useful for processing.
For the first 3 points, the given solution is using different program modules for each tool. These mod-
ules are independent programs that are used by SAINT (according to its configuration file) for getting and
processing each tool’s data.
This gives the following advantages:
Each module is specialized in only one data type, thus it may be very simple and easy to test.
Each module can be written in the language that is most appropriate for the kind of processing to do, as
long as it complies with SAINT’s interface specifications.
Eachmodule canget the datafromwhereverit isappropriate. Itmay get it fromafile, fromthe network
or from another program. This process is transparent to SAINT, sinceit is performedinternallyby each
Modules can be easily added, replaced or modified to deal with new tools or new versions of existing
tools, to correct problems or to improve processing efficiency.
The design of the common data format had to meet the following goals:
Completeness: It must include all the information it gets, only in another format. Its output must be in the
form of “events”, that is, discrete pieces of information as concise and simple as possible, to simplify
in the format.
Simplicity: It must be easily processable by a program. This implies that the fields must be easily distin-
guishable, and that the contents of each field must belong, as far as possible, to a finite and predictable
The common data format is composed by lines of text representing events, and each line includes the fol-
Event type: A keyword that allows classification of the event. These are assigned arbitrarily, according to
the events the system must recognize. Some of the event types currently recognized are:
Most of these types are self-explanatoryand need no further discussion. Perhaps it is worth explaining
su_root, su_user and port_connect. The first refers to an su command executed to get root access, and
the second refers to the same command used to get access to a non-root account. These events were
separated since su’s to root normally require a much stricter analysis.
Port_connect representa connectionto any TCP/IPport in the system. This canbe useful, for example,
to detect port scans, failed login attempts, etc.
new event types, as long as they deal correctly with them.
Event date and time: Since the analysisperformed will be chronological,it is important that each event has
a time stamp, whereverpossible. If the original datadoesn’tinclude dateand time, one oftwo solutions
may be provided:
1. The corresponding module may be able to estimate the time when the event happened (for exam-
ple, by interpolating from other known data). This is the preferred solution.
2. Leave the field empty, in which case the event will be considered as having happened before all
Event source system: When the event involves an access through the network, this field identifies the orig-
Event destination system: The destination system for network events.
Event source user: Forsomeeventsit ispossibletofindoutwhich usergeneratedit, andthe informationcan
be useful in the analysis.
Event destination user: Itmayalsobeusefultoknowwhichuser“received”theevent,forexample,atelnet
session or an su.
General purpose field: It was considered appropriate to have a field whose meaning depends on the event
that is being registered. Some examples of what this field may contain are:
Process ID for the daemon providing a service.
Flag indicating success or failure of an operation.
Relevant environment variables.
File name in an FTP transfer.
Command executed by rsh.
Terminal name for an interactive session.
Reason for reboot.
Original message: Itisimpossibletoforeseeandclassify allthe informationthat,atanygiven moment,may
data format the original message from which the event was detected. This will allow to performon this
should be substituted by their common escape-character sequences (for example, \n for a newline or
\t for a tab) or their ASCII code representation in octal (for example, \014).
The format used for each record in the common data format is as follows:
Where the fields appear in the order they were previously mentioned. The vertical bar character (|) was
chosen because it is rare in most of the reports we have seen. In case it appears in a field, it should be escaped
(\|) before storing it.
The analysis performed on the events will be necessarily chronological, since this facilitates the detection of
data format, they will be sorted according to their time stamps.
Events whose second field (date and time) is empty should be left at the beginning of the list, in the order
they appeared in the event collection stage.
It isimportant tomention a possibleproblem here: ifthe clocksin the systemsbeinganalyzed are not cor-
rectly synchronized(more than a fewseconds difference), this stagecouldprobably leaveeventsina different
order than they originated. This could affect the analysis results.
This is the stage that does SAINT’s central work. Based on the data collected and processed in the previous
stages, an analysis must be done that allows detection of relationships among events and trying to decide if
these events are part of the systems’ normal operation or represent possible problems.
Two approaches were considered for this analysis in the design: parsing and event simulation.
event would be a token, and the grammar would detect special token sequences.
This approach was discarded for the following reasons:
Relevant event sequences may be too complex, and may not even be predictable.
ifications. This greatly diminishes the expandability capabilities planned for SAINT.
mars excessively complex or even impossible to develop.
Many event sequences may be similar or even exactly the same, and yet represent different things. De-
terministic and finite-lookahead grammars have very hard times dealing with these kind of things.
This techniqueconsists of doinga simulation, inside the program, of the eventsthat affect each computer sys-
are not predefined, only how the system reacts to events under certain circumstances.
A simulation is based on elements that respond to certain stimulations and interact between them. In this
case, the elements of the simulation would be:
Systems: These are the central elements of the simulation, since they are where most events are generated
and received. Each system remains in its current state until an event happens that it is programmed to
react to. Based on its current state, a system can trigger certain actions (such as reporting a possible
Security domains: In this case, security domains refer to groups of systems that share some characteristics
related to security. The most common security domain is a group of systems that “trust” each other (at
least as defined by the SAINT configuration).
The network: It is through the network that systems interact among each other. In this case, the network is
considered only as a passive transport element, since we are notconsidering it as being able to generate
events on its own. Thus, it is not considered in the simulation.
Given this view of things, the simulation technique seems appropriate for doing event analysis.
The method used for implementing it seems to suggest itself. Object-oriented programming allows us
to define objects (in this case, systems and domains), each of which can have its own characteristics, have
an internal state, can communicate with other objects, and can react to messages received from other objects.
technique for implementing it.
Here we faced another problem. Most of the “traditional” object-oriented languages (C++, Objective-C,
Smalltalk, etc.) are not portable enough to allow us to easily use SAINT in a wide variety of systems. The
choice was Perl5. In its latest incarnation, Perl includes object-oriented capabilities. This, along with Perl’s
great flexibility, portability, and the fact that it is free, made the decision clear. Most, if not all, of the original
SAINT modules are being written in Perl5.
It was considered that the object classes used in the simulation must be the following:
Systems: These objectsmust contain a representation of all the factorsthat may affect, at any given moment,
the system operation. The state of a Unix system, for our initial purposes, can be summarized with the
Active sessions of any kind (telnet, rlogin, ftp, etc.) Each session has associatedinforma-
tion about the user it belongs to, assigned terminal, date and time, etc.
Existing processes. Not all the processesare relevant in the analysis, but those that are significant
(for example, those triggered by events in the simulation) must be tracked. Each process has as-
sociated information about the user it belongs to, associated terminal, privileges, date and time,
Files. Again, notallthe filesare relevant, butsomeofthemare worthtrackingduringthe analysis.
Each file has associated information about user and group it belongs to, size, access permissions,
pathname, date and time, etc.
Besides this, a system and its reaction to events are defined by the following characteristics:
Trusted systems and domains. Normally this information is inherited from the security domain it
belongs to (see below), but it may be changed for a particular system. Trusted systems and do-
mains may be given special privileges, like establishing sessions with administrative privileges.
Privileged users, which are allowed to do privileged administrative tasks.
Special times. Some periods of time may be defined as “maintenance” periods, where the system
may be rebooted or some special programs may be run.
Event selection mechanism. This is the entry point for events directed to the system. This mech-
anism, based on the event characteristics, sends it to the appropriate event reaction routines.
to certain events. According to the type of event and the system’s current state, the reaction may
be ignoring it, modifying the system state, issuing a warning message or a notification to other
These routines, along with the event selection mechanism, define the events a system will react
to and the problems it will be able to detect. To be able to add SAINT support for new problems,
new tools, or new system types, it may be necessary to add or modify reaction routines. Here,
the object-orientedapproach also comesin handy. Using inheritance and Perl’s great flexibilityin
interpreting code, SAINT can make the needed additions or modifications.
These are the basicelements ofa systemobject. Some kindsof systems(for example,dependingon the
operating system version) may react differently to events. For this, new classes could be defined that
inherit from the base system object class and modify their behavior (or even the data representing the
internal state) according to the specific characteristics of the new system. New analysis modules could
also add data fields or even reaction routines to increase the object’s event-reaction capabilities.
Security domains: The state of a security domain in any given moment may be defined by the following:
Connections established to it from the “outside” (systems that don’t belong to the domain).
Connections established from the domain to the outside.
The state of each of the systems that belong to it. This state is maintained, independently, by each
A domain is also defined by the following characteristics:
Domain name (for reference).
Systems that belong to it, represented by their respective objects.
8.3Performing the simulation
Once object classes are defined the steps for performing the simulation are:
1. Create the object instances representing all the systems and domains participating in the simulation.
2. Inchronologicalorder,sendeachobjecttheeventsinwhichitmaybeinvolved. Eachobjectwillreceive
the events through its event selection mechanism, and will react to it according to its internal state and
its event reaction routines.
An object may react to an event with one or more of the following actions:
Modify its internal state to reflect a change introduced by the event.
Send a message (in the form of an event) to another object, to communicate something to it.
Emit an output to be presented as a result of the simulation. All the output produced by the objects will
be passed to the next stage for generating the final report.
To facilitate communication between stages, a common format was also defined for the results of the
tioned in section 6, it contains the following fields:
Event type: Possibly using the same classification mentioned before, plus other types defined for de-
Entity reporting the event: The system or domain that emits the message.
Event priority: Each reportedevent must be classified accordingto its severity. The currently defined
0 Informative. Something notable enough to be reported, but not representing a particular prob-
1 Warning. An event that is somehow uncommon, but not directly representing a problem.
2 Alert. A possible problem that must be immediately investigated.
3 Emergency. A clear problem.
It must be observed that the priority level is assigned by the object reporting the event, so its de-
termination is left to that object’s “opinion”.
Date and time: Date and time of the event that triggered the message.
Event summary: A short description of the event, normally including the event type, affected system
or domain, and any other relevant information.
Descriptive message: A detailed description of the event, which will be included in some formats of
the final report.
The formatofthe commonreportformatis the following,wherethe fieldsappearinthe order theywere
8.4 Central data repository
During the simulation, objects may need global information they don’t have stored internally. The most obvi-
ous application is knowing which other objects exist (something like a DNS server), for communicating with
them. For this reason, one or more objects may exist that serve as data repositories which other objects may
query for information.
The last stage in SAINT’s executionis the interpretation of the messages produced duringthe simulation, and
its presentation in a human-readable format.
Having the result presentation in a separate module makes it simple to modify the result format without
modifying the program. Some possible output formats are:
1. Chronological report.
2. Reports by event severity.
3. Reports by system or domain.
4. Reports by event type.
5. Reports restricted to a specific time interval.
6. Reports formatted in ASCII.
7. Reports automatically stored and/or mailed.
8. Reports formatted in HTML, to be viewed with a WWW browser.
As can be seen, this stage determines both the contents and the form of the presented reports. The idea is
tohave separatemodulesfor each kindof report,insertingthe propermoduleinthe executionchainaccording
towhattheuseraskedfor. Thismeansthatallthe reportingmodulesreceiveexactlythe sameinformation(the
messages producedby the event analysisstage), and presentit accordingto their particularfunctionality. This
stage is SAINT’s front-end to the user.
10 Control module
Itisnecessarytohave a centralmodulethat controlsthe rest, sothe informationflowscorrectlyand theresults
are appropriately generated.
The task of this main module is pretty straightforward since most of the work is distributed among other
modules. Its activities can be summarized as follows:
1. Interpretation of command-line arguments.
2. Reading the configuration file.
3. Based on the information collected in the previous steps, set the appropriate parameters and read any
additional information (for example, load additional code modules).
4. Execute, one by one, the programs implementing the four SAINT stages. The flow of information be-
tween the stages is established using Unix pipes.
11 Configuration file
PracticallyallofSAINT’s behaviorisconfigurable. Thisisneededifweexpectthetooltobe usableinseveral
different work settings, with different needs, policies and configurations.
All the operational parameters are set in the configuration file, called saint.cf by default, and located
in the same directory as the SAINT executable.
Theconfigurationfileisa text file. Infact, it consistsof Perl5code, butmostof it are variableassignments
and other simple statements, so it is easily readable and modifiable even by someone not experienced in Perl
Some of the information that may be definable through the configuration file includes:
Information about the systems that will be simulated, such as their types, names and characteristics.
Support modules to be loaded for supporting different tools, problem-detection capabilities, system
Normal working schedule. This information can be used by the modules to detect anomalous behavior
(for example, a secretary establishing a network connection at 3 in the morning). This information can
be set in general terms and specifically by domain, system or user.
System maintenance schedule. At these times, some activities (for example, rebooting a system) may
be considered less suspicious than during other times.
Users authorized to use root. Normally, a non-authorized user using root is a clear indication of prob-
Electronic addresses from which users normally access systems.
Security domain definitions.
Trust relationships between systems and domains.
Distrust relationships, so problematic systems and domains can be immediately identified.
Default module for result presentation.
Itmustbekept inmindthatthe formatofthe configurationfileisvery free-form. Sincemostof theSAINT
or procedure calls. Each package will define its own interface with the outside world, through which the con-
figuration file can set that package’s parameters.
12 Some thoughts about SAINT
Probably the most important thing to keep in mind when using SAINT, as when using any other security and
system administrationtool, is that it is not magic. Actually, SAINT is only a data collectionand analysis tool,
so the following factors must be carefully considered:
SAINT cannot invent information. All the data SAINT uses comes from other tools and places. In-
formation it is not given cannot be taken from anywhere, although SAINT modules may be intelligent
enough to deduct certainpieces. On the other side, the more tools SAINT has to feed it, the more infor-
mation it will have to make more precise analyses.
SAINT can be only as trustworthy as the information it receives. If the data it gets for analysis has
already been modified by an intruder to hide his tracks, SAINT will never detect him.
Not discussedin this paper are matters about privacy and integrityof the information being fedto SAINT.
Work is being done in these aspects too, investigating methods to increase the reliability of the data. Some
possibilities include using PGP to encrypt traveling data, using syslog to send data to a central system as it
is being generated, and others.
Although SAINT was designed with security analysis in mind, its structure allows for it to be used for
analyzing any kind of information. It could be used for monitoring the correct functioning of other subsys-
tems such as NFS, NIS and printingsystems. Its name caneven be easily changedto “System Administration
Analysis Integration Tool.”
SAINT is not intended as a monolithic do-it-all system. Instead, it tries to define a general infrastructure
that allows modules of any level of complexity to be interconnected and to work in coordination. SAINT
modules can (and probably will) be very complex, but the general structure of the system tries to be as simple
as possible, and allows for modules to be defined to deal with any kind of problems or data.
Although this paper talks about SAINT’s ability to detect “problems”, SAINT modules can as well be
developed for detecting “things that are not normal”. Under this scheme, anything that is not explicitly con-
sidered normal should be reported. This may be preferred by some security-critical sites.
which is important due to the already installed base of security tools and logging facilities. The fact that most
of it is being written in Perl makes it very portable, and no complex mechanisms are used for collecting the
information. Most of it is transferred via the syslog(3) facility, by e-mail, or using FTP.
13Current state of SAINT
The designpresented in thispaper is currentlybeing refined andimplementedas part of a student’sbachelor’s
thesis. When it is in a usable state, SAINT will be released under GNU’s General Public License, and will be
available under ftp://ftp.super.unam.mx/pub/security/tools/.
The author is no longer involved in the development of SAINT. Please forward all requests to saint@
14 The future of SAINT
In the first releaseof SAINT, most of the functionalitydescribed in this paper will be implemented. However,
there are many things that can be considered for future work. For example:
Generation of reports in different languages. Although support for multiple languages will be included
from the beginning, the first version will generate reports in Spanish. However, English modules will
Generation of information that can be used with other tools. For example, a SAINT module could sug-
gest, according to the configurationfile, the contents for TCP-Wrapper access control files. This would
allow not only detecting problems, but preventing them.
Graphical interface. SATAN (by Dan Farmer and Wietse Venema) set a precedent in using a WWW
browser for presenting resultswith a hypertext interface, making it enormouslyeasier to read and inter-
pret the results. This same kind of interface could be implemented for SAINT as one of the front-end
Real-time monitoring. In the current design, SAINT is intended to be periodically executed over data
collected during a time interval. However, it could be possible to collect and analyze data as it is being
generated. In fact, only the data collection and homogenization modules would have to change.
Distributed processing. Interesting work is being currently made in the field of intelligent agents for
security monitoring and intrusion detection [CS95a, CS95b]. It probably wouldn’t be too difficult to
allow SAINT to distribute processing, so the simulation stage becomes more of a real-time monitoring
by an independent agent located in each system, and reporting to a central system where the results are
consolidated and reports generated.
[Bis95]Matt Bishop. Passwd+. In Course W16: UNIX Security Tools: Use and Comparison, presented
[CS95a]Mark Crosbie and Gene Spafford. Active defense of a computer system using autonomous
agents. Technical Report CSD-TR-95-008, COAST Laboratory, Department of Computer Sci-
ences, Purdue University, West Lafayette, IN 47907-1398, February 1995. Available at http:
nical Report CSD-TR-95-022, COAST Laboratory, Department of Computer Sciences, Purdue
University, West Lafayette, IN 47907-1398, March 1995. Available at http://www.cs.
[FS90] Daniel Farmer and Eugene H. Spafford. The COPS security checker system. In Proceedings of
the Summer 1990 Usenix Conference, pages 165–170. Usenix, June 1990. Available at http:
[FV] Dan Farmer and Wietse Venema. SATAN documentation (Security Administrator Tool for An-
alyzing Networks). Included in the SATAN package distribution, available at ftp://ftp.
94] Al Geist, Adam Beguelin, Jack Dongarra, Weicheng Jiang, Robert Manchek, and Vaidy Sun-
deram. PVM 3 user’s guide and reference manual. Manual ORNL/TM-12187, Engineering
Physics and Mathematics Division, Mathematical Sciences Section, Oak Ridge National Labo-
ratory, September 1994. Available at http://www.netlib.org/pvm3/ug.ps.
[HA92] Stephen E. Hansen and E. Todd Atkins. Centralized system monitoring with Swatch. In Pro-
ceedings of the 3rd UNIX Security Symposium, pages 105–117. Usenix, September 1992.
[HA93] Stephen E. Hansen and E. Todd Atkins. Automated system monitoring and notification with
swatch. In Proceedings of the LISA VII Systems Administration Conference, pages 145–155.
[HA94] N. Haller and R. Atkinson. On Internet authentication. RFC 1704, Network Working Group,
October 1994. Available at ftp://nic.ddn.mil/rfc/rfc1704.txt.
[Hal94] Neil Haller. The S/KEY one-time password system. In Proceedings of the ISOC Symposium on
[HCMM92] Naji Habra, Baudouin Le Charlier, Abdelaziz Mounji, and Isabelle Mathieu.
ware architecture and rule-based language for universal audit trail analysis. In Proceedings
of ESORICS ’92: European Symposium on Research in Computer Security. Springer-Verlag,
November 1992. Available in the ASAX distribution at ftp://coast.cs.purdue.edu/
[Hug]Doug Hughes. TkLogger. Program available at ftp://coast.cs.purdue.edu/pub/
[KS93] GeneH.KimandEugeneH.Spafford. Thedesignofasystemintegritymonitor: Tripwire. Tech-
nical Report CSD-TR-93-071, COAST Laboratory, Department of Computer Sciences, Purdue
University, West Lafayette, IN 47907-1398, November1993. Availableat http://www.cs.
[KS94a] Gene H. Kim and Eugene H. Spafford. Experiences with Tripwire: Using integrity checkers
for intrusion detection. Technical Report CSD-TR-94-012, COAST Laboratory, Department of
Computer Sciences, Purdue University, West Lafayette, IN 47907-1398, February 1994. Avail-
able at http://www.cs.purdue.edu/homes/spaf/tech-reps/9412.ps.
[KS94b]Gene H. Kim and Eugene H. Spafford. Writing, supporting, and evaluating Tripwire: A pub-
lically available security tool. Technical Report CSD-TR-94-019, COAST Laboratory, Depart-
ment of Computer Sciences, Purdue University, West Lafayette, IN 47907-1398, March 1994.
Available at http://www.cs.purdue.edu/homes/spaf/tech-reps/9419.ps.
[KS94c]Sandeep Kumar and Eugene H. Spafford. An application of pattern matching in intrusion de-
tection. Technical Report CSD-TR-94-013, COAST Laboratory, Department of Computer Sci-
ences, Purdue University, West Lafayette, IN 47907-1398, June 1994. Available at http://
[KS95]Sandeep Kumar and Eugene H. Spafford. A software architecture to support misuse intrusion
detection. Technical Report CSD-TR-95-009, COAST Laboratory, Department of Computer
Sciences, Purdue University, West Lafayette, IN 47907-1398, March 1995. Available at http:
[Kum95]Sandeep Kumar. Classification and Detection of Computer Intrusions. PhD thesis, Purdue
University, August 1995. Available at ftp://coast.cs.purdue.edu/pub/COAST/
[MCZH95] AbdelazizMounji, BaudouinLe Charlier, DenisZampunie ´ris, andNaji Habra. Distributedaudit
trail analysis. In Proceedings of the ISOC 95 Symposium on Network and Distributed System
Security, 1995. Available in the ASAX distribution at ftp://coast.cs.purdue.edu/
[Muf] Alec D.E. Muffet. Crack Version 4.1: A Sensible PasswordChecker for Unix. Manual included
inthe distributionof Crack,availableatftp://ftp.super.unam.mx/pub/security/
[SSH93] Dave Safford, Douglas Lee Schales, and David K. Hess. The TAMU security package: An on-
going response to internet intruders in an academic environment. In Proceedings of the Fourth
USENIX UNIX Security Symposium, pages 91–118. Usenix, October 1993. Program available
[Ven] Wietse Venema. Logdaemon package. Program and documentation available at ftp://ftp.
[Ven92] Wietse Venema.
In Proceedings of the 3rd UNIX Security Symposium, pages 85–92. Usenix, September
1992. Program available at ftp://ftp.super.unam.mx/pub/security/tools/
TCP Wrapper: Network monitoring, access control, and booby traps.
[Wal] Larry Wall. Perl5 documentation. Included in the Perl5 package, available at ftp://ftp.
[WS92]LarryWallandRandalL.Schwartz. ProgrammingPerl. O’Reilly&Associates,Inc.,103Morris
Street, Suite A, Sebastopol, CA 95472, first edition, March 1992.