logo

A Guide to CIS Control 8: Audit Log Management

Introduction to CIS Control 8

CIS Control 8 Center for Internet Security (CIS) version 8 covers audit log management. (In version 7, this topic was covered by Control 6.) This security control details important safeguards for establishing and maintaining audit logs, including their collection, storage, time synchronization, retention and review.

Two types of logs are independently configured during system implementation:

  • System logs provide data about system-level events such as process start and end times.
  • Audit logs include user-level events such as logins and file access. Audit logs are critical for investigating cybersecurity incidents and require more configuration effort than system logs.

Log management

Because IT environments generate so many events, you need log management to ensure you capture valuable information and can analyze it quickly. All software and hardware assets, including firewalls, proxies, VPNs and remote access systems, should be configured to retain valuable data.

In addition, best  practices recommend that organizations scan their logs periodically and compare them with their IT asset inventory (which should be assembled according to CIS Control 1) to assess whether each asset is actively connected to your network and generating logs as expected.

One aspect of effective log management that is frequently overlooked is the need to have all systems time-synched to a central Network Time Protocol (NTP) server in order to establish a clear sequence of events.

The role of log management

Log management involves collecting, reviewing and retaining logs, as well as alerting about suspicious activity in the network or on a system. Proper log management helps organizations detect early signs of a breach or attack that appear in the system logs.

It also helps them investigate and recover from security incidents. Audit logs provide a forensic-level detail trail, including a stepwise record of the attackers’ origin, identity, and methodology. Audit logs are also critical for incident forensics, telling you when and how the attack occurred, what information was accessed, and whether data was stolen or destroyed. The logs are also essential for follow-up investigations and can be used to pinpoint the beginning of any long-running attack that has gone undetected for weeks or months.

A breakdown of CIS Control 8: Audit Log Management to guide your compliance efforts follows.

Safeguard 8.1: Establish and maintain an audit log management process

Establish and maintain an audit log management process that defines the enterprise’s logging requirements. At a minimum, address the collection, review, and retention of audit logs for enterprise assets. Review and update documentation annually or when significant enterprise changes could impact this safeguard.

Why is audit logging necessary?

Audit logs capture and record events and changes in IT devices across the network. At a minimum, the log data should include:

  • Group — The team, organization, or account where the activity originates
  • Actor — The UUIDs, usernames and API token names of the account responsible for the action
  • Event name — The standard name for a specific event
  • Description — A human-readable description that may include links to related information
  • Action — How the object was altered
  • Action type — The type of action, such as create, read, update or delete
  • When — The NTP-synced timestamp
  • Where — The country of origin, device ID number or IP address of origin

System administrators and auditors use these details to examine suspicious network activity and troubleshoot issues. The logs provide a baseline for normal behavior and insight into abnormal behavior.

Advantages of audit logging

Audit logging has the following advantages:

  • Security improvement, based on the insights into activity
  • Proof of compliance with standards and regulations like HIPAA and PCI DSS
  • Risk management to control risk levels and demonstrate due diligence to stakeholders

The four steps of audit logging

Step 1. Inventory your systems and hardware and establish preliminary priorities.

Take an inventory of all devices and systems within the network, including:

  • Computers
  • Servers
  • Mobile devices
  • File storage platforms
  • Network appliances such as firewalls, switches, and routers

Place a value on the data stored in each asset. Consider the value of the roles these assets serve and the criticality of the data for business purposes. The goal is an estimated risk assessment for each asset for future evaluation.

Step 2. Consolidate and replace assets.

Use the inventory to evaluate aging equipment and platforms for replacement. Include the estimated time required to implement replacements or consolidate platforms with a final objective of auditing your environment.

Determine easily audited assets versus assets requiring additional auditing effort. Document everything to measure progress and create a reference for auditors.

Step 3. Categorize the remaining resources from most to least auditable.

Review your remaining systems and determine how they relate to data storage or access control. Categorize the assets based on the expected likelihood of an audit. Ensure that the information at the highest risk or value is stored in the most easily audited systems.

Step 4. Look for an auditing solution that will cover the most assets in the least time.

When selecting a solution, look for a vendor with a broad set of tools and excellent customer service. The vendor should have a proven track record of delivering product enhancements and updates to keep up with constantly changing auditing requirements and the risk environment.

To simplify management, minimize the number of licenses, contacts and support arrangements. Also, look for flexible licensing, scalability and centralized long-term storage that meets your needs.

Safeguard 8.2: Collect audit logs

Collect audit logs. Ensure that logging has been enabled across enterprise assets per the enterprise’s audit log management process.

Each organization should audit the following:

  • Systems, including all access points
  • Devices, including web servers, authentication servers, switches, routers, and workstations
  • Applications, including firewalls and other security solutions

Safeguard 8.3: Ensure adequate audit log storage

Ensure that logging destinations maintain adequate storage to comply with the enterprise’s log management process.

Storing audit logs is a requirement of most legal regulations and standards. In addition, log storage is needed to enable forensic analysis for investigating and remediating an event.

Key types of data to retain include:

  • User IDs and credentials
  • Terminal identities
  • Changes to the system configuration
  • Date and time of the event
  • Successful and failed log attempts

NIST publication SP 800-92 Sections 5.1 and 5.4 speak to policy development and long-term storage management.

Log retention periods

Organizational policy should drive how long each log should store data depend on the value of the data and other factors:

  • Not stored — Data of little value
  • System-level only — Data of some value to system administration but not enough to be sent to the log management infrastructure
  • Both system-level and infrastructure level — Data required for retention and centralization
  • Infrastructure only — When system logs have limited storage capacity

The policy also sets local log rotation for all log sources. You can configure your logs to rotate regularly and when the log reaches its maximum size. If the logs are in a proprietary format that doesn’t allow easy rotation, you must decide whether to stop logging, overwrite the oldest entries or stop the log generator.

Log retention periods depend on the nature of your business and your organizational policies. Most enterprises keep audit logs, IDS logs and firewall logs for at least two months. Some regulations require anywhere from six months to seven years.

If you must retain logs for a relatively long period, you should choose a log format for all archived data and use a specific type of backup media as selected by your budget and other factors. Verify the integrity of the transferred logs and store the media securely offsite.

Safeguard 8.4: Standardize time synchronization

Standardize time synchronization. Configure at least two synchronized time sources across enterprise assets, where supported.

Each host that generates logs references an internal clock to timestamp events. Failure to synchronize logs to a central time source can cause problems with the forensic investigation of incident timelines and lead to false interpretations of the log data. Synchronizing timestamps between assets allows for event correlation and an accurate audit trail, especially if the logs are from multiple hosts.

Safeguard 8.5: Collect detailed audit logs

Configure detailed audit logging for enterprise assets containing sensitive data. Include event source, date, username, timestamp, source addresses, destination addresses, and other useful elements that could assist in a forensic investigation.

Forensic analysis of logs is impossible without details. Beyond the information stated in the safeguard, you also need to capture event entries since they provide information related to a specific event that occurred and impacted a covered device. 

Collect detailed audit logs for:

  • Operating system events — System startup and shutdown, service startup and shutdown, network connection changes or failures, and successful and failed attempts to change system security settings and controls
  • Operating system audit records — Logon attempts, functions performed after login, account changes, information, and operations

Each audit log should provide the following:

  • Timestamp
  • Event, status and any error codes
  • Service/command/application time
  • User or system account associated with the event
  • Device used and source and destination IPs
  • Terminal session ID
  • Web browser
  • Other data as required

Safeguard 8.6: Collect DNS query audit logs

Collect DNS query audit logs on enterprise assets, where appropriate and supported.

The importance of collecting DNS query audit logs

Collecting DNS query audit logs reduces the impact of a DNS attack. The log event can include:

  • Dynamic updates
  • Zone transfers
  • Rate limiting
  • DNS signing
  • Other important details

DNS risks and attacks

DNS hijacking uses malware to modify workstation-configured name servers and cause DNS requests to be sent to malicious servers. Hijacking enables phishing, pharming, malware distribution, and publication of a defaced version of your website.

DNS tunneling refers to accessing DNS queries, terms and responses containing data payloads that possibly transport malware, stolen data, bidirectional protocols, rights, and command and control information.

Denial of service (DoS) attacks increase the load on your server until it cannot answer legitimate requests.

DNS cache poisoning, also known as spoofing, is similar to hijacking, where the DNS resolver accepts an invalid source record due to a vulnerability.

Safeguard 8.7: Collect URL request audit logs

Collect URL request audit logs on enterprise assets, where appropriate and supported.

URL requests can expose information through the query string and pass sensitive data to the parameters in the URL. Attackers then obtain usernames, passwords, tokens and other potentially sensitive information. Using HTTPS does not resolve this vulnerability.

Possible risks linked to URL requests include:

  • Forced browsing
  • Path traversal or manipulation
  • Resource injection

Safeguard 8.8: Collect command-line audit logs

Collect command-line audit logs. Example implementations include collecting audit logs from PowerShell®, BASH®, and remote administrative terminals.

A threat actor can use an insecure data transmission, such as cookies and forms, to inject a command into the system shell of a web server. The attacker then leverages the privileges of the vulnerable applications. Command injection includes direct execution of shell commands, injecting malicious files into the runtime environment and exploiting configuration file vulnerabilities.

One risk connected to a command-line exploit is the execution of arbitrary commands on the operating system, especially when an application passes unsafe user-supplied data to a system shell.

Accordingly, organizations should log data about use of the command line.

Safeguard 8.9: Centralize audit logs

To the extent possible, centralize audit log collection and retention across enterprise assets.

Hackers often use the tactic of deleting local log files to eliminate evidence of their activity. A centralized, secure database of log data defeats this tactic and allows the comparison of logs across multiple systems.

Safeguard 8.10: Retain audit logs

Retain audit logs across enterprise assets for a minimum of 90 days.

The benefits of log retention include facilitating forensic analysis of attacks discovered long after the system was compromised. Many standards and regulations require audit log retention for compliance, and preservation of log data helps ensure data integrity.

Logs track all changes to records so you can discover unauthorized modifications performed by an external source or due to errors in internal development or system administration.

Safeguard 8.11: Conduct audit log reviews

Conduct reviews of audit logs to detect anomalies or abnormal events that could indicate a potential threat. Conduct reviews on a weekly or more frequent basis.

Review the logs to detect abnormal events that could signal a threat. Use them to match endpoints with inventory and configure new endpoints if needed. Also, review audit logs to ensure the system generates the appropriate logs.

Conduct reviews weekly or more frequently.

Safeguard 8.12 Collect service provider logs

Collect service provider logs, where supported. Example implementations include collecting authentication and authorization events, data creation and disposal events, and user management events.

While your service provider may guarantee security, you want to verify the integrity of the logs you receive and ensure the vendor complies with regulations. Also, in the event of an incident, you need the data for forensic analysis.

The vendor should collect authentication and authorization events, data creation and disposal events, and user management events.

As cloud computing grows, attackers are increasingly targeting services. A hacker could spoof a URL and redirect the user to a face provider site or cause other damage. If a service provider experiences a security issue, it may not notify its customers promptly. Also, you might find out the service provider doesn’t have the level of security you expect or require.

Summary

Control 8 contains updated safeguards for audit log management, a critical function required for establishing and maintaining audit logs, including collection, storage, time synchronization, retention and review.

Each safeguard addresses a facet of audit log management to help you maintain compliance with standards and provide you with information in case of audits or attacks.

FAQ

What does audit log mean?

An audit log is a method of retaining data about user-level events. It contains specific information to help identify the actor and actions taken.

What is the function of an audit log?

The log can be used for forensic analysis in case of an attack and to determine the integrity of the log data. It also provides proof of compliance with standards.

What should be included in an audit log?

An audit log should include the following:

  • Group
  • Actor
  • Action type
  • Event name and description
  • Timestamp
  • Origination location
Dirk Schrader is a Resident CISO (EMEA) and VP of Security Research at Netwrix. A 25-year veteran in IT security with certifications as CISSP (ISC²) and CISM (ISACA), he works to advance cyber resilience as a modern approach to tackling cyber threats. Dirk has worked on cybersecurity projects around the globe, starting in technical and support roles at the beginning of his career and then moving into sales, marketing and product management positions at both large multinational corporations and small startups. He has published numerous articles about the need to address change and vulnerability management to achieve cyber resilience.