Network and Distributed
`System Security
`
`-l='L
`01- IIJ-
`I
`
`February 16-17, 1995
`
`San Dieg0,California
`
`@ lEEE Computer society Press
`
`The Institute of Electrical and Electronics Engineers, Inc.
`
`000001
`
`Symantec 1036
`IPR2015-01892
`Symantec v. Finjan
`
`

`
`Distributed Audit Trail Analysis
`
`Abdelaziz Mounji
`
`Denis Zampunidris
`
`Baudouin Le Charlier
`Naji Habra,
`Institut d'Informatique,
`FUNDP,
`rue Grangagnage 21,
`5000 Namur
`E-mail: {amo, ble, dza, nha)@info.fundp.ac.be
`
`Abstract
`An implemented system for on-line analysis of mul-
`tiple distributed data streams is presented. The system
`is conceptually universal since it does not rely on any
`particular platform feature and uses format adaptors
`to translate data streams into its own standard format.
`The system is as powerful as possible (from a theoret-
`ical standpoint) but still efficient enough for on-line
`analysis thanks to its novel rule-based language (BUS-
`SEL) which is specifically designed for efficient pro-
`cessing of sequential unstructured data streams.
`In this paper, the generic concepts are applied to secu-
`rity audit trail analysis. The resulting system provides
`powerful network security monitoring and sophisti-
`cated tools for intrusion/anomaly detection. The rule-
`based and command languages are described as well as
`the distributed architecture and the implementation.
`Performance measurements are reported, showing the
`effectiveness of the approach.
`1 Introduction
`Auditing distributed environments is useful to un-
`derstand the behavior of the software components. For
`instance this is useful for testing new applications: one
`execution trace can be analyzed to check the correct-
`ness wrt the requirements.
`In the area of real-time
`process control, critical hardware or software compo-
`nents are supervised by generating log data describing
`their behavior. The collection and analysis of these log
`files has often to be done real-time, in parallel with
`the audited process. This analysis can be conducted
`for various purposes such as investigation, recovery
`and prevention, production optimization, alarm and
`statistics reporting. In addition, correlation of results
`obtained at different nodes can be useful to achieve a
`more comprehensive view of the whole system.
`Computer and network security is currently an ac-
`tive research area. The rising complexity of today
`networks leads to more elaborate patterns of attacks.
`Previous works for stand-alone computer security have
`established basic concepts and models 3,4,5,7,8] and
`
`described a few operational systems I 1, 6, 9, 12, 181.
`
`However, distributed analysis of audit trails for net-
`work security is needed because of the two following
`
`facts. First, the correlation of user actions taking place
`at different hosts could reveal a malicious behavior
`while the same actions may seem legitimate if consid-
`ered at a single host level. Second, the monitoring of
`network security can potentially provide a more coher-
`ent and flexible enforcement of a given security policy.
`For instance, the security officer can set up a common
`security policy for all monitored hosts but choose to
`tighten the security measures for critical hosts such as
`firewalls [2] or for suspicious users.
`A software architecture and a rule-based language
`for universal audit trail analysis were developed in the
`first phase of the ASAX project [lo, 11, 121. The dis-
`tributed system presented here uses this rule-based
`language to filter audit data at each monitored host
`and to analyze filtered data gathered at a central host.
`The analysis language is exactly the same at both local
`and central levels. This provides a tool for a flexible
`and a gradual granularity control at different levels:
`users, hosts, subnets, domains, etc.
`The rest of this paper is organized as follows. Sec-
`tion 2 briefly describes the system for single audit trail
`analysis and its rule-based language. Section 3 details
`the functionalities offered by the distributed system.
`Section 4 presents the distributed architecture. Sec-
`tion 5 describes the command interface of the security
`officer. In section 6 , the implementation of the main
`components is outlined. Performance measurements
`are reported in section 7. Finally, section 8 contains
`the conclusion and indicates possible improvements of
`this work.
`2 Single Audit Trail Analysis
`In this section, the main features of the stand alone
`version of ASAX for single audit trail analysis are ex-
`plained. However, we only emphasize interesting func-
`tionalities. The reader is referred to [12] for a more de-
`tailed description of these functionalities'. A compre-
`hensive description of ASAX is presented in [lo, 111.
`
`'Notice however that [12] is a preliminary description of a
`The examples in the present
`system under implementation.
`paper have been actually run on the implemented system
`
`0-8186-7027-4195 $4.00 0 1995 IEEE
`
`102
`
`000002
`
`

`
`2.1 A motivating example
`The use of the RUSSEL language for single audit
`trail analysis is better introduced by a typical exam-
`ple: detecting repeated failed login attempts from a
`single user during a specified time period. This ex-
`ample uses the SunOS 4.1 auditing mechanism. Na-
`tive audit trails are translated into a standard format
`(called NADF). The translation can be applied on-line
`or off-line. Hence, the description below is based on
`the NADF format of the audit trail records.
`Assuming that login events are pre-selected for au-
`diting, every time a user attempts to log in, an audit
`record describing this event is written into the audit
`trail. Audit record fields (or audit data) found in a
`failed login record include the time stamp (au-time),
`the user id (au-tezt-3) and a field indicating success
`or failure of the attempted login (au-tezt4). Notice
`that audit records representing login events are not
`necessarily consecutive since other audit records can
`be inserted for other events generated by other users
`of the system.
`In the example (see Figure l), RUSSEL keywords
`are noted in bold face characters, words in italic style
`identify fields in the current audit record, while rule
`parameters are noted in roman style. Two rules are
`needed to detect a sequence of failed logins. The
`first one (failed-login) detects the first occurrence of
`a login failure. If this record is found, this rule trig-
`gers off the rule count-rule which remains active until
`it detects countdown failed logins among the subse-
`quent records or until its expiration time arrives. The
`parameter target-uid of rule count-rule is needed to
`count only failed logins that are issued by the same
`user (target-uid). If the current audit record does
`not correspond to a login attempt from the same
`user, count-rule simply retriggers itself for the next
`record otherwise. If the user id in the current record
`is the same as its argument and the time stamp is
`lower than the expiration argument, it retriggers it-
`self for the next record after decrementing the count
`down argument. If the latter drops to zero, count-rule
`writes an alarm message to the screen indicating that
`a given user has performed maztimes unsuccessful lo-
`gins within the period of time duration seconds. In
`addition, count-rule retriggers the failed-login rule in
`order to search for other similar patterns in the rest
`of the audit trail.
`In order to initialize the analysis process, the special
`rule initaction makes the failed-login rule active for
`the first record and also makes the print-results rule
`active at completion of the analysis. The latter rule is
`used to print results accumulated during the analysis
`such as the total number of detected sequences.
`2.2 Salient features of ASAX
`2.2.1 Universality
`This feature means that ASAX is theoretically able
`to analyze arbitrary sequential files. This is achieved
`by translating the native file into a format called
`NADF Normalized Audit Data Format). According
`
`to this I ormat, a native record is abstracted to a se-
`
`quence of audit data fields. All data fields are consid-
`
`global v:
`
`integer;
`
`integer) ;
`
`rule f ailedlogin(max-times, duration:
`event = 'loginlogout '
`and au-textA = 'incorrect password'
`--> trigger off fornext
`count r u l e (audext-3,
`strToInt (adime) +durat ion.
`max-t imes-1)
`
`if
`
`fi;
`
`rule count r u l e (target a i d : string ;
`expirat ion,
`countdown: integer) ;
`
`if
`
`auid = suspectauid
`and
`event = 'loginlogout'
`and au-text4 = 'incorrect password'
`and au-text-b = t a r g e t v i d
`and strToInt(ou1ime) < expiration
`--> if countdown > 1
`--> trigger off fornext
`countiule (target a i d ,
`expirat ion,
`countdown-1) ;
`
`countdown = 1
`--> begin
`v := v + 1;
`print In (gett ime ( a d i m e ) ,
`I . . 3 FAILED LOGINS ON ',
`t a r g e t v i d ) ;
`trigger off fornext
`f ailedlogin(3,120>
`end
`
`fi;
`strToInt (audime) > expiration
`--> trigger off fornext f ailedlogin(3,120) ;
`true
`--> trigger off fornext
`count r u l e (target a i d ,
`expiration,
`countdown)
`
`fi;
`
`rule p r i n t i e s u l t s ;
`begin
`println(v. ' sequence(s) of bad logins found')
`end ;
`
`init action;
`begin
`v := 0 ;
`trigger off fornext f a i l e d l o g i n ( 3 , 120) ;
`trigger off at-completion p r i n t i e s u l t s
`end.
`Figure 1: RUSSEL module for failed login detection
`on SunOS 4.1
`
`103
`
`000003
`
`

`
`ered as untyped strings of bytes. Therefore, an audit
`data in the native record is converted to three fields2:
`an identifier (a 2-bytes integer) identifies the data
`field among all possible data fields;
`a length (a 2-bytes integer;)
`a value i.e., a string of bytes.
`A native record is encoded in NADF format as the
`sequence of encodings of each data field with a leading
`4-bytes integer representing the length of the whole
`NADF record. Note that the NADF format is similar
`to the TLV (Tag, Length, Value) encoding used for the
`BER (Basic Encoding Rules) which is used as part of
`the Abstract Syntaz Notation ASN.l [14]. However,
`the TLV encoding is more complex since it supports
`typed primitive data values such as boolean, real, etc
`as well as constructor data types. Nevertheless, any
`data value can be represented as a string of bytes in
`principle. As a result, the flexibility of the NADF
`format allows a straightforward translation of native
`files and a fast processing of NADF records by the
`universal evaluator.
`2.2.2 The RUSSEL language
`RUSSEL (Rule-based Sequence Evaluation Lan-
`guage) is a novel language specifically tailored to the
`problem of searching arbitrary patterns of records in
`sequential files. The built-in mechanism of rule trig-
`gering allows a single pass analysis of the sequential
`file from left to right.
`The language provides common control structures
`such as conditional, repetitive, and compound actions.
`Primitive actions include assignment, external routine
`call and rule triggering. A RUSSEL program simply
`consists of a set of rule declarations which are made
`of a rule name, a list of formal parameters and lo-
`cal variables and an action part. RUSSEL also sup-
`ports modules sharing global variables and exported
`rule declarations.
`The operational semantics of RUSSEL can be sketched
`as follows:
`records are analyzed sequentially. The analysis of
`the current record consists in executing all active
`rules. The execution of an active rule may trigger
`off new rules, raise alarms, write report messages
`or alter global variables, etc;
`rule triggering is a special mechanism by which a
`rule is made active either for the current or the
`next record. In general, a rule is active for the
`current record because a prefix of a particular se-
`quence of audit records has been detected. (The
`rest of this sequence has still to be possibly found
`in the rest of the file.) Actual parameters in the
`set of active rules represent knowledge about the
`already found subsequence and is useful for se-
`lecting further records in the sequence;
`21n fact, native files can be translated t o NADF format in
`many Merent ways depending on the problem at hand. The
`standard method proposed here was however sufficient for the
`applications we have encountered so far.
`
`0 when all the rules active for the current record
`have been executed, the next record is read and
`the rules triggered for it in the previous step are
`executed in turn;
`
`0 to initialize the process, a set of so-called init rules
`are made active for the first record.
`
`User-defined and built-in C-routines can be called
`from a rule body. A simple and clearly specified in-
`terface with C allows to extend the RUSSEL language
`with any desirable feature. This includes simulation
`of complex data structures, sending an alarm message
`to the security officer, locking an account in case of
`outright security violation, etc.
`2.2.3 Efficiency
`Is a critical requirement for the analysis of large
`sequential files, especially when on-line monitoring is
`involved. RUSSEL is efficient thanks to its opera-
`tional semantics which exhibits a bottom-up approach
`in constructing the searched record patterns. Fur-
`thermore, optimization issues are carefully addressed
`in the implementation of RUSSEL: for instance, the
`internal code generated by the compiler ensures a
`fast evaluation of boolean expressions and the cur-
`rent record is pre-processed before evaluation by all
`the current rules, in order to provide a direct access
`to its fields.
`3 Administrator Minded
`Funct ionalit ies
`3.1 Introduction
`The previous sections showed that ASAX is a uni-
`versal, powerful and efficient tool for analyzing sequen-
`tial files, in general, and audit trails, in particular.
`In this section, the functionalities of a distributed ver-
`sion of ASAX are presented in the context of dis-
`tributed security monitoring of networked computers.
`The implemented system applies to a network of SUN
`workstations using the C2 security feature and uses
`PVM (Parallel Virtual Muchine) [15] as message pass-
`ing system. However, the architecture design makes
`no assumption about the communication protocol, the
`auditing mechanism or the operating system of the in-
`volved hosts.
`3.2 Single point administration
`In a network of computers and in the context of se-
`curity auditing, it is desirable that the security officer
`has control of the whole system from a single machine.
`The distributed on-line system must be manageable
`from a central point where a global knowledge about
`the status of the monitoring system can be maintained
`and administered in a flexible fashion. Management of
`the monitoring system involves various tasks such as
`activation of distributed evaluators and auditing gran-
`ularity control. Therefore, monitored nodes are, in a
`sense, considered as local objects on which adminis-
`tration tasks can be applied in a transparent way as
`if they were local to the central machine.
`
`104
`
`000004
`
`

`
`3.3 The local and global analyses
`-
`Local analysis requirement corresponds to the abil-
`ity of analyzing any audit trail associated to a moni-
`tored host. This is achieved by applying an appropri-
`ate RUSSEL module to a given audit trail of a given
`host. The analysis is considered local in the sense that
`analyzed audit data represents events taking place at
`the involved host. No assumption is otherwise made
`about which host is actually performing the analy-
`sis. Local analysis is also called filtering since at the
`network level, it serves as a pre-selection of relevant
`events. In fact, pre-selected events may correspond to
`any complex patterns of subject behaviors.
`Audit records filtered at various nodes are com-
`municated to a central host where a global (network
`level) analysis takes place. In its most interesting use,
`global analysis aims at detecting patterns related to
`global network security status rather than host secu-
`rity status. In this regard, global analysis encompasses
`a higher level and a more elaborate notion of security
`event.
`Concerted local and global analysis approach lends
`itself naturally to a hierarchical model of security
`events in which components of a pattern are detected
`at a lower level and a more aggregate pattern is de-
`rived at the second higher level and so on. Note that
`an aggregate pattern could exhibit a malicious secu-
`rity event while corresponding sub-patterns do not at
`all. For instance, a login failure by a user is not an
`outright security violation but the fact that this same
`user is trying to connect to an abnormally high num-
`ber of hosts may indicate that a network attack is
`under course. Organizations often use networks of in-
`terconnected Lans corresponding to departments. The
`hierarchical model can be mapped on the organization
`hierarchy by applying a distributed analysis on each of
`the Lans and an organization-wide analysis carried out
`on audit data filtered at each Lan. Thus, concerted
`filtering and global analysis can lead to the detection
`of very complex patterns.
`In the following, the node performing the global
`analysis is called the central or master machine while
`filtering takes place at slave machines. Correspond-
`ingly, we will also refer to master and slave evaluators.
`A distributed evaluator is a master evaluator together
`with its associated slave evaluators.
`3.4 Availability
`This requirement means that a distributed evalua-
`tor must survive any of its slave evaluators failure and
`must easily be recovered in case of a failure of the mas-
`ter evaluator. The availability of a distributed evalu-
`ator ensures that if for some reasons a given slave is
`lost (broken connection, fatal error in the slave code
`itself, node crash, etc), the distributed analysis can
`still be carried on the rest of monitored hosts. On
`the other hand, if the master evaluator fails, the dis-
`tributed analysis can be resumed from an other avail-
`able host. In all cases, and especially for on-line anal-
`ysis, all generated audit records must remain available
`for analysis (no records are lost). Distributed analy-
`sis recovery must also be done in a flexible way and
`require a minimum effort.
`
`3.5 Logging control
`This functionality involves control of the granular-
`ity of security events at the network, host and user
`levels. Typically, the security officer must be able to
`set up a standard granularity for most audited hosts
`and to require a finer granularity for a particular user
`or all users of a particular host. According to the sin-
`gle point administration requirement, this also means
`that logging control is carried out from the central
`machine without need for multiple logging to remote
`hosts.
`4 Architecture
`The architecture of the distributed system is ad-
`dressed at two different levels. At the host level, a
`number of processes cooperate to achieve logging con-
`trol and filtering. The global architecture supports the
`network level analysis. This section aims at giving an
`intuitive view of the overall distributed system.
`4.1 Host level
`Processes in the local architecture are involved in
`the generation of audit data, control of its granularity
`level, conversion of audit data to NADF format, anal-
`ysis of audit records and finally transmission of filtered
`sequences to the central evaluator. At the master host,
`a network level analysis subsequently takes place on
`the stream of records resulting from merging records
`incoming from slave machines. Both global and local
`analyses are performed by a slightly modified version
`of the analysis tool outlined in the previous section.
`4.1.1 Audit trail generation
`This mechanism is operating system dependent. It
`generates audit records representing events such as op-
`erations on files, administrative actions, etc. It is as-
`sumed that all monitored hosts provide auditing ca-
`pabilities and mechanism for controlling granularity
`level. The process generating audit records is called
`the audit daemon (auditd for short).
`4.1.2 Login controller
`This process communicates with auditd in order to
`alter the granularity. It is able to change the set of pre-
`selected events. This can be done on a user, host and
`network basis. Furthermore, we distinguish between
`a temporary change which applies to the current lo-
`gin session and a permanent change affecting also all
`subsequent sessions.
`4.1.3 Format adaptor
`This process translates audit trails generated by au-
`ditd to the NADF format. Native files can be erased
`after being converted since they are semantically re-
`dundant with NADF files. Keeping converted files in-
`stead of native files has several advantages: the files
`are converted only once and can be reanalyzed several
`times without requiring a new conversion. Moreover,
`in the context of an heterogeneous network, they pro-
`vide a standard and unique format.
`4.1.4 Local evaluator
`It analyzes the NADF files generated by the format
`adaptor. Note that several instances of the evaluator
`can be active at the same time to perform analyses on
`different NADF files or possibly on the same file. Off-
`line and on-line analyses are implemented in the same
`
`105
`
`000005
`
`

`
`FILTERING
`Format Adaptor
`
`FILTERING
`Format Adaptor
`I
`
`NADF . . .
`
`NADF
`
`Evaluator
`
`8
`
`Evaluator
`
`Audit
`Records
`
`4.1 C2 security notation for event classes. (The SunOS
`4.1 C2 security features are described in detail in [16].)
`These audit flags are listed in Table 1.
`
`flags - dr
`
`dw
`dc
`da
`lo
`ad
`PO
`pf
`
`short description
`data read
`data write
`object create/delete
`object access change
`Login, Logout
`Administrative operation
`Privileged operation
`Unusual oDeration
`
`example
`stat(2)
`utimes( 2)
`mlcdir ( 2 )
`c h d ( 2)
`login( 1)
`su( 1)
`quota( 1)
`re boot ( 2 )
`
`NETWORK
`
`Figure 2: System Architecture
`
`way. The only difference is that in on-line mode, the
`evaluator analyzes the currently generated file. These
`processes will be further described in section 6.
`Audit records filtered by slave evaluators on the var-
`ious monitored slave machines are sent to the central
`machine for global analysis.
`4.2 Network level
`At the network level, the system consists of one or
`more slave machines running the processes previously
`described and a master machine running the master
`evaluator (see Figure 2). The latter performs global
`analysis on the audit record stream resulting from lo-
`cal filtering. The result of the central analysis can be
`network security status reports, alarms and statistics,
`etc. In addition, a console process is run on the master
`machine. It provides an interactive command interface
`to the distributed monitoring system. This command
`interface is briefly described in the next section.
`5 The Command Language of
`the Distributed System
`5.1 Preliminaries
`This section presents the command interface used
`by the security officer. In the following, evaluator in-
`stances are identified by their PVM instance numbers
`which are similar to Process Ids in UNIX systems. Au-
`ditable events are determined by a comma separated
`list of audit flags which are borrowed from the SunOS
`
`106
`
`Ti de 1: SunOS C2 security audit flags
`Audit flags can optionally be preceded by +
`-) to select only successful (resp.
`(resp.
`failed)
`events.
`For
`instance,
`the list of audit flags
`+dr,-dw, lo,pO,pl specifies that successful data read,
`failed data writes, all new logins and all privi-
`leged operations are selected. Under SunOS, the
`file / e t c/security/audit/audit-control contains
`(among other things) a list of audit flags determin-
`ing the set of auditable events for all users of the sys-
`tem. /etc/security/passwd. adjunct is called the
`shadow file and contains a line per user which indicates
`events to be audited for this particular user. The ac-
`tual set of auditable events for a given user is derived
`from the system audit value and the user audit value
`according to some priority rules. Finally, audit trails
`in NADF format respect naming conventions based on
`creation and closing times. This allows to easily se-
`lect files generated during a given time interval. For
`instance, the file named timq .timef .NADF contains
`events generated by auditd in the time interval [time;,
`timef]. Supported commands fall into two categories:
`5.2 Analysis control commands
`The commands for distributed analysis allow to
`start, stop and modify a distributed analysis. To
`start a new distributed analysis on a set of monitored
`hosts, one first prepares a text file specifying the in-
`volved hosts, the RUSSEL modules to be applied on
`the hosts, and optionally an auditing period a time
`
`interval which is the same for each node). By 6 efault,
`
`analysis is performed on-line. This file is given as an
`argument to the run command.
`Using the rerun command, the security officer can
`change attributes of an active distributed evaluator
`either by changing rule modules on some hosts (master
`or slave) or by changing the time interval used by the
`whole distributed evaluator. The rerun command is
`parameterized by an evaluator instance number and a
`rule module or a time interval.
`The kill command stops an evaluator identified by
`its instance number. ps reports the attributes of all
`active distributed evaluators. Attributes of an evalu-
`ator include instance number, instance number of the
`corresponding master evaluator, host name, rule mod-
`ule and time interval.
`
`000006
`
`

`
`It is possible to activate several distributed evalu-
`ators which run independently of each others. The
`command reset stops all current distributed evalua-
`tors.
`5.3 Logging control commands
`The command logcntl implements the logging con-
`trol functionality (see 3.5). It allows to alter the gran-
`ularity level for any monitored user or host. The se-
`curity officer is so able to change the auditable events
`for a particular user on a particular host according to
`the list of audit flags supplied to logcntl. With the
`option -t the change takes effect immediately, how-
`ever, the settings are in effect only during the current
`login session. With the option -p, the change takes
`effect the next time the user logs in and for every sub-
`sequent login session until this command is invoked
`again. On the host basis, the security officer can alter
`the system audit value of a specified host by supplying
`a host name and a list of audit flags.
`Although the logcntl command relies closely on the
`SunOS formalism for specifying auditable events and
`altering the set of events currently audited, it could be
`possible to develop a system-independent event clas-
`sification as well as a portable auditing configuration.
`Nevertheless, as the SunOS 4.1 uses an event classifi-
`cation and auditing configuration that are similar to
`most O S , the current solution is sufficient for a pro-
`totype system.
`5.4 Example
`In this section, the failed login detection example
`introduced in section 2.1 is reconsidered in the con-
`text of a distributed analysis. The purpose is still to
`detect repeated failed login attempts, but now failed
`login events can occur at any of the monitored hosts
`(here we consider two hosts viz. poireau and epinard).
`According to the filtering/global analysis principle, a
`slave evaluator is activated on each hosts (poireau and
`epinard) and a master evaluator is initiated on poireau.
`Each slave evaluator only filters failed login records
`from its local host and sends it to the master eval-
`uator which then analyzes the filtered record stream
`to detect the sequence of failed logins. As indicated
`in the evaluator description file shown in Figure 3,
`filtering is implemented in RUSSEL by the rule mod-
`ule badlogin.asa while the sequence of failed logins is
`detected using the rule module nbbad1ogin.a~~. This
`file also contains the time interval to which analysis
`is applied. Figures 5 and 6 depict the content of bad-
`1 o g i n . a ~ ~ and nbbadlogin.asa respectively. Notice that
`the master evaluator does not check that records corre-
`spond to login failure events since this is already done
`by the associated slave evaluators. Figure 4 shows how
`
`master poireau:
`nbbadlogin: [19940531170431,199406011738291;
`slaves poireau, epinard: badlogin.
`
`Figure 3: Distributed Analysis Description File
`
`the distributed evaluator is activated using the inter-
`active console window. The lower window contains
`
`rule f a i l e d l o g i n ;
`begin
`event = ’ loginlogout
`if
`and au-teztd = ‘incorrect password’
`--> send-current
`fi;
`trigger off fornext f a i l e d l o g i n
`end ;
`
`init action ;
`begin
`trigger off fornext f a i l e d l o g i n
`end
`
`Figure 5: Slave evaluator module: badlogin.asa
`
`the distributed analysis interactive console. The se-
`curity officer has just invoked the run command with
`the name of the evaluator description file as argument.
`The upper window is the Unix console where outputs
`from the master evaluator are printed.
`6 Overview of the Implementation
`The implementation of the rule-based language
`RUSSEL is out of the scope of this paper and is fully
`explained in [lo, 111. We only consider the implemen-
`tation of the distributed aspects. However, it is worth
`noticing that very few modifications were necessary to
`handle record streams instead of ordinary audit trails.
`In addition to the auditd process, the following con-
`current processes are attached to each monitored host
`(see Figure 7):
`6.1 Distributed format adaptor (FA)
`The distributed format adaptor fadapter translates
`SunOS audit files into NADF format.
`It also ob-
`serves date and time based naming conventions for
`NADF files: a NADF file consisting of the chronolog-
`ical sequence of audit records Ro, ..., h - 1 is named
`timQ.time,.NADF where timeo is the time and date
`found in RO and time, is the time stamp in h - 1 plus
`one second. Both timQ and time, are 4 decimal dig-
`its year, and 2 decimal digits for each of the month,
`day, minute, and second. The current NADF file has a
`name of the form timeo.not-terminated.NADF where
`timeo is the time stamp of its first record.
`The current native and NADF files are limited to a
`maximum size which is recorded in the file nadf-data.
`The process sizer sends a signal to auditd (resp.
`fadapter) if the maximum size for the current native
`(resp. NADF) file is reached. When auditd or fadapter
`receives such a signal, it closes the current file and
`continues on a new one. The maximum size can be
`changed at any time by a simple RPC (Remote Pro-
`cedure Call) server dfisize-svc after request from the
`console process. dfisize-svc updates the file nadf-data
`accordingly.
`The distributed FA is automatically started at boot
`time of each monitored host from / e t c / r c . l o c a l .
`
`107
`
`000007
`
`

`
`H k J
`
`cmdtool (CONSOLD -/bin/csh
`
`end of parsing description f i l e I . .
`end of parsing description f i l e ...
`pvmd@epinard:begin parsing description f i l e ..;
`pvmd@epinard:end o f parsing description f i l e ...
`asax :
`/etc/securi ty/audi t/pvm/SUM/nbbadl ogi n. asa
`Processing audit t r a i l ...
`asax :
`/etc/securi ty/audi t/pvm/SUM/badlogi n. asa
`Processing audit t r a i l ...
`pvmd@epinard:Processing audit t r a i l ...
`asax :
`pvmd@epi nard:
`/etc/securi ty/audi t/pva/SUM/badlogi n. asa
`3 FAILED LOGINS ON nha (601). AT Thu Jul 07 11:34:29 1994 from poireau
`pvmd@epi nard:
`pvmd@epi nard: end o f anal ysi s(8)
`pvud@epinard:Processing completion rules . . .
`end of analysis(7)
`Processing completion rules .
`end of analysis(6)
`Processing completion rules _..
`
`. r
`
`5=========1=1==-==*_iii=11=1======1=================-======
`
`1 sequencek) o f f a i l e d l o g i n found
`
`~~~~
`
`run edflogin
`
`dasax%.
`
`cmdtool -/bin/csh
`
`1
`
`Figure 4: Console windows
`
`6.2 Logging control
`Changing the granularity level for a user or a host
`is performed remotely from the security officer con-
`sole by a remote update of the avditd configuration of
`the involved host. Therefore, logging control is imple-
`mented by means of RPC. For this purpose, to each
`monitored host is attached a server process logcntl-svc
`accepting requests from the console process running
`on the master machine. Depending on the option used
`for the command logcntl, the console process calls an
`appropriate procedure offered by the logcntl-svc server
`on the involved host. According to the RPC model,
`logcntl-svc transfers control to the appropriate service
`procedure and then sends back a reply to the console
`process indicating the outcome of the call.
`It was not possible to implement such a communi-
`cation