Security Auditing

1. Security Auditing CS460/ECE422 Spring 2012

2. Reading Material • Chapter 18 of text

3. 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.

4. 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.

5. Logging • Application or system logging events • Create security audit trail • Debugging services/daemons • Input to intrusion detection/correlation engines

6. General Audit Architecture

7. CC Audit Functional Requirements

8. What to log? • Session initialization • Authentication information • Authorization decisions • Access to sensitive data • Changes to security policy • Key system calls • Network connections • Everything?

9. 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

10. Example Audit Events • Database containing customer sensitive information. What audit events should be logged?

11. 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?

12. 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

13. 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: LOCAL SERVICE Account Name: LOCAL SERVICE Account Domain: NT AUTHORITY Logon ID: 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: Open Key. Return Code: 0x0

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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()

20. 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

21. Example Audit Analysis Systems • Security information and event management (SIEM) • NetForensicswww.netforensics.com/products/security_information_management/ • Cisco MARS – discussed in text • LogLogichttp://loglogic.com/ucf

22. 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

23. 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