Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 1 of 39
`Case 4:18-cv-07229—YGR Document 192-5 Filed 04/19/21 Page 1 of 39
`
`EXHIBIT 4
`
`EXHIBIT 4
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 2 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 2 of 39
`
`
`
`See discussions, stats, and author profiles for this publication at: ta“
`
`Preliminary report on Distributed ASAX
`
`Article March 1996
`
`
`
`Cll‘A'l'EONE‘.
`
`0
`
`READS
`
`14
`
`4 authors, including:
`
`
`
`
`
`University of Namur
`
`10 PUBLEa’LA'lEOl‘li-T 159 Ci'lAl'lONS
`
`
`
`
`
`Université Catholique cle Louvain
`
`86 PUBLlCA'i'lO E13 1,344 Cl'E'A'i'lONiE
`
`SEE PROHLE
`
`SEE PROFELE
`
` University of Namur
`
`61 F’UBiECATEONS 495 CH'A'HONS
`
`Some of the authors of this publication are also working on these related projects:
`
`mm
`
`intrusion Detection '2: beta
`
`.
`
`New: Methods to Simpliiy'ihings '..r"‘é2'a<:z=
`
`All content following this page was uploaded by i-Zées law on 17 March 2014.
`
`The user has requested enhancement of the downloaded file.
`
`QUALY800024281
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 3 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 3 of 39
`
`Preliminary report on Distributed ASAX
`
`Abdelaziz Mounji
`
`Denis Zampunieris
`
`Baudouin Le Charlier
`Naji Habra,
`Institut D’Informatique,
`FUNDR
`rue Grangagnage 217
`5000 Namur
`
`E-mail: {amo, ble, dzaJ nha}@info.fundp.ac.be
`
`May 27, 1994
`
`QUALYSOOOZ4282
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 4 of 39
`Case 4:18-cv-O7229-YGR Document 192-5 Filed 04/19/21 Page 4 of 39
`
`Contents
`
`1
`
`Introduction
`
`2 Desirable functionalities for distributed network monitoring
`2.1
`Introduction ............................
`
`Single Point Administration ...................
`2.2
`2.3 Local Analysis (Filtering) ....................
`2.4 Global Analysis ..........................
`2 .5 Availability ............................
`2.6 Audit Trail Control ........................
`
`2.7 Security ..............................
`2.8 Multi Point Administration ...................
`
`2.9 Portability .............................
`2.10 Proposed solution .........................
`
`3 The SunOS 4.1 Security level C2
`3.1
`Installation ............................
`3.2 Process audit state ........................
`
`3
`
`5
`5
`
`5
`6
`6
`7
`7
`
`7
`8
`
`8
`8
`
`9
`9
`9
`
`3.3 Naming conventions ....................... 10
`3.4 Command interface ........................ 10
`
`4 General Architecture
`
`11
`
`4.1 Filtering .............................. 11
`4.2 Global Analysis .......................... 12
`
`5 Detailed Functionalities
`
`14
`
`Introduction ............................ 14
`5.1
`Initialization ........................... 14
`5.2
`5.3 Audit Trail Control ........................ 15
`
`5.4 Login control ........................... 15
`5.5 NADF file management ..................... 16
`5.6 Distributed Analysis ....................... 16
`5.7 Portability ............................. 18
`
`19
`6 Command Interface
`6.1
`Introduction ............................ 19
`6.2
`Initialization ........................... 20
`
`6.2.1 Activation of Format Adaptor .............. 20
`
`1
`
`QUALY800024283
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 5 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 5 of 39
`
`6.3
`
`6.4
`
`6.5
`
`Analysis Control ......................... 21
`6.3.1 Distributed Evaluator Description File ......... 21
`6.3.2 Distributed Evaluator execution ............ 22
`
`6.3.3 Changing current filtering ................ 23
`6.3.4 Changing the time interval of the analysis ....... 23
`Login Control ........................... 24
`6.4.1 Notations and definitions ................ 24
`
`6.4.2 Temporary change of user audit state ......... 26
`6.4.3
`Permanent change of user audit state ......... 26
`6.4.4 Host login control .................... 27
`6.4.5 Network login control .................. 27
`Miscellaneous Commands .................... 27
`
`Stopping an evaluator .................. 27
`6.5.1
`6.5.2 Reinitializing the system ................. 28
`6.5.3 Current active evaluators ................ 28
`
`6.5.4 Audit trail size control .................. 28
`
`6.5.5 The configuration .................... 29
`6.5.6 Help command ...................... 29
`
`7 The
`7.1
`7.2
`7.3
`7.4
`
`7.5
`7.6
`
`30
`implementation
`Introduction ............................ 30
`PVM ................................ 30
`
`Format Adaptors ......................... 30
`The Parallel Virtual Machine Configuration .......... 31
`7.4.1 The audit state controller processes .......... 31
`7.4.2 Evaluator processes ................... 32
`7.4.3 The supplier processes .................. 32
`7.4.4 The console process ................... 32
`
`Specification of the exchanged messages ............ 33
`A typical session ......................... 34
`7.6.1
`Initialization ....................... 34
`
`7.6.2 Distributed Analysis ................... 34
`7.6.3 Termination ........................ 35
`
`2
`
`QUALY800024284
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 6 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 6 of 39
`
`Chapter 1
`
`Introduction
`
`The purpose of this report is to present a distributed on-line system capable
`of performing efficient, intelligent and network-level analysis of security audit
`trails in a network of SUN workstations. The distributed system is in fact
`
`an extension of ASAX ([1], [2], [3]) whose main features can be summarized
`by the following:
`
`Universality: by supporting any kind of native audit trail format. This is
`achieved by means of user-provided Format Adaptors translating the
`native format to the NADF (Normalized Audit Data Format) format;
`
`Power: by devoting a brand new rule-based language especially designed
`for formulating arbitrary complex queries on the audit trail;
`
`Efficiency: by allowing to resolve multiple queries in a single pass analysis
`of the audit trail using a bottom-up method.
`
`However, ASAX was originally designed for analyzing a single audit trail
`generated on a single machine.
`In effect, the present and future integration of computer systems and net-
`works suggest more elaborate analysis that should be carried out at the
`network level. This stems from the fact that (from security analysis stand-
`point at least) some pattern of actions may appear legitimate if considered
`at the host level but could reveal malicious behaviour if related to actions
`
`occurring on other hosts of the network. On the other hand, such a dis—
`tributed system potentially provides a coherent and integrated control of
`
`the network auditing/analysis system.
`
`The distributed analysis should be ideally applied to an heterogeneous net-
`work but in this paper, we suggest an experimental system restricted to a
`network of Sun workstations. However, the paper presents high level, user-
`oriented functionalities general enough to be applicable to an heterogeneous
`network.
`In this regard, the experimental distributed system will serve a
`twofold goal. First, it will demonstrate the usefulness of these functionalities
`in achieving network security monitoring and intrusion / anomaly detection.
`Second, it will prove the feasibility of these functionalities by implementing
`
`QUALY800024285
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 7 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 7 of 39
`
`a functioning prototype version on a network of SUN workstations.
`
`Distributed Analysis should not be restricted to security audit trails. In
`this first attempt, we concentrate on the security aspects but we hope that
`many design choices are applicable to the analysis of distributed systems in
`general.
`
`The rest of the paper is organized as follows. The next chapter describes
`the functionalities a distributed system for audit trail analysis should pro-
`vide. Chapter 3 introduces some basic features of the SunOS 4.1 security
`level CZ. Chapter 4 depicts a general architecture of a distributed system
`for audit trail analysis and explains the interactions between the various
`components (machines, processes,
`etc). Chapter 5 describes the detailed
`functionalities implemented by the experimental system and shows how the
`user-oriented requirements of chapter 2 can all be fulfilled using the detailed
`functionalities. Chapter 6 is a specification of the Security Administrator
`command interface for the distributed system. Chapter 7 addresses the
`implementation design issue.
`
`QUALY800024286
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 8 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 8 of 39
`
`Chapter 2
`
`Desirable functionalities for
`
`distributed network
`
`monitoring
`
`2.1
`
`Introduction
`
`In this chapter we will examine the high level functionalities of a distributed
`on-line system for audit trail analysis. We claim that the provided function-
`alities are essential for the Security Administrator to accomplish his task in
`the most effective and convenient way.
`
`2.2
`
`Single Point Administration
`
`In a network of computers and in the context of auditing/analysis of secu-
`rity related events, it is desirable that the security administrator could gain
`
`control over the auditing/analysis system of the whole network from a single
`machine. To be accomplished, none of his (security-related) duties should
`require multiple (physical or remote) login to numerous machines. Rather,
`he must be provided with an (command/graphical) interface which allows
`management and control of the auditing/ analysis resources, programs and
`parameters in a transparent way. For instance, remote hosts should be ac—
`cessed using logical names without need of multiple connections to remote
`hosts. This is especially useful in case the security administrator wants to
`
`apply the same administration tasks (set up auditing parameters such as
`audit directories, level of granularity, analysis,
`etc) on a group of hosts
`in the network.
`
`the single point administration requirement means that remote
`That is,
`audited nodes should be considered as logical objects on which security ad-
`ministration operations could be applied as if they were directly available
`on the local machine.
`
`QUALY800024287
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 9 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 9 of 39
`
`2.3 Local Analysis (Filtering)
`
`The distributed auditing/analysis system is able to perform analysis on any
`node taking part in the network of audited nodes. The analysis is considered
`local in the sense that the audit data subject to analysis represents events
`taking place at the audited host. No assumption is otherwise made about
`which node is actually performing the analysis.
`
`It can
`Local analysis requires that the auditing mechanism is activated.
`be carried out in two different modes.
`In the on-llne (or real-time) mode,
`analysis is applied to audit records as soon as they are generated by the
`auditing subsystem. In ofi-line mode, the system analyzes audit trails pre-
`viously stored by the auditing subsystem. The outcome of a local analysis
`is a sequence of audit records from the local audit trail which satisfy the
`analysis. Local analysis is also called filtering since at the network level, it
`serves as a pre—selection of audit records. The various audit records obtained
`at each node will subsequently be subject to a more elaborate analysis.
`
`2.4 Global Analysis
`
`The distributed auditing/analysis system is able to perform more intelligent
`analysis of a global audit trail gathering audit records that result from the
`various local analyses. Global analysis aims at identifying correlations be—
`tween events occurring at different nodes. The overall benefit is reducing
`the complexity of malicious behaviour detection. In effect, a malicious be—
`haviour can be viewed as an elaborate sequence of actions involving many
`nodes. On the other hand, these actions could in turn be as complex rather
`than mere pre-selection of audit records on record type basis for instance.
`
`As a result, concerted local filtering and global analysis leads to a more in-
`
`telligent monitoring and intrusion/anomaly detection system for computer
`networks. Moreover, this combination yields a better balancing of the pro-
`cessing resources since the total amount of cpu time is distributed over the
`network.
`
`If the current global analysis indicates that a security violation is suspected,
`it can trigger a finer granularity of generated events on certain nodes. It can
`also affect the current local analysis by asking such nodes to apply a more
`appropriate filter in order to capture more audit records.
`
`In the following, the node performing the global analysis is called the central
`(or master) machine while filtering takes place at
`slave machines.
`Note that the master machine can also analyze its own local audit trail and
`then be considered slave at the same time.
`
`QUALY800024288
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 10 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 10 of 39
`
`2.5 Availability
`
`In the case where any host goes down, auditing must continue on any other
`machines and the global analysis of the rest must continue.
`If the central
`machine breaks down, analysis can be restarted from another machine and
`
`resumed from the time of the crash (i.e.
`completely performed albeit delayed).
`
`the global analysis will still be
`
`2.6 Audit Trail Control
`
`Appropriate audit trail control is driven by 2 factors:
`
`Huge volume of audit data at the finest level of granularity, audit data
`for a single user can exceed 10 MB of data per day;
`
`The network context audit data could span over numerous hosts and
`hence introduces the difficulty of coherent maintenance.
`
`Consequently, audit trail control requirement should include:
`
`At the host level common methods for reducing the required storage i.e:
`
`o a tradeoff between a finer granularity (in order to achieve detailed
`analysis) and the resulting big amount of data;
`
`0 archiving policy to removable media;
`
`0 data compression.
`
`At the network level since audit data is scattered over many hosts, a
`
`centralized management is necessary in order to avoid inconsistencies
`between audit trail controls applied at each host.
`
`2.7 Security
`
`Audit data must be protected from corruption and/or unauthorized access.
`The whole effort devoted to audit trail analysis is meaningless if appropriate
`access control to audit data is not enforced. Multi-user operating systems
`support access control mechanism to ordinary files that must be used for
`
`this purpose. Only a very few number of users (user audit in Unix systems)
`should be allowed access to audit trails.
`
`Note that audit
`
`trails analysis could also be used as the last line of de-
`
`fense against unauthorized access to audit trails themselves.
`Again, in a network audit context, audit record transmission between a slave
`machine and the master machine must be secured against users listening to
`the transmission media.
`
`QUALY800024289
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 11 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 11 of 39
`
`2.8 Multi Point Administration
`
`It is desirable that the audit files could be queried by several persons with
`different interests and privileges.
`In this perspective, the system must be
`able to manage access control to audit trails at the record or at the audit
`data (audit record fields) level. For example, the accounting department
`executive should be able to access audit data relevant to accounting while
`he must be denied access to security related audit data. At the network level,
`
`etc) can perform
`different persons (accounting auditor, security officer,
`different kinds of analysis on different machines depending on their domain
`of investigation.
`
`2.9 Portability
`
`The distributed on-line analysis system should be highly independent of any
`
`machine or network architecture in order to allow monitoring/analysis of
`networks as heterogeneous as possible. Provisions should be made for most
`system and network architectures which can be supported with a minimum
`
`reprogramming effort.
`
`2.10 Proposed solution
`
`The solution that we describe in the rest of this paper provides a complete
`
`treatment of requirement 2.2, 2.3, 2.4 and 2.5 (Single Point Administration,
`Local Analysis, Global Analysis and Availability). Partial solutions are
`provided to requirements 2.6 and 2.7 (Audit Trail Control and Security).
`They amount to reusing mechanisms which are provided by the SunOS 4.1.
`
`Security level C2. Requirement 2.8 (Multiple Point Administration) is not
`addressed formally because its satisfactory treatment requires defining the
`notion of shared data with access privileges defined at the data field level.
`Nevertheless, our solution could be naturally extended to handle Multiple
`
`Point Administration. Requirement 2.9 (Portability) is addressed at the
`architecture and language level, but the implementation and the audit trail
`generation control are specific. However the implementation will isolate
`the system dependent parts in a few modules to allow ”portability with
`minimum reprogramming”.
`
`QUALY800024290
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 12 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 12 of 39
`
`Chapter 3
`
`The SunOS 4.1 Security
`
`level C2
`
`3.1
`
`Installation
`
`Under the security level C2, the SunOS 4.1 operating system provides audit-
`ing of security-related events in the so-called audit trails. For a host (namely
`a Sun workstation) to run in this security level, the Security option must
`be selected when installing SunOS. The system kernel must be configured
`with SYSAUDIT option and the machine must be rebooted.
`
`3.2 Process audit state
`
`Security-related events could be audited at different levels of granularity. For
`less granular auditing, an event can be considered atomic and represented by
`a single audit record while it could be decomposed into a sequence of events
`(represented by several audit records) in a more granular level of auditing.
`The process audit state for a given process determines the set of event types
`to be audited for it. The system audit value characterizes which events
`should be audited for an arbitrary process running on a host while a user
`audit value for a given user specifies what events should be audited for an
`arbitrary process initiated by this user on this host. As a result, the audit
`state of an arbitrary process is completely determined by the system audit
`value and the associated user audit value.
`
`The system audit value is represented in the file audit_control while the
`user audit value is represented in the file passwd. adjunct. The latter file is
`
`an adjunct to the file /etc/passwd and contains encrypted passwords. Users
`are denied access to /etc/passwd.adjunct in order to avoid insider password
`attacks.
`
`QUALY800024291
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 13 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 13 of 39
`
`3.3 Naming conventions
`
`Audit trails are stored in the directory /etc/security/audit/server/files
`where server is the name of the audited host. This directory is automat-
`ically created when the system is booted C2. Furthermore, some naming
`conventions are used for audit files: when auditing starts, a file designated
`date0.not_terminated (where dateo is made up of the year, month, day, hour
`minutes and seconds) is created. When this file is closed, its name is changed
`to date0.date1 (where datel is the date of the close operation), at which time,
`auditing continues on a the file named date1.not_terminated and so on. The
`audit deamon writes audit records to the current file unless it receives a sig-
`nal forcing it to switch to an other file. When audit trails quota is exceeded,
`the audit daemon (auditd) informs the security administrator of such event
`and suspends auditing until some arrangements are made; at that time,
`auditing can resume.
`
`3.4 Command interface
`
`The audit system interface audit(8) command can be used to
`
`0 signal audit daemon to close the current audit file and open a new
`audit file in the current audit directory;
`
`0 signal audit daemon to read audit control file. The audit daemon
`stores the information internally;
`
`0 signal audit daemon to disable auditing and die;
`
`0 change the process audit state of all processes owned by a user by
`
`changing his user audit value and/or the system audit value. These
`two values are contained in the file audit_control and passwd.adjunct
`respectively.
`
`See audit(8) man page and Administering C2 Security of the System and
`Network Administration for more details.
`
`10
`
`QUALY800024292
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 14 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 14 of 39
`
`Chapter 4
`
`General Architecture
`
`In order to understand clearly the architecture of our proposed solution, it
`
`the local level (or filtering) and
`is worth considering two different levels.:
`the global level. In the following, we outline each level in turn. The current
`chapter only aims at giving an intuitive view of the solution. The exact
`functionalities are detailed in chapter 5.
`
`4.1 Filtering
`
`The system is built on a network of Sun workstations. At the host level,
`
`there are 4 main components (see Figure 4.1) :
`
`Auditing Mechanism
`
`Audit State Controller
`
`ON-LINE
`
`OFF-LINE
`
`Figure 4.1: Filtering
`
`Audit State Controller: it is able to alter the granularity level used by
`the auditing mechanism. This granularity can be controlled for all pro-
`cesses running on this host or on a user basis by controlling the granu-
`larity of processes belonging to that user. The Auditing Mechanism
`is the original mechanism provided by the SunOS 4.1 security level C2
`
`11
`
`QUALY800024293
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 15 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 15 of 39
`
`and there is no possibility to modify it. It runs independently of our
`distributed system. The audit state controller is a separated process
`of our distributed system which receives commands from the central
`
`console (see 4.2) and sends messages to the auditing mechanism by
`means of the (SunOS security level C2) audtt{8) interface;
`
`this is the module responsible for translating the 0.8.
`Format Adaptor:
`generated audit trail to a canonical format. The Format Adaptor is
`linked to the SunOS4.l Auditing Mechanism in a pipeline fashion.
`The native file is erased automatically after translation. NADF files
`
`are kept until the auditor decides to erase them. Precise naming con-
`ventions are used for NADF files. They allow to select files on a ”time
`
`of generation” basis.
`Keeping converted files instead 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 provide a standard and unique format;
`
`performs analysis on the file (in canonical format) previously
`Evaluator:
`generated by the Format Adaptor. Note that several evaluators can be
`active at the same time. They perform different analysis on different
`NADF files or possibly on the same file. Off-line and on-line analyses
`are implemented in the same way. The only difference is that on-line
`
`evaluation applies to the currently generated NADF file.
`
`Audit records resulting from local analysis on slave machines are sent to the
`central machine for further analysis.
`
`4.2 Global Analysis
`
`At the network level, the system consists of one central or master machine
`and one or more slave machines. Slave machines analyze their local audit
`trails and send the filtered audit records to the master machine which then
`
`performs a more intelligent analysis. Two processes are run on the central
`machine (see Figure 4.2):
`
`Central Evaluator performs global analysis on a global audit trail con-
`taining the audit records resulting from local analysis and sent by the
`slave machines. The result of the central evaluation can be network
`
`wide reports, alarms and statistics;
`
`is an interactive command interface used by the Security Ad-
`Console:
`ministrator to control the network monitoring system. It can be used
`to affect the level of auditing granularity on host or user basis. It can
`also be used to apply a given analysis on any host. More generally,
`the console is used by the auditor to specify any change to the system
`current behaviour. The set of available commands are described in
`
`chapter 6.
`
`12
`
`QUALY800024294
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 16 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 16 of 39
`
`FLITERING
`
`FILTERING
`
`Format Adaptor
`
`Format Adaptor
`
`
`
`GLOBAL
`
`ANALYSIS
`
`CENTRAL
`
`CONSOLE
`
`EVALUATOR
`
`Figure 4.2: Global Analysis
`
`13
`
`QUALY800024295
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 17 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 17 of 39
`
`Chapter 5
`
`Detailed Functionalities
`
`5.1
`
`Introduction
`
`In chapter 2 we described high level functionalities and user—oriented re—
`quirements. The present chapter deals in detail with the functionalities
`supported by the proposed solution of a distributed on-line system for audit
`trail analysis. It aims also to show how the following detailed functionalities
`address the user-oriented requirements.
`
`5.2
`
`Initialization
`
`We distinguish 2 kinds of initialization:
`
`0 installation of the security feature by rebooting under the security level
`C2. Refer to Administering 0'2 Security of the System and Network
`Administration for more details;
`
`0 Initialization of the analysis system for all hosts attached to the net-
`work to be monitored.
`
`At completion of the initialization procedure, the distributed system must
`be ready for starting network analysis. This initialization consists of the
`following steps:
`
`0 starting of the Format Adaptor module on each host so that all local
`native audit trails are translated to NADF files. This translation must
`
`be on-line;
`
`0 activation of an evaluator on each host so that it is ready for processing
`local NADF files;
`
`0 activation of the interactive console process on one of the hosts. This
`host is chosen by the Security Administrator and is considered to be
`the master machine.
`
`At this point, and using the interactive console, the Security Administrator is
`able to launch any analysis he wants on any host. This is done by specifying a
`
`14
`
`QUALY800024296
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 18 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 18 of 39
`
`host name and a rule module that implement this analysis. Chapter 6 lists
`
`the command language used by the console. Note that the initialization
`procedure automatically starts the Format Adaptors and evaluators on the
`various hosts and then activates the Security Administrator console that
`prompts the Security Administrator for commands.
`
`5.3 Audit Trail Control
`
`Audit trail control involves elimination of native audit trails, login control,
`and management of audit trails. These points are described in the following:
`
`o native audit trails must be systematically removed since they are re-
`
`dundant with the corresponding NADF files. When the native file
`reaches a given size (say 1MB), it is removed and the format adaptor
`resumes the translation of a new native file;
`
`0 naming conventions must be chosen so that audit trails are automat—
`ically assigned standard names as they are generated by the format
`adaptor. An NADF file name has the following general format:
`
`crtime_cltime.NADF
`
`where crtime is the date of the NADF file creation and cltime is the
`
`If an NADF file is still been gen-
`date at which the file was closed.
`erated by the Format Adaptor, cltz'me is set to the conventional value
`notierminated.
`
`In order to allow easier management of NADF files, it is necessary to
`specify a maximum size that these files may grow before a new NADF file is
`created. Choosing a small value for this maximum size results in excessive
`file switches and leads to the proliferation of small files on the host. Con-
`versely, choosing a too large value yields too large and unmanageable files
`especially for back-up and restore operations. The system uses a default
`
`value for an NADF file (say 1MB). However, this value can be set up to a
`different one at the initialization procedure if needed.
`
`5.4 Login control
`
`The login control requirement aims at tuning the auditing granularity level.
`Under the SunOS 4.1, this is achieved by setting up the system audit value
`and the user audit value for each user.
`It is desirable to allow a dynamic
`login control which can change the audit state of current processes either
`temporarily or permanently. Under SunOS level C2, there is a certain num-
`ber of C library interface routines that can be used to read the audit control
`file and alter process audit states.
`
`15
`
`QUALY800024297
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 19 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 19 of 39
`
`5.5 NADF file management
`
`The NADF file management is left to the Security Administrator who bears
`the responsibility of choosing:
`
`o a back-up/restore policy;
`
`0 secure the audit data contained in the NADF file by choosing the right
`access control available in the OS;
`
`0 organize the NADF file system so that the NADF files are well classi-
`fied.
`
`5.6 Distributed Analysis
`
`The Security Administrator is able to apply local analysis on any host at-
`tached to the audited network by specifying a rule module implementing
`such an analysis and the host (Sun workstation) this analysis must be ap-
`plied to. He can also activate a central analysis on the central machine. The
`result of the central analysis could be reports, alarms or statistical measures
`on network, host and user basis.
`
`In order to choose one or more NADF file, the Security Administrator
`must supply at the interactive console a time stamp or a time interval which
`will completely determine the sequence of NADF files to be analyzed by the
`local evaluators.
`If a time interval is specified, one or more NADF file is
`selected for analysis. This analysis terminates when it encounters the first
`record with a time stamp greater than the upper bound of this interval.
`Otherwise, if a time stamp is given, the analysis is applied to the NADF file
`whose name reflects the time interval the time stamp falls into. The analysis
`is started from the first record whose time stamp is greater or equal to the
`given time stamp.
`In this case, the analysis continues until the end of the
`last generated NADF file and then becomes on-line. When no time stamp
`is given, the analysis is performed on-line i.e, starting from the next record
`generated by the audit subsystem and converted to NADF format. This is
`the default option.
`
`the central evaluator analyzes only au-
`On the central machine side,
`dit records incoming from the other slave machines. As mentioned before,
`there is (at least) two versions running on the central machine: the central
`(or master) version which performs the network level analysis and a slave
`version which performs a local analysis. These two versions differ only by
`
`the origin of the NADF records stream that is analyzed. However, the mas-
`ter evaluator makes no special distinction between audit records incoming
`from the local evaluator and the other audit records sent by the remote
`workstations.
`
`16
`
`QUALY800024298
`
`

`

`Case 4:18-cv-07229-YGR Document 192-5 Filed 04/19/21 Page 20 of 39
`Case 4:18-cv-O7229—YGR Document 192-5 Filed 04/19/21 Page 20 of 39
`
`The above functionalities clearly fulfill the high-level global and local
`analysis presented in chapter 2. On-line (local or global) analysis is realized
`by activating the desired rule module on the chosen host (slave or master).
`Off-line analysis (global or local) analysis is also fulfilled by specifying a time
`stamp or a time interval.
`
`In addition, nothing precludes the possibility of running more than one
`evaluator process on a single workstation. Moreover, this lends itself to the
`very interesting possibility of having scalable network analysis by consider-
`ing many different global analysis as local analysis that produces records for
`a second level global analysis and so on. This feature can be implemented
`without any special additional arrangements.
`
`The availability requirement is also adequately addressed thanks to the
`NADF files produced by the Format Adaptors. On the one hand, suppose
`that a given slave workstation goes down. The rest of the slave machines
`as well as the central