Notes from the Field: Center for Internet Security Control 08 – Audit Log Management 

by Greg Halpin / July 19th, 2023

During a recent SOC 2 Gap Assessment with a medical billing company, the IT Manager and I discussed the logging and alerting tools the organization had in place. He explained that the company uses the default logging settings and capabilities of the operating systems, applications, and network gear. However, they didn’t configure any alerts. The IT team reviewed logs when there was a problem but did not conduct regular reviews. I asked the IT manager how he would know if the company network was attacked or if it was already compromised and sensitive patient data was being exfiltrated.  

The IT manager paused and shifted in his chair, his face looking perplexed. After a few moments, he said it was a good question. The anti-virus logs might turn something up, right?  

No, the anti-virus logs won’t be helpful when an attacker has accounts and access on your systems. The attacker will go undetected. The anti-virus tools also won’t tell you when patient data, including Social Security numbers and copies of driver licenses, are stolen by an attacker. An endpoint detection and response tool would show more file access detail and could potentially stop such activity, but this company uses traditional anti-virus.   

As concerning as this type of situation is, it’s a more common scenario than you might expect. Many companies have excellent logging and alerting tools in place. They log everything that is going on in their networks and have staff that can respond to alerts in real time. Other companies have nothing in place. They don’t know about attacks or even technical issues until they occur and are notified by the attackers, customers, or end users. There are a lot of reasons for this, like lack of funds to invest in such products, limited staff resources, and often a lack of knowledge. That’s when I discussed the Center for Internet Security Controls with the manager.   

With good and succinct information, the IT manager could understand what tools would help protect the company’s networks. From there, the manager should make the case to senior management to obtain the resources the company needs to properly protect itself, its customers, and patient data.   


This is the eighth instalment in Greg Halpin’s Center for Internet Security Controls series, focusing on CIS control 08 – Audit Log Management. As a reminder, the Center for Internet Security Controls are 18 critical information security controls that all organizations and information security professionals should be familiar with and implement to protect their networks and data. What’s powerful about the document is that it contains high level information that executives can understand and also has specific details about tools and procedures for technical staff to run with. 

The Overview for Control 08 – Audit Log Management is Collect, alert, review, and retain audit logs of events that could help detect, understand, or recover from an attack. 

Control 08 includes 12 sub-controls or safeguards. They are: 

  • 8.1 Establish and Maintain an Audit Log Management Process 
  • 8.2 Collect Audit Logs 
  • 8.3 Ensure Adequate Audit Log Storage 
  • 8.4 Standardize Time Synchronization 
  • 8.5 Collect Detailed Audit Logs 
  • 8.6 Collect DNS Query Audit Logs 
  • 8.7 Collect URL Request Audit Logs 
  • 8.8 Collect Command-Line Audit Logs 
  • 8.9 Centralize Audit Logs 
  • 8.10 Retain Audit Logs 
  • 8.11 Conduct Audit Log Reviews 
  • 8.12 Collect Service Provider Logs 

Why is audit log management critical?  

Audit logs may be the only method for companies to identify an attack and compromise of their network and systems. Without proper logging and auditing in place, attackers may stay active in and exploit a company network for months or years before they are identified, as was the case with the compromises of SolarWinds and the U.S. Government in 2020. With effective logging tools and log review processes in place, the victim can identify the compromise and take action to block and end the attack. In a forensic investigation, the logs will help determine how the attack was carried out, which systems were compromised, and what data the attacker exfiltrated from the organization.   

As mentioned above, the clients I work with have varied logging capabilities. Some do not do anything specific in regard to logging. I’ve worked with clients whose Windows Event Viewer Security logs on their domain controllers were overwritten after a few hours as a result of using the default retention settings. Those same companies often do not retain firewall logs besides what is stored in the buffer, which is a few hours at most.  

If these companies had a security incident, they could not rely on those logs to help them identify the source or target of an attack. Normally attackers will attempt to delete system and firewall logs to make an investigation difficult for a company. In cases like these, the attacker’s work is already done for them by the victim’s lack of effort. 

Conversely, some companies have sophisticated logging and alerting tools that are improperly configured. When I ask them to show me examples of alerts they track, they bring up a dashboard of 1.2 million “critical” entries from the past 24 hours. I ask how they filter out the actual alerts from all the noise. They shrug their shoulders. We discuss how they can narrow in on what alerts are meaningful to them and would indicate an attack or system failure.   

Successful companies in this area that I’ve worked with have centralized log management tools to collect and analyze logs for systems, applications, and network gear. Such tools include Splunk, CloudWatch, the Elk Stack (Elasticsearch and Kibana), Nagios, OpenSearch, FluentD among others. The tools allow IT security teams to create alerts based on logon activity, privileged access, suspicious logins and activity. The tools are flexible to allow teams to focus on what they need for their environments.  

Some companies utilize tools like PagerDuty, which can be configured to require a response to an alert. It texts and emails the on-call person to investigate. It will also escalate the alert to others as needed until someone acknowledges the alerts. Critical and specific alerts can automatically be sent to their service desk tool and create a ticket for security operations center staff to triage.  

Partner with KirkpatrickPrice to Help Protect Your Environment 

Whether you work at a large organization with a team reviewing alerts or a one-person shop, you need a minimum level of logging and alerting tools and processes in place to protect your environment. The Center for Internet Security Control 08 – Audit Log Management can help guide you; however, if you need additional assistance, our experts are happy to help. We want to partner with your organization to help you become as secure as possible. Connect with a KirkpatrickPrice expert today to become unstoppable.  

About the Author

Greg Halpin

Greg Halpin has 25 years of experience in information technology and security. He has a Master’s in Information Sciences – Cybersecurity and Information Assurance from Penn State University, and he has earned the CISSP, CISA, and CCSP certifications. He has experience and additional
certifications in Amazon Web Services, Azure Cloud Services, Linux and Windows systems administration, vulnerability scanning, intrusion detection/prevention, and project management. He enjoys working with people and organizations to help them secure their networks and systems.