SOC 2 Academy: Performing Daily Log Reviews
by Joseph Kirkpatrick / March 1st, 2019
Common Criteria 7.2
Common criteria 7.2 of the 2017 Trust Services Criteria says, “The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.” When an auditor verifies an organization’s compliance with this criterion during a SOC 2 audit, they’ll use the following points of focus to guide their assessment:
- Does the entity implement detection policies, procedures, and tools?
- Does the entity design detection measures?
- Does the entity implement filters to analyze anomalies?
- Does the entity monitor detection tools for effective operation?
Performing Daily Log Reviews to Comply with Common Criteria 7.2
Effectively monitoring an organization’s system is critical to ensuring that no malicious outsider or insider gains access to unauthorized areas or assets. To combat the threat of malicious hackers, we suggest that organizations should start by performing daily log reviews. By having personnel who are strictly responsible for performing daily log reviews, organizations will be better equipped to locate any anomalies that are occurring in their environment, analyze those anomalies, and take the proper measures to mitigate them.
For example, far too often, we have seen data breach headlines that easily could have been prevented if the organization had been performing daily log reviews. A prime example is Panera Bread. In August 2017, a security researcher reported a vulnerability to Panera Bread, but the claim was dismissed. Apparently, Panera Bread didn’t even take the claim seriously enough to look into because eight months later, the bakery-cafe announced a data breach of their website that exposed thousands of customer records. If Panera Bread had personnel dedicated to performing daily log reviews, they could’ve identified the vulnerability on their own and remediated the problem accordingly before any of the clients’ data was put at a greater risk. So, if you’re going to pursue SOC 2 compliance, make sure that your organization has processes in place for performing daily log reviews. Not only will it allow you to keep your security posture strong, but it will demonstrate to your clients that you’re dedicated to keeping their data secure.
More SOC 2 Resources
Understanding Your SOC 2 Report
It’s a best practice to perform daily log reviews, and just that one control right there is very difficult to accomplish first of all. It requires a full-time person many times. It requires someone who is dedicated to reviewing logs, because even in small environments, there are so many logs generated from so many systems – whether it’s applications, operating systems, desktop systems, servers, routers, firewalls, etc. – that it can be difficult to keep up with. There are many well-known stories about data breaches, where large organizations with network operations centers or security operations centers weren’t reviewing the logs, so they missed the sign of the attack. That’s the purpose of doing daily log reviews: to understand what anomalies are occurring in your environment and doing an analysis of those anomalies in order to understand if they’re real security events or something else that is innocent. This is what common criteria 7.2 of the SOC 2 Trust Services Criteria talks about. It’s really about correlating information from multiple sources, so that you can take action on any anomaly that would indicate that a security event is taking place. You have to think about how to correlate your information. Do you have a log correlation tool that will apply filters and other methods in order to really identify, out of all the noise, what the individual actions are that would indicate that an attack is occurring? I know I get alerts from systems sometimes of problems that are innocent in and of themselves, but if I have that alert plus another alert, I would know that it is a real event, and that something was occurring that we needed to respond to with our incident response plan. Think about common criteria 7.2 and how you would correlate all of the information that gets generated in your environment for the purpose of analyzing those anomalies to identify critical security events.
