Audit COM380 University of Sunderland Harry R. Erwin, PhD

Purpose The purpose of Audit is to maintain a safe record of security-relevant events to allow: –Reconstruction of incidents, –Prosecution in court, and –In some cases, to detect real, potential, or imminent violations of system security.

Audit in a Distributed Environment Differs significantly from audit in a stand-alone system. An audit ‘trail’ is not really feasible in a distributed environment. More thought should be given to collection and management, given the amount of data collected and the vagaries of the collection process. Different hosts and servers may conflict in their naming and formats. An audit repository may be required. Local long- term storage of audit data is probably unwise.

Cracker Interest in Audit Logs An audit log shows the cracker what can be seen of his attack. –Useful in limiting the cracker’s visibility and vulnerability to identification and prosecution. –Will be removed or modified by the cracker if possible.

Common Criteria Security Audit Functionality (FAU) Security audit automatic response (FAU_ARP) Security audit data generation (FAU_GEN) Security audit analysis (FAU_SAA) Security audit review (FAU_SAR) Security audit event selection (FAU_SEL) Security audit event storage (FAU_STG)

Security Audit Automatic Response (FAU_ARP) How are audit events handled? –Alarms –Possible automatic responses Terminate offending process or user Disable attacked service Disconnection Invalidation of a user account

Security Audit Data Generation (FAU_GEN) Should define the auditable events The following should be included: –Minimal Successful use of security administration functions –Basic Attempted use of security administration functions Identification of modified attributes –Detailed Capture new values of attributes (but don’t capture passwords, cryptographic keys, and similar sensitive data).

Typical Auditable Events Access to security controlled objects Deletion of objects Change of access rights Changes to security attributes Policy checks performed for a user Use of access rights to bypass policy checks Identification and authentication Operator security actions Import/export of data from/to removable media

Security Audit Analysis (FAU_SAA) Automated analysis of system activity and audit data. –For potential violations –Profile-based anomaly detection (to generate suspicion ratings) Note this cannot detect one-time events. Security administrators need to be briefed in the meaning of the suspicion rating. Otherwise, everyone becomes a suspect, and users are motivated to evade or hack security.

Detection of Attacks Usually audit analysis cannot determine a security violation is imminent; however some system events may be significant: –Deletion of security data files –Remote user attempting to gain root access. These events can be detected using simple or complex heuristic rules.

Security audit review (FAU_SAR) Pre or post-storage audit selection based on: –Individual users or groups of users –Actions performed on specific objects or resources –Audited exceptions and alerts –Actions associated with a specific security attribute. Access to this capability should be restricted

Security audit event selection (FAU_SEL) Not all events need or should be audited. The security supervisor should be allowed to select events based on: –Object identity –User identity –Subject identity –Host identity –Event type

Security audit event storage (FAU_STG) Requirements on storing audit data for later use. Note audit data should not be generally accessible to users. Requirements for controlling the loss of audit data due to: –System failure –Attack –Exhaustion of storage space

Conclusions If you don’t maintain an audit trail, you don’t know when you’re attacked and can’t figure out what you may have lost. Be selective. Monitor your audit trails.