MODULE 3

CHAPTER 1 – AUDITING
DEFNITIONS:
• Logging is the recording of events or statistics to provide information
about system use and performance.

• Auditing is the analysis of log records to present information about

the system in a clear and understandable manner.
• Logs help analyze a system’s security by recording events and changes .So
the system state can be reconstructed or investigated after a compromise.
Even partial logs help narrow down possible causes of security problems.

• According to Gligor, audit logs also help evaluate protection mechanisms,

establish normal usage patterns for intrusion detection, record all privileged
operations, and deter attacks through accountability.

Intrusion Detection means finding unauthorized or

suspicious activities in a computer system or network.
• Two key issues arise:

• What to log – identifying which system events, commands, system

calls, and object changes are relevant for detecting policy violations.

• What to audit – determining which recorded events must be

examined based on the security policy and how attacks might occur.

• Logging gathers data; auditing selects and analyzes the relevant parts
for security.
Anatomy of an Auditing System :
• An auditing system consists of three components:

the logger

the analyzer

the notifier

• These components collect data, analyze it, and report the results.
Logger :
• Logging mechanisms record information.

• The type and quantity of information are dictated by system or program

configuration parameters.

• The mechanisms may record information in binary or human-readable

form or transmit it directly to an analysis mechanism.

• A log-viewing tool is usually provided if the logs are recorded in binary

form, so a user can examine the raw data or manipulate it using
text-processing tools.
 • Example : RACF is a security tool for IBM systems. It keeps audit logs of important
security-related actions, such as:

• Failed access attempts

• Use of special privileges

• Any interaction with RACF itself

RACF (Resource Access Control Facility) is a security

system used on IBM mainframes to control who can access
what.
The command LISTUSER is a RACF command that displays
all security-related information about a specific user
account.
• The example shows the output of the RACF command LISTUSER, which displays all
security-related details about a user, such as:
• Username and owner
• When the account and password were created
• Password expiry interval
• User attributes (like special privileges)
• Last access date and time
• Groups the user belongs to, along with their access rights
• Logon permissions (days/times)
• RACF can also log whenever a user tries to change RACF settings. This helps detect
unauthorized attempts to modify security controls.
• Example : How Windows NT handles event logging — the process of recording
important system and security activities.
• Windows NT has three types of logs:
• System Event Log
• Records system-level events like crashes, hardware failures, and services failing.
• Application Event Log
• Applications write their own messages here (errors, warnings, status updates).
• Security Event Log
• Records security-critical events such as:
• Logins/logouts
• File access attempts
• Privilege use
• Process creation/termination
• Only administrators can read this log.
• How a Log Record Looks

• Each log entry contains:

• Header (event ID, date/time, user ID, computer name)

• Description (what happened)

• Possibly extra data

• Entries are stored in binary form, and the Event Viewer displays
them in readable format.
 The sample record shows:

• Date/Time: 2/12/2000 at 13:03

• Type: Success (event completed successfully)

• Source: Security log

• Event ID 592: "A new process has been created"

• User: Administrator

• Action: Administrator launched Internet Explorer

What Happens When the Log Becomes Full?
([Link])
The administrator can choose one of these actions:
•Shut down the system • Process IDs: IDs of the new process and the parent process
•Stop logging • This means the system was configured to log successful
•Overwrite old entries process creations.
•Discard oldest events
This prevents security logs from being lost or ignored.
Analyzer
• The analyzer takes log data as input.
• It evaluates that information to detect patterns, problems, or important
events.
• It may trigger actions — like updating logs or detecting security issues.
Example 1 — Remote login monitoring
• Patterns detect entries with rlogin or telnet
• But exclude:
• localhost connections
• any system ending in .[Link] (local domain)
Helps identify external connections, useful for detecting unauthorized
access.
Example 2 — Database query control
•Logs all user queries
•Analyzer checks new queries against old ones
•If too many answers overlap, it detects possible information
leakage
Example 3 — Intrusion Detection System (IDS)
•Logs are analyzed to find:
• Unexpected activities
• Known attack patterns
•IDS uses this analysis to detect security threats
Notifier
• The notifier receives results from the analyzer.
• It alerts relevant parties (admins, security teams, or automated
systems).
• It may also take corrective actions.

Example 1 — swatch notifications

• When rlogin/telnet is detected,
• It sends email alerts to staff: mail staff
Example 2 — Database query control

•Blocks responses if they violate security rules

Example 3 — Failed login attempts

•After 3 failed attempts, system:

•Notifies administrator
•Disables the user account (automated security action)
Designing of an Auditing System :
• A logging subsystem collects raw security-related events.
An auditing mechanism analyzes those logs to:
✔ detect violations of security policies
✔ detect entry into insecure states
✔ trigger appropriate responses

• So, what we log depends on what we want to audit

Security Policy → Determines What Must Be Logged
• Let Ai = all actions possible in a system
• Let pi = constraints defined by the security policy
(rules the system must satisfy to remain secure)
• If any action can break a rule, that action must be logged.
How to Represent Constraints
• Constraints written as:
action ⇒ condition
• Action happens → condition must be true.
• If action occurs and condition is false → security violation
Example:
• If a user reads a file → they must have permission.
Why include the result?

• If the constraint is satisfied → success/failure doesn’t matter.

• If the constraint is violated and action was successful.

→ security breach detected.

Example — Bell-LaPadula Policy

There are different security levels like:

Unclassified < Confidential < Secret < Top Secret

❖ Subject S with level L(S) - Subject (S) → person or program

❖ Object O with level L(O) - Object (O) → file or data

Bell-LaPadula Rules:

1. No Read Up (Simple Security Rule)

• A person cannot read information above their level.
• Example:
A Confidential user cannot read a Secret file.
(Because that would reveal higher secrets!)
• Rule:
S reads O ⇒ L(S) ≥ L(O)
2. No Write Down
• A person cannot write information to a lower security level.
• Example:
A Secret user cannot save data into Unclassified level.
(Because secret info may leak!)
• Rule:
S writes O ⇒ L(S) ≤ L(O)
Implementation Considerations
System may not start in a secure state

• Security models assume rules must always be followed.

• But a system might already be insecure when it starts.

• So, when auditing logs, we must also record the initial state of the
system.

• If only actions are logged, we may miss security problems that already
existed.

Therefore, Log the initial security state at system startup.

What exactly is a “write”?

• In theory, Bell–LaPadula logs “write” actions.

But in real systems, write can mean many different operations:

• create file

• append data

• change file permissions

• change system clock

• Some of these may create covert channels (secret ways to send

information), so they must also be logged.
Naming issues in logging
Objects (like files) can have multiple ways of access.
Example (UNIX):
•Access via file name (normal)
•Access via disk blocks and inodes (raw access)
Most systems only log file name access, but raw access may bypass
logs → making logs incomplete.
Therefore, Log all access to an object, regardless of how it is named
or accessed.
Syntactic Issues
• When logs are recorded, it is important that the information is clear and
unambiguous.
Otherwise, the auditor cannot correctly understand what happened.
Main Problem
Logs sometimes:
• Do not contain enough details
• Use confusing file names
• Lack context (who did what, where, and how)
• So, the same log entry may look like one action but actually refer to a
different action.
• Example

A UNIX log shows:

/etc/passwd

• It looks like someone accessed the system password file.

But if the user is anonymous, it is actually a different file inside an FTP
folder.

• This means one log line is not enough to understand the full action.
We must analyze context along with log entries.
Suggested Solution: Grammar-Based Logging
Researchers (Flack & Atallah) suggest:
• Use a formal grammar like BNF to define log structure
• Every log must follow the same syntax and meaning
• Tools can then accurately parse and analyze logs
entry: date host prog [FAILED] user ["from" host] "to" user "on" tty
• Benefits:
✔ Consistency
✔ No ambiguity
✔ Easier for analyzers to extract correct data

BNF stands for Backus–Naur Form.

It is a notation (formal language) used to describe the syntax or structure of
programming languages, commands, and log formats.
LOG SANITAIZTION
• Logs collected by a computer system may contain confidential or private
information.

• Before sharing the logs with someone else, the confidential information must be
removed or [Link] process is called sanitization of logs.

Definition : Let U be a set of users. The policy P defines a set of information C(U )
that members of U are not allowed to see. Then the log L is sanitized with respect to
P and U when all instances of information in C(U ) are deleted from L.

A log L is sanitized with respect to policy P and user group U when:

All confidential information that policy P says U should not see is
deleted/hidden from the log.
 Two Reasons for Sanitizing Logs

What is being Who cannot see Where sanitizer

Type
protected? the data? works
Company-sensitive
information (e.g., Sanitizer removes
Company People outside the
project names, IP information after
confidentiality site
addresses in the log is created
company)
System
Sanitizer removes
Privacy of users administrators
User privacy information before
using the system should not spy on
log is written
users
There are two sanitizer placements
After logging → protects company secrets from outsiders
Before logging → protects users from system admins spying
Two Types of Sanitizers :

Definition : An anonymizing sanitizer deletes information in such a way that it

cannot be reconstructed by either the recipient or the originator of the data in the
log. A pseudonymizing sanitizer deletes information in such a way that the
originator of the log can reconstruct the deleted information.
Can original data be
Type of Sanitizer
recovered?
Deletes information
Anonymizing Sanitizer No one can reconstruct it
permanently
Pseudonymizing Replaces data with a Only authorized originator
Sanitizer pseudonym can reconstruct it later
Example : Humongous Corporation has IP addresses:
[Link] --- A
[Link] --- B
[Link] --- C
[Link] --- D
[Link] --- E
Logs show a sequence of connections to port 25 (email port) in this exact order.
Problem
• If they replace IPs randomly, the order is lost → the consultant cannot detect that:
It was actually a sequential scan, which might signal an attack attempt.
Correct sanitization
• Replace the IPs with fake ones (pseudonyms) but keep the order same.
Example replacement:
A, B, C, D, E
So the consultant sees:
Port 25 → A, B, C, D, E
He can detect scanning pattern without knowing real IPs.