Transcript PPTX

Security Auditing
CS460/ECE422
Spring 2012
Reading Material
• Chapter 18 of text
General Definition of Audit
• From Wikipedia
– The general definition of an audit is an evaluation of a
person, organization, system, process, enterprise,
project or product.
– Audits are performed to ascertain the validity and
reliability of information; also to provide an
assessment of a system's internal control. The goal of
an audit is to express an opinion of the person /
organization / system (etc.) in question, under
evaluation based on work done on a test basis.
Security Audit
• Security audit – An independent review and
examination of a system’s records and activities to
determine the adequacy of system controls, ensure
compliance with established security policy and
procedures, detect breaches in security services, and
recommend any changes.
• Security audit trail – A chronological record of system
activities that is sufficient to enable the reconstruction
and examination of the sequence of environments and
activities surrounding or leading to an operation,
procedure, or event in a security-relevant transaction.
Logging
• Application or system logging events
– Create security audit trail
– Debugging services/daemons
– Input to intrusion detection/correlation engines
General Audit Architecture
CC Audit Functional Requirements
What to log?
•
•
•
•
•
•
•
•
Session initialization
Authentication information
Authorization decisions
Access to sensitive data
Changes to security policy
Key system calls
Network connections
Everything?
Audit Event Analysis
• Need to log enough information to review correct
enforcement of security policy
– Don’t collect enough, miss security-relevant actions
– Collect too much, negatively impact performance
• Some events dictated by need to comply with laws or
industry standards
– E.g., HIPPA, SOX, GLB, PCI
• Timestamped
• Events to consider
–
–
–
–
Session initialization (login/network)
Changes to security policy system
Access/modify sensitive data
Statistical information
Example Audit Events
• Database containing customer sensitive
information. What audit events should be
logged?
Storing Audit Trail
• Ideally, infinite write-only log
• Realistic options
–
–
–
–
–
Read/Write media with appropriate OS access controls
Write-once media such as CD-ROM
Write-only media such as paper
Write-Once Read-Many drives (WORM)
Networked system
• What should happen when audit trail space is exhausted?
• Archiving
– How long should the audit trail be stored?
– Where should it be stored?
Windows Event Log
• Three sublogs
– Security Log – generated by local security authority
– System Log – generated by system services, drivers, components
or applications affecting system health
– Application Log – generated by applications. Open to any
application
• Each event contains
–
–
–
–
Numeric ID
Timestamp
Set of attributes, e.g. task, opcode, level, version, keywords
Programmer-specified data
• Can be exported to XML form for external analysis
Example Windows Security Event
Log Name: Security
Source:
Microsoft-Windows-Security-Auditing
Date:
11/5/2011 11:58:50 AM
Event ID: 5061
Task Category: System Integrity
Level:
Information
Keywords: Audit Success
User:
N/A
Computer: Rhino
Description:
Cryptographic operation.
Subject:
Security ID:
Account Name:
Account Domain:
Logon ID:
LOCAL SERVICE
LOCAL SERVICE
NT AUTHORITY
0x3e5
Cryptographic Parameters:
Provider Name: Microsoft Software Key Storage Provider
Algorithm Name: RSA
Key Name:
5917ebdc-3374-4f30-a9fd-0f6d0e25d463
Key Type:
Machine key.
Cryptographic Operation:
Operation:
Return Code:
Open Key.
0x0
Syslog
• Event Logging system supported on Unix/Linux.
– Events can be sent across the network. Generally
using UDP. Syslog events generated by most network
devices.
• Every event contains
– PRI: The facilities and severity values (see next page)
– Header:
• Timestamp
• hostname or IP
– MSG:
• TAG – name of generating program or process
• CONTENT – details of message
Syslog Facilities
• Identifies at a coarse level the entity that generated the log
–
–
–
–
–
–
–
–
–
–
–
User – user process
Kern – system kernel
Mail – email system
Daemon – system daemon
Auth – authorization program
Lpr – printing system
News – UseNet news system
UUCP – UUCP system
Cron – cron or at
Local0-7 – Up to 8 locally defined categories
Mark – syslog, for timestamping logs
Syslog Severity Levels
• Levels
–
–
–
–
–
–
–
–
Emerg – Most sever messages such as immediate system shutdown
Alert – system conditions requiring immediate attention
Crit – critical system issues such as failing hardware
Err – other system errors
Warning – warning messages
Notice – unusual situation that merits investigation
Info – informational messages
Debug – messages for debugging purposes.
• Can set severity level at system or application level
– E.g., set application’s syslog level to Err
• Application will ignore calls generate info level syslog messages
• Application will generate syslog messages for severity levels of err and above
Example syslog message
• From the auth.log on a unix system
– Nov 27 12:16:19 lab1 sshd[19556]:
Accepted password for root from XX.XX.XX.XX port
61177 ssh2
Network Security Events
• Network Device generates syslog messages
• Intrusion Detection Device creates events
• Netflow Events
– Track the start and end of network flows
• Encodes 5 tuple and timestamps
– Generated directly by Cisco devices
– Created indirectly by network appliances
Ensuring Applications Audit
• Review/rewrite application to insert audit log
calls
• Interpose library
– Use dynamically linked library to audit then
perform the original library call
– E.g., Audit the open of a file before calling open()
or fopen() or CreateFile()
Audit Analysis
• Originally envisioned to be direct human analysis
– Still the case for some forensic analysis, but generally some
analysis tools are used
• Baselining
– Understand the time of audit events generated in normal
situations. Do anomaly detection against the baseline
• Never Seen Before – DHCP example
• Thresholding – only concerned if events fall beyond a
threshold
– E.g., volume of data acquired or number of failed connections
• Windowing – only concerned with events that fall outside a
timing window
– E.g., login events outside the normal office hours
Example Audit Analysis Systems
• Security information and event management
(SIEM)
• NetForensics
www.netforensics.com/products/security_info
rmation_management/
• Cisco MARS – discussed in text
• LogLogic http://loglogic.com/ucf
Cisco MARS Steps
• Parse Log Events
– Very hard to keep up all devices and versions of
software. Log messages containing critical
information are generally free-form.
• Normalize information to a common log format
• Perform correlation analysis to link related events
– Create sessions
• Run sessions and unrelated events against rule
engine
• Do some fixups to avoid false positives
Conclusions
• Audit Trail is necessary
– Tends to be overlooked or haphazardly generated
– No direct functional benefit
– Essential to determine that things are operating per
security policy requirements
• Audit Trail Analysis
– Valuable source of information for unexpected action
– Difficult to keep up to date with changes to audit
message format