Security Audit Logging Guideline

Requirement

Resource Custodians must maintain, monitor, and analyze security audit logs for covered devices.

Description of Risk

Without appropriate audit logging, an attacker's activities can go unnoticed, and evidence of whether or not the attack led to a breach can be inconclusive.

Recommendations

Regular log collection is critical to understanding the nature of security incidents during an active investigation and post mortem analysis.  Logs are also useful for establishing baselines, identifying operational trends and supporting the organization’s internal investigations, including audit and forensic analysis.  In some cases, an effective audit logging program can be the difference between a low impact security incident which is detected before covered data is stolen or a severe data breach where attackers download large volume of covered data over a prolonged period of time.

In the context of MSSEI, logs are composed of event entries, which capture information related to a specific event that has occurred impacting a covered device.   Log events in an audit logging program should at minimum include:

  1. Operating System(OS) Events
    • start up and shut down of the system 
    • start up and down of a service
    • network connection changes or failures
    • changes to, or attempts to change, system security settings and controls
  2. OS Audit Records
    • log on attempts (successful or unsuccessful)
    • the function(s) performed after logged on (e.g., reading or updating critical file, software installation)
    • account changes (e.g., account creation and deletion, account privilege assignment)
    • successful/failed use of privileged accounts
  3. Application Account Information
    • successful and failed application authentication attempts
    • application account changes (e.g., account creation and deletion, account privilege assignment) 
    • use of application privileges
  4. Application operations
    • application startup and shutdown
    • application failures
    • major application configuration changes
    • application transactions, for example,
      • e-mail servers recording the sender, recipients, subject name, and attachment names for each e-mail
      • Web servers recording each URL requested and the type of response provided by the server
      • business applications recording which financial records were accessed by each user

Source: NIST SP 800-92, Guide to Computer Security Log Management 

The details logged for each event may vary widely, but at minimum each event should capture 

  • timestamp
  • event, status, and/or error codes
  • service/command/application name
  • user or system account associated with an event
  • Device used (e.g. source and destintation IPs, terminal session ID, web browser, etc)
As an information source that keeps track of important transactions with covered system, audit logs are also a prime target for attackers who are keen to hide their activities to maximize opportunities to compromise targeted data.  To prevent attackers from hiding their activities, resource proprietors and custodians must configure strong access control around audit logs to limit the number of user accounts that can modify audit log files.  For example, it's common to grant privileges to modify audit log to only the system/application user account, and require any maintenance of audit logs to be performed through the application interface, and not through direct access to operating system console.  

If audit logs are transmitted to from one device to another device, e.g. for remote collection, resource proprietors and custodians must also ensure the transmission is secure in accordance to MSSEI encryption in transit requirement. 

All covered institutional device should also be configured to use synchronized time sources (i.e. Network Time Protocol - NTP) such that the times on these covered devices are sync to the common time source on a regular basis so that time stamps across all the logs are consistent.

Resource proprietor and custodian must also develop log retention policy to identify storage requirements for covered device logs and appropriate archival procedures to ensure useful log data are available in the case of a response required security incident or investigation.  At minimal, the audit logs for the last 30 days must be collected in easily accessible storage media. Older logs should be archived to less expensive storage media, as long as they are still accessible in the future as is required by incidents or investigation.  

Due to the complexity of an audit logging program implementation, it is strongly recommended that resource proprietors and resource custodians enroll in the campus-provided audit logging service described below.

Campus Service

The Information Security Office (ISO) has implemented Campus Log Correlation Program, an enterprise grade audit logging software solution (based on HP ArcSight), to aid in managing, correlating, and detecting suspicious activities related to the campus' most critical data assets.  This service's advanced detection capabilities enable ISO to correlate events in multiple dimensions - by identity, vulnerability, asset, time, patterns and other events -  across firewalls, web servers, system access logs, and other core central Security Services such as Vulnerability and Intrusion Detection to determine if a system has been successfully attacked, is currently being probed for attack, or detect advanced threats before they cause damage.  

To enroll in ISO Campus Log Correlation Program, please email your request to security@berkeley.edu.

Topics

On This Page