Logs provide an important role in the security of your environment. They are a recording what happened and a method to recreate events that led to a security incident. That’s if you capture all of them, if you protect their integrity, and if you are looking for the right things. These common pitfalls affect the ability to monitor your environment and meet PCI requirements.
Capturing all the Logs (10.2.1)
Many times during the annual assessment QSA review to expose that the logging solution is not capturing logs from all in-scope systems. There can be many reasons for this. It may be that a log forwarder isn’t running, new systems were added to the environment but logging settings were not configured, or not all types of relevant logs were provided. Make sure you regularly review what systems are reporting logs and that they are sending the appropriate level of messages. Configuration guides for each type of system (servers, network devices, supporting systems providing security services, etc.) should specify the logging configurations that are required. Also remember to ensure other types of logs, such as antivirus/malware or application logs, are also centralized and secured.
Local Audit Log Files (10.3.1)
If you aren’t shipping the logs off immediately, have you reviewed the permissions on the files and directories where those logs are saved? Many times these permissions fly below the radar and are set by deefault to allow access to any administrator. This could be overly permissive depending on who has access to the system and allow for unauthorized modification or deletion of logs. Ensure least privilege concepts are followed for these sensitive files to protect them prior to delivery to the log repository.
Getting Rid of Manual Log Reviews (10.4.1, 10.4.1.1)
We are well past the days when a security admin could pour a cup of java and quickly review logs from the previous day. The volume of logs now make this a futile effort. Ensure that you use any rule-based alerts or advanced analytic capabilities in your logging or SIEM solution. Of course, the alerts are only as good as your ability to tune those rules. The system has to know what you consider events that need to be triaged for human review. And while many systems come with pre-written rules, they need to be reviewed to ensure that you know what will trigger them to avoid alert fatigue. Don’t forget that automated alerting will become a requirement after 31 March 2025!
Logs are the key to event reconstruction.
Remember the intent of logging - to have enough pieces to be able to put together the puzzle of a security incident. That means ensuring you have enough data points, can trust the data, and have effective review procedures. Good log data, aggregated properly, could be used to tie events together as an early warning system that something may be going wrong. Avoiding these issues with logging will help ensure you get the most out of your logs and are able to comply with the PCI DSS.