The Audit and Accountability (AU) Control Family: Pitfalls and Solutions

With an increasing number of systems and applications hosted in the cloud, auditing plays a pivotal role in understanding who is accessing, and what changes are occurring, within the cloud system. But it’s tricky to get auditing right.

Below, we will discuss some of the most common auditing pitfalls, as well as solutions to ensure that auditing is effective for the system environment.

Challenge #1: Defining Auditable Events

Defining what is being audited is as critical as turning auditing on in the first place. For example, it is important to have both auditing and logging turned on when adding and/or deleting users or tables in a database. If one or both are off, critical actions may be missed, especially if malicious activity is occurring.

That said, auditing every action could diminish valuable storage space for crucial events such as account activity and deleting/adding tables, etc. it is important to have the systems owner, administrators, operations, and management in sync on what events should be auditable within the system environment.  As the potential threat landscape changes, periodic reviews should occur to determine if auditing needs to increase and/or decrease in certain areas.

For our clients dealing with FedRAMP compliance, minimum events that must be captured on system components are: successful and unsuccessful account login events, account management events, object access, policy change, privileged functions, process tracking, and system events for web applications. For Web applications: all administrator activity, authentication checks, data deletions, data access, data changes, and permission changes must be captured.

Challenge #2: Failure to Audit All Systems Within the Environment

Once auditable events are defined, the second most important step is to ensure that all systems are being audited. Aggregating logs with a Security Information and Event Management (SIEM) tool helps to collect all logs in one place to ensure that all systems report in.

With the SIEM tool, reports can be generated displaying which systems are forwarding logs.  This report can be compared against host discovery scans or inventory spreadsheets to ensure all systems are logging required events for each system component.

This is especially important for incident response because hackers or even insider threats will use methods to cover their tracks. A common attack technique is to maliciously turn off logging or deleting/modify logs. These types of actions should be flagged as incidents, and alerts should be sent to security personnel.

Additionally, if auditing is not occurring on all systems, hackers could exploit this, causing potential harm within the environment. It is critical to have processes in place as new system components are installed, such as having logging enabled and forwarding all logs to a SIEM tool for log aggregation. Potential threats from log aggregation can then be investigated in real-time or near-real time within dashboards of the SIEM ensuring the information system is in a secure state.

Challenge #3: Failure to Configure Logging Correctly

A key component of logging is to ensure that logs are detailed and formatted correctly, so that they can be traced back to a person or action, how the event occurred, when the event occurred, and on what system component. Logs, especially when a SIEM is being used, may become garbled. Adjustments need to be made from either the SIEM tool or from the system component to ensure proper formatting.

Most SIEM tools allow you to configure what type of log source you are ingesting logs from so that the logs are formatted correctly. Having who, what, where and why is crucial for incident response. If you cannot determine all of those “w’s” within the log file, then auditing configuration needs to change.

Challenge #4: Failure to Sync All System Components to the Same Time Source

Setting the correct time source for all logs helps with log analysis across multiple components. If system components are syncing to different time sources and time zones, or not syncing system clocks at all, then event times are inconsistent and thus it is harder to determine when an event occurred. Government systems usually sync to Naval or NIST time servers. NIST guidance for syncing time can be found here. Naval NTP servers can be synced by time zone and can be found here.

The most secure setup is to have dedicated Network Time Protocol (NTP) servers sync time to an official time source. Then all servers within the information system sync with the NTP servers so not all system components must reach out over the internet for syncing.

NTP is typically setup on domain controllers. However, NTP servers can also be stand-alone servers. All system components can then be configured to do a time sync at the desired interval. Having all information system components synced to the same NTP servers ensures that event times are accurate and consistent across the environment.

Challenge #5: Protecting Audit Information from Unauthorized Modification

Who has access to audit logs & can modify or delete them? This is often overlooked, both on the system component level as well as the SIEM tool. Permissions or role-based access needs to be clearly defined and enforced to ensure that deletion or modification of logs is restricted.

Achieving this depends on how access management is enforced within the environment. For example, Active Directory can be configured to only allow certain permissions for who can delete or modify logs locally. As for the SIEM tool, I recommend configuring one account (an emergency use only, “break glass” type) with access to delete or modify logs from within the SIEM tool. The key is to strictly limit the ability of users to mess with log data.

Challenge #6: Devices that Don’t Log

Sometimes audit log configuration is only partially configured locally on the component or application, or not all logs are being forwarded to the SIEM tool. Once the auditable events are defined by the organization, or by FedRAMP parameters, they need to be configured locally within the system component or application to log those events.

Once logging is established on the component, then ensure that all logs are forwarded to the SIEM. Logs collected for defined audible events are crucial to maintaining compliance for auditing within the system boundary.

Wrapping Up

Contact 38North and we can help you evaluate and improve your auditing processes to achieve compliance and enhance security.