Auditing

Computer Security | Lecture Eight

 Topics
 Introduction  Detect any Violation of a Stated
Policy
 What is Auditing?
 Detect Actions known to be Part of
 Audit System Structure an Attempt to Breach Security
 Logger
 Auditing Mechanisms
 Analyzer
 For Secure System
 Notifier
 For Non-Secure Systems
 Designing an Audit System  Audit Browsing
 Application and System Logging  Browsing Techniques
 A posteriori Design  Key Points

2
 Reading

 Computer Security Art and Science

(Second Edition); Matt Bishop,
2019, Addison-Wesley
 Chapter 25 - Auditing

The Contents of this Lecture Note was adapted from the Text

3
 Topics | Lecture Progress
 Introduction  Detect any Violation of a Stated
Policy
 What is Auditing?
 Detect Actions known to be Part of
 Audit System Structure an Attempt to Breach Security
 Logger
 Auditing Mechanisms
 Analyzer
 For Secure System
 Notifier
 For Non-Secure Systems
 Designing an Audit System  Audit Browsing
 Application and System Logging  Browsing Techniques
 A posteriori Design  Key Points

4
 Introduction
 Auditing is a technique for  Auditing plays a major role in
determining security  Detecting security violations
violations. and
 This lecture presents the  Post-mortem analysis to
determine precisely what
notions of happened and how.
 Logging: Recording of system
 This makes an effective
events and actions
 Auditing: Analysis of these Auditing Subsystem a key
records security component of any
system.
5
 Topics | Lecture Progress
 Introduction  Detect any Violation of a Stated
Policy
 What is Auditing?
 Detect Actions known to be Part of
 Audit System Structure an Attempt to Breach Security
 Logger
 Auditing Mechanisms
 Analyzer
 For Secure System
 Notifier
 For Non-Secure Systems
 Designing an Audit System  Audit Browsing
 Application and System Logging  Browsing Techniques
 A posteriori Design  Key Points

6
 What is Logging?
 Logging is the recording of events or statistics to provide
information about system Use and Performance.
 Logs provide a mechanism for analysing the system security state,
 Determine if a requested action or the sequence of events will put the
system in a nonsecure (compromised) state.
 System’s state can be reconstructed at any time from logged events
that cause state transitions, and the previous and new values of the
objects changed
 The Log need not be on the computer.
 E.g. images from a camera may play a role in the analysis of system state.

7
 What is Auditing?
 Auditing is the Analysis of log resource usage, which are critical
for some Intrusion Detection
records to present Systems
information about the system  Auditing mechanisms must
in a clear and understandable  Record any use of privileges
manner.  Controlled access to Ordinary
users Vs Empowered users
 Allows systems analysts to review
 Provide some level of assurance
patterns of usage to evaluate the
that any violation of security
effectiveness of protection
policies will be detected
mechanisms.
 These patterns can be used to
establish expected patterns of

8
 Uses and Problems of Auditing
 Uses presence of record
 Describe Security state  Problems
 Determine if system enters  What do you Log?
Unauthorized state  Hint: looking for violations of
 Evaluate effectiveness of a policy, so record at least
protection mechanisms what will show such violations
 Determine which  What do you Audit?
mechanisms are appropriate  Need not audit everything
and working
 Key: What is the policy
 Deter attacks because of
involved?
9
 Topics | Lecture Progress
 Introduction  Detect any Violation of a Stated
Policy
 What is Auditing?
 Detect Actions known to be Part of
 Audit System Structure an Attempt to Breach Security
 Logger
 Auditing Mechanisms
 Analyzer
 For Secure System
 Notifier
 For Non-Secure Systems
 Designing an Audit System  Audit Browsing
 Application and System Logging  Browsing Techniques
 A posteriori Design  Key Points

10
 Audit System Structure

 An Auditing System consists of three

components:
 The Logger, Analyzer, and Notifier.
 Logger: Records information, usually controlled by
parameters
 Analyzer: Analyzes logged information; Looking for
some violations or not
 Notifier: Reports results of analysis

11
 Audit System Structure
The Logger
 Type and Quantity of directly to an Analysis
information recorded mechanism.
controlled by system or  Log-viewing Tool is provided if
program configuration the logs are recorded in binary
form
parameters
 Users can examine the raw data
 The Logging mechanisms or manipulate it using text-
may record information in processing tools.
Binary or Human-readable  The Space available and
Form then transmit it portability influence Storage
Format.
12
 Audit System Structure
Logger | Example-Windows 11
 Microsoft’s Windows 11 records events out, system file accesses, and other
using the Windows Event Log events
Service and stores them in log  Setup Event Log records events
 occurring during application installation
Different logs for different types of
 Forwarded Event Log records entries
events
forwarded from other systems
 System Event Logs record system
 Logs are Binary
crashes, component failures, and other
system events  Use event viewer to see them
 Application Event Logs record events  If Log full
that applications request be recorded  Can have system Shut Down,
 Security Event Log records security-  Logging Disabled or
critical events such as logging in and
 Logs Overwritten

13
Snapshot | Windows Event Log Service

14
 Audit System Structure
The Analyzer
 An Analyzer takes a Log as input and analyses it.
 One or more logs may be analyzed
 Logs may come from Multiple Systems, or a Single
system
 The results of the analysis may lead to
 Changes in the data being recorded,
 Detection of some event or problem,
 or both of the above
15
 Audit System Structure
Analyzer | Examples

 Query Set Overlap Control in Information

Retrieval from databases
 If too much overlap between current query and past
queries, do not answer
 Intrusion Detection analysis engine (director)
 Takes data from sensors and determines if an intrusion is
occurring

16
 Audit System Structure
Notifier

 The analyzer passes the results of the analysis to the

Notifier
 The Notifier is responsible for informing the analyst,
and other entities, of the results of the audit.
 The entities may take some action in response to these results
 Such as Reconfigure Logging and/or Analysis on basis of
results

17
 Audit System Structure
Notifier | Examples
 Query Set Overlap Control in Query Set
Overlap Control in Information Retrieval from
databases
 Prevents response from being given if too much overlap
occurs
 Three failed logins in a row disable user account
 Notifier disables account and notifies sysadmin

18
 Topics | Lecture Progress
 Introduction  Detect any Violation of a Stated
Policy
 What is Auditing?
 Detect Actions known to be Part of
 Audit System Structure an Attempt to Breach Security
 Logger
 Auditing Mechanisms
 Analyzer
 For Secure System
 Notifiers
 For Non-Secure Systems
 Designing an Audit System 
Audit Browsing
 Application and System Logging  Browsing Techniques
 A posteriori Design  Key Points

19
 Designing an Audit System
 The Audit System is an occurred or
 If certain states have been
essential component of
entered.
security mechanisms
 The Goals of the Auditing
 It is built on the data from
the logging subsystem, Process determines
 Analyses information related  What information is logged
to the security state of the  Which Policy has been
system and determines if violated
 Specific actions have

20
 Designing an Audit System
 There are three considerations in the Design of Audit
Systems
 Implementation Considerations
 Assessment of the System’s Initial State and Logging requirements
 Syntactic issues
 How to Log
 Log Sanitization
 Dealing with confidential Log information based on Confidentiality
Policies

21
 Designing an Audit System
Implementation Issues (1 of 2)

 Analysing specific Rules and Axioms of the model

that underlies a system reveal
 The Requirements that informs the amount of information
to be logged to detect security violations

22
 Designing an Audit System
Implementation Issues (2 of 2)
 One need not assume that the One can Use Auditing to
system begins in a Secure detect
(or valid) state.  Actions that violate security or
 A system is not secured if the  Systems that are not secured
auditing of the logs shows a  This would require that the
security violation Initial State of the system is
 However, it could still be not captured
 This means recording at start
secured without showing a
violation if the initial state of the time the information that would
be logged on changes in the
system is non-secure.
system States

23
 Designing an Audit System
Syntactic Issues
 One critical issue with  Log data Ambiguously or

Auditing Systems is How to  Do not present enough context

to tell what elements the log
Log
entry are referring to
 What data should be placed in
 Solution would be to use Formal
the log file
Grammar to ensure well-
 How it should be expressed to
defined syntax of log files
enable analyst provide a well
 The grammar (e.g. expressed
reasoned conclusions.
using BNF), forces the designer
 However, the Problem is that to specify the syntax and
semantic content
many systems
24
 Designing an Audit System
Log Sanitization ( 1 of 2)
 Logs may contain Confidential  Confidentiality policies may
Information from a site and impact logs in two ways
must be deleted if the log is to  Information C(U) can’t leave Site
be made available.  People inside the site are trusted
and info is not sensitive to them
 Definition
 Information C(U) can’t leave
 Let U set of users, P policy defining
System
set of information C(U) that U
 People inside site not trusted or
cannot see; Log L is Sanitized wrt
(more commonly) information
P and U when all information in sensitive to them
C(U) deleted from the Log L.  Don’t log this sensitive information

25
 Designing an Audit System
Logging Sanitization (2 of 2)

 Log Organization
 Preventing information from leaving Site
 Users’ Privacy not protected from system administrators, other
administrative personnel (Sanitized for External Viewing)

 Preventing information from leaving System

 Data simply not recorded, or data scrambled before recording (Sanitized
for Privacy of Viewers)

26
 Designing an Audit System
Log Reconstruction
 If data must recovered in  Anonymizing Sanitizer
 Cannot be undone as there is
the future, the Sanitizer no way to recover data from this
can either use  Pseudonymizing Sanitizer
 A Cryptography to protect the  Can be undone and the
data by encrypting it or Original Log can be
 A Cryptographic Scheme reconstructed

allowing a re-identifier to  Sanitization must preserve

reassemble the un-sanitized data properties needed for security
 This suggests 2 Types of analysis in the Auditing
system.
Sanitization:
27
 Designing an Audit System
Key Issue in Sanitization
 The key to sanitization is not simply hiding data;
 It also requires hiding the relationships between the hidden
data and the data that is not hidden.
 If a log is to be sanitized to provide anonymity, the
simplest technique is simply not to collect the data.
 However, pseudonymity requires that the data be collected.
 Two techniques provide the hiding ability include
 Devise set of Pseudonyms
 Use random key to Encipher sensitive data

28
 Designing an Audit System
Key Issue in Sanitization
 Generation of Pseudonyms
1. Devise set of Pseudonyms to replace sensitive
information
• Replace data with pseudonyms
• Maintain table mapping pseudonyms to data
2. Use Random Key to encrypt sensitive data and use secret
sharing scheme to share key
• Used when insiders cannot see un-sanitized data, but outsiders
(law enforcement) need to
29
 Topics | Lecture Progress
 Introduction  Detect any Violation of a Stated
Policy
 What is Auditing?
 Detect Actions known to be Part of
 Audit System Structure an Attempt to Breach Security
 Logger
 Auditing Mechanisms
 Analyzer
 For Secure System
 Notifiers
 For Non-Secure Systems
 Designing an Audit System  Audit Browsing
 Application and System  Browsing Techniques
Logging  Key Points
 A posteriori Design
30
 Application and System Logging
 Applications Logs are created by Applications
 Applications control what is logged and typically use high-
level abstractions
 Does not include detailed, system call level information such as
results, parameters, etc.
 System Logs system events such as kernel actions;
 They report system calls and Low-level events
 Does not include high-level abstractions such as loading
libraries
31
 Application Logs Vs. System Logs
 Difference in Focus causes (why did access fail?)
 Application Log focuses on  Advantages
Application Events,  System Logs: Completeness
 E.g. Failure to supply proper Of The Information
password, and the broad  System logs usually much
operation (what was the bigger than application logs,
reason for the access and may led to log overflow.
attempt?)  Application Logs: Level Of
 System Log focuses on
Abstraction
System Events  Log data has gone through
 E.g. Memory mapping or file some interpretations.
accesses, and the underlying

32
 Topics | Lecture Progress
 Introduction Policy
 What is Auditing?  Detect Actions known to be Part
of an Attempt to Breach
 Audit System Structure Security
 Logger
 Auditing Mechanisms
 Analyzer
 For Secure System
 Notifiers
 For Non-Secure Systems
 Designing an Audit System  Audit Browsing
 Application and System Logging  Browsing Techniques
 A posteriori Design  Key Points
 Detect any Violation of a Stated

33
 A posteriori Design
 The Design of an Auditing  Goal of Auditing in this case
system is direct in the face of  Detect any Violation of a
known Possible policy Stated Policy
 Focus is on policy and actions
violations
designed to violate policy;
 Most security breaches arise in
 Specific actions may not be known
systems not designed with security
 Detect any Known Action that
considerations ab initio
Attempts to Breach Security
 A Posteriori Design:  Focus on specific actions that have
 Need to design auditing been determined to indicate
mechanism for system not built attacks
with security in mind
34
 A posteriori Design
Audit for Violations of a Stated Policy
 The idea is to determine that Actions and Settings are
consistent with Policy
whether a state violates the
 The Goal: Does system enter a
policy.
 The auditing mechanisms must be disallowed state?
integrated into the existing  Two forms of Detecting Violations
system. of a Known Policy
 The Analysts must:  State-based Auditing: Look at
current state of system
 Determine what Actions and
 Transition-based Auditing:
Settings are consistent with the
Look at actions that moves the
Policy.
system from one state to another
 Design Mechanisms to ensure

35
 Audit for Violations of a Stated Policy
State-Based Auditing
 In a state-based approach the unauthorized
states of the system are  Assumptions:
 One could get a snapshot of
analysed to determine if a
system state
policy violation exists.  Snapshot needs to be consistent
 State-based Logging  Non-distributed system needs to
mechanism records information be dormant to obtain a snapshot
about a system’s state.  Distributed system can use
 State-based Auditing Chandy-Lamport algorithm to
mechanism determines whether obtain the snapshot of system
a state of the system is state

36
 Audit for Violations of a Stated Policy
Transition-Based Auditing
 The actions that could violate if the result will place the system
the policy are checked to in an unauthorized state

determine if they do indeed  Log information about action,

cause violations. and examine current state and
 Transition-based Logging proposed transition
mechanism records info about an  To determine if new state would
action on a system. be disallowed
 Transition-based Auditing  Transition-based Auditing is
mechanism examines the current used when specific transitions
state of the system and the always require analysis (for
proposed transition to determine example, change of privilege)

37
 A posteriori Design
Audit for Known Actions that Violate Policies

 In many cases, the security policy is not stated

explicitly.
 It can be assumed that an action automatically violates policy
 Such behaviours are “nonsecure.”
 For example: an attack that floods a network to the point that it is
not usable, or accessing of a computer by an unauthorized person,
would violate the implicit security policy
 Under these conditions, analysts can determine specific
sequences of commands, or properties of states, that indicate a
security violation and look for that violation
38
 Topics | Lecture Progress
 Introduction  Detect any Violation of a Stated
Policy
 What is Auditing?
 Detect Actions known to be Part of
 Audit System Structure an Attempt to Breach Security
 Logger
 Auditing Mechanisms
 Analyzer
 For Secure System
 Notifiers
 For Non-Secure Systems
 Designing an Audit System  Audit Browsing
 Application and System Logging  Browsing Techniques
 A posteriori Design  Key Points

39
 Auditing Mechanisms

 Systems use different mechanisms

 Most common is to Log All events by Default,
 Thereafter allow the System Administrator to disable
logging that is unnecessary
 Two examples
 One audit system designed for a Secure system
 One audit system designed for a Non-secure system

40
 Auditing Mechanisms
Secure Systems
 Secured systems have Auditing Mechanisms
integrated into System Design and
Implementation.
 Such systems provide a language or interface to
configure reporting and logging
 To report specific events
 To monitor accesses by a subject
 To monitor accesses to an object
 This is controlled at the Audit Subsystem so that
irrelevant actions or accesses are not logged

41
 Auditing Mechanisms
Non-Secure Systems
 Auditing subsystems for non-secure systems are
generally for purposes of accounting
 Have some limited Logging Capabilities
 Log accounting data, or data for non-security purposes
 Possibly limited security data like Failed logins
 Auditing subsystems focusing on security usually added
after system completed
 May not be able to log all events, especially if limited kernel
modifications to support audit subsystem

42
 Topics | Lecture Progress
 Introduction  Detect any Violation of a Stated
Policy
 What is Auditing?
 Detect Actions known to be Part of
 Audit System Structure an Attempt to Breach Security
 Logger
 Auditing Mechanisms
 Analyzer
 For Secure System
 Notifiers
 For Non-Secure Systems
 Designing an Audit System  Audit Browsing
 Application and System Logging  Browsing Techniques
 A posteriori Design  Key Points

43
 Audit Browsing

 Apart form running audit mechanisms to analyse log files,

 Auditors sometimes look through the log files themselves
 Goal of the Audit Browser
 Present log information in a form easy to understand and use: Why?
 Audit mechanisms may miss problems that auditors will spot
 Mechanisms may be unsophisticated or make invalid assumptions
about log format or meaning
 Logs usually not integrated; often different formats, syntax, etc.

44
 Audit Browsing -
Browsing Techniques
 Audit browsing tools
emphasize Associations  The Techniques include:
that are of interest to the 1. Text Display
auditor. 2. Hypertext Display
 Hence, their configurations 3. Relational Database
depend on the goals of the Browsing
auditors 4. Replay
5. Graphing
6. Slicing
45
 Audit Browsing | Browsing Techniques
Text Display

 Shows the logs in a Textual Format

 The format may be fixed, or it may be defined by
the analyst through post-processing.
 Auditor may search for Events based on name, time, or
Some Other Attribute which is already recorded in the
log file.
 This method does not indicate relationships among
Events, Entries, and Entities

46
 Audit Browsing | Browsing Techniques
Hypertext Display
 Hypertext display shows the logs as a set of
Hypertext Documents with associated Log Entries
linked by hypertext constructs.
 The auditor can follow relationships between Entries and
Entities using the Hyperlinks.
 The browser can also include additional information about
entities
 Disadvantage
 The view of the log information is Local
 Browser does not highlight global relationships in a
manner that is clear and easy to understand.
47
 Audit Browsing | Browsing Techniques
Relational Database Browsing
 Requires that the logs be stored  Auditor needs advanced knowledge
of what associations are of interest.
in a Relational Database.
 Disadvantage
 Auditor issues queries to the
database, and the database  The representation of the output to
performs the Correlations and the query is usually Textual.
Associations in response to the  Some pre-processing is required
query.  The elements of the logs must be
 Advantage separated to provide the
information for the database.
 The database performs the
 There may be limit to the
correlations and after pre-
associations between entities and
processing Logs
events

48
 Audit Browsing | Browsing Techniques

Replay

 Replay presents the events of interest in Temporal

Order.
 It highlights temporal (Chronological) relationships.
 For example,
 If three logs are replayed on a single screen,
 The temporal order of the events in the log will be intermingled
 The order of occurrence across the logs will clearly indicate the
Order Of The Events in a way that the analyst can see.

49
 Audit Browsing | Browsing Techniques
Graphing
 Graphing provides a Visual be unreadable.
 However, reducing the logs to
Representation of the contents of
eliminate some information solves this
logs.
problem.
 Nodes represent entities such as
 The graph may also represent
Processes and Files,
 Edges represent the Associations High-level Entities (such as
between various entities. groups of processes or file
 Disadvantage systems) and their Relationships
  The auditor can expand the high-level
The Size of the Graph
 If the area in which the graph is drawn
entities in order to examine
is too small, the information may
relationships within the components of
those entities

50
 Audit Browsing | Browsing Techniques
Slicing
 Slicing obtains a minimum set of log events and
objects that affect a given object.
 This comes from the traditional notion of Slicing,
 Slicing is a program debugging technique that extracts a
minimum set of statements that affect a given variable.
 Advantage
 Focuses attention on the sequence of events, and related
objects, that affect some entity.
 Disadvantage
 Similar to hypertext browsing, is the locality of the technique

51
 Topics | Lecture Progress
 Introduction  Detect any Violation of a Stated
Policy
 What is Auditing?
 Detect Actions known to be Part of
 Audit System Structure an Attempt to Breach Security
 Logger
 Auditing Mechanisms
 Analyzer
 For Secure System
 Notifiers
 For Non-Secure Systems
 Designing an Audit System  Audit Browsing
 Application and System Logging  Browsing Techniques
 A posteriori Design  Key Points

52
 Summary
 Logging is Collection and Recording;
 Auditing is Analysis of the Logged files
 There is a need to have clear goals when designing an
Audit System
 Auditing should be designed into system, not patched into system
after it is implemented.
 Browsing through logs helps auditors determine
completeness of Audit and the effectiveness of audit
mechanisms
53