Forensics and

Auditing
 Computer Forensics
 Computer forensics is the science of attempting to
recover evidence on a computer system.
 Complex area:
 Legal issues heavily weigh in here.
 Technical tools are likewise complex, since a chain
of evidence must be preserved.
 However, much of this boils down to an area
called auditing. As a result, we must discuss what
audit tools are included (and appropriate) on
various systems.
 Table 18.1
Security Audit Terminology

RFC 2828
 Anatomy of an audit system

 Logger: a mechanism to record information. Generally

built into the system, but can be tailored by administrator.

 Analyzer: Takes a log as input. Result of the analysis may

lead either to changes in the data being recorded or to
detection of problem/event.

 Notifier: Takes output of analyzer and takes appropriate

action, such as notifying user or admin.
 Security
Auditing
Functions
 Event Definition
 must define the set of events that are subject to
audit
common criteria suggests:

 introduction of objects
 deletion of objects
 distribution or revocation of access rights or capabilities
 changes to subject or object security attributes
 policy checks performed by the security software
 use of access rights to bypass a policy check
 use of identification and authentication functions
 security-related actions taken by an operator/user
 import/export of data from/to removable media
 Implementation Guidelines
requirements for
agree on requirements special or additional all access should be
with management processing should be monitored and logged
defined

resources for
performing the checks document procedures,
scope of checks agreed
should be explicitly requirements,
and controlled
identified and made responsibilities
available

other access only for

checks limited to read- isolated copies of person(s) doing audit
only access to software system files, then independent of
and data erased or given activities
appropriate protection
 What to Collect

 events related to the use of the auditing software

 events related to the security mechanisms on the system

 events that are collected for use by the various security

detection and prevention mechanisms
 events related to system management and operation

 operating system access

 application access for selected applications

 remote access
 Table
18.2

Auditable
Items
Suggested
in X.816
Monitoring Areas Suggested
in ISO 27002
Figure 18.4 - Examples of Audit Trails
 figure 18.4a is an
example of a
system-level audit
trail on a UNIX
system

 figure 18.4b is an
example of an
application-level
audit trail for a mail
delivery system

 figure 18.4c is an
example of a user-
level audit trail on a
UNIX system
 Physical Access Audit Trails

 generated by equipment that controls physical access

 card-key systems, alarm systems

 sent to central host for analysis and storage

 data of interest:
 date/time/location/user of access attempt
 both valid and invalid access attempts
 attempts to add/modify/delete physical access privileges
 may send violation messages to personnel
Protecting Audit Trail Data
read/write file on write-once/read-
host many device
• easy, least resource • more secure but less
intensive, instant access convenient
• vulnerable to attack by • need steady supply of
intruder recordable media
• access may be delayed
and not available
immediately

write-only device must protect both

• provides paper trail integrity and
• impractical for capturing confidentiality
detailed audit data on • encryption, digital
large or networked signatures, access
systems controls
• useful when a permanent,
immediately available log
is required
 Implementing Logging

 foundation of security auditing facility is the initial capture

of the audit data

 software must include hooks (capture points) that trigger

data collection and storage as preselected events occur

 dependent on the nature of the software

 varies depending on operating system and applications
involved
 Windows Event Log

 event is an entity that describes some interesting

occurrence
 contains:
 a numeric identification code
 a set of attributes
 optional user-supplied data

 three types of event logs:

 system: system related apps and drivers
 application: user-level apps
 security: Windows LSA
Windows
Event
Schema
Elements
Windows System Log Example
Windows Event Categories

account logon
events
account
privilege use managemen
t

directory
policy
service
changes
access

object access logon events

 UNIX Syslog
 UNIX's general-purpose logging mechanism
 found on all UNIX / Linux variants

elements:

syslog() logger /etc/syslog.conf syslogd

API referenced by
command used to configuration file
several standard daemon to
add single-line used to control the
system utilities and receive/route log
entries to the system logging and routing
available to events
log of system log events
application programs
 Syslog Service

basic service provides:

a means of
capturing relevant
events
extra add-on features may
include:
a storage facility

alternative
robust event log file database
log analysis message rate limiting
filtering response encryption storage
a protocol for formats
transmitting syslog
messages from
other machines to a
central machine
that acts as a
syslog server
 Syslog Protocol
 a transport allowing hosts to send IP event notification
messages to syslog servers
 provides a very general message format
 allowing processes and applications to use suitable conventions for
their logged events

 common version of the syslog protocol was originally

developed on the University of California Berkeley Software
Distribution (BSD) UNIX/TCP/IP system implementations
 messages in the BSD syslog format consist of:
 PRI - facilities / severity code
 header – timestamp and hostname/IP address
 Msg - program name and content
Syslog Examples
Syslog Facilities and Severity Levels

(a) Syslog Facilities

(b) Syslog Severity Levels

 Logging at Application Level
 privileged applications present security issues
 may not be captured by system/user-level audit data
 constitute a large percentage of reported vulnerabilities

 vulnerabilities exploited:
 lack of dynamic checks on input data
 errors in application logic
 may be necessary to capture behavior of application
beyond its access to system services and file systems
 two approaches to collecting audit data:
 interposable libraries
 dynamic binary rewriting
 Interposable Libraries

 allows the generation of audit  statically linked libraries

 a separate copy of the linked library
data without needing to function is loaded into the program’s
recompile either the system virtual memory
libraries or the application  statically linked shared libraries
 referenced shared object is
 audit data can be generated incorporated into the target executable
without changing the system’s at link time by the link loader
shared libraries or needing access  each object is assigned a fixed virtual
address
to the source code for the
 link loader connects external referenced
executable objects by assigning their virtual
addresses when the executable is
 exploits the use of dynamic created
libraries in UNIX  dynamically linked shared libraries
 the linking to shared library routines is
deferred until load time
 if changes are made to the library prior
to load time any program that
references the library is unaffected
 Use of an
Interposable
Library
 Example of Function
in the Interposed Library
 Dynamic Binary Rewriting

 can be used with both statically and dynamically linked

programs
 postcompilation technique that directly changes the binary
code of executables
 change is made at load time and modifies only the memory image
of a program
 does not require recompilation of the application binary

 implemented on Linux using two modules:

 loadable kernel module
 monitoring daemon

 loadable modules
 can be automatically loaded and unloaded on demand
 Audit Trail Analysis

 analysis programs and procedures vary widely

 must understand context of log entries

 relevant information may reside in other entries in the same
logs, other logs, and nonlog sources

 audit file formats contain mix of plain text and codes

 must decipher manually / automatically

 ideally regularly review entries to gain understanding of

baseline
 Types of Audit Trail Analysis

 audit trails can be used in multiple ways

 this depends in part on when done

 possibilities include:
 audit trail review after an event
 triggered by event to diagnose cause and remediate
 focuses on the audit trail entries that are relevant to the specific
event
 periodic review of audit trail data
 review bulk data to identify problems and behavior
 real-time audit analysis
 part of an intrusion detection function
 Audit Review

 audit review capability provides administrator with

information from selected audit records
 actions of one or more users
 actions on a specific object or resource
 all or a specified set of audited exceptions
 actions on a specific system / security attribute

 may be filtered by time / source / frequency

 used to provide system activity baseline

 level of security related activity

Approaches to Data Analysis
basic alerting

• indicate interesting type of event has occurred

baselining

• define normal versus unusual events / patterns

• compare with new data to detect changes
• thresholding is the identification of data that exceed a particular baseline
value

windowing

• detection of events within a given set of parameters

correlation

• seeks relationships among events

 Integrated Approaches

 volume of audit data means manual analysis and

baselining is impractical
 need a Security Information and Event
Management (SIEM) system
 a centralized logging and analysis package
 agentless or agent-based
 normalizes a variety of log formats
 analyzes combined data
 correlates events among the log entries
 identifies and prioritizes significant events
 can initiate responses
 Example: Cisco MARS

 example of SIEM product

 support a wide variety of systems

 agentless with central dedicated server

 wide array of analysis packages

 an effective GUI

 server collects, parses, normalizes, correlates and assesses

events to then check for false positives, vulnerabilities,
and profiling
Table 18.6

Suggested
List of
Events
to Be
Audited