PCI Requirement 10.5.2 – Protect Audit Trail Files from Unauthorized Modifications
by Randy Bartels / May 1st, 2018
Unauthorized vs. Authorized Modifications
PCI Requirement 10.5.2 requires organizations to protect audit trail files from unauthorized modifications. What would an unauthorized modification look like? Audit trails contain all the correct information about events and incidents in critical systems, so malicious individuals will often seek to modify audit trails to hide their actions. What would an authorized modification look like? If an approved individual in an organization finds unencrypted cardholder data or Social Security numbers in a log, they may want to modify the log to encrypt this sensitive data.
During an assessment for PCI Requirement 10.5.2, an assessor may look for a situation where an individual would need to modify an audit trail file, examine the access controls, and review the modification approval process. An assessor really wants to verify that those who shouldn’t or don’t have access to audit trail files actually don’t have access to them.
However and wherever you’re storing your logs, you need to protect audit trail files from unauthorized modifications. There might be situations where you need to modify logs, such as if you found unencrypted cardholder data in the logs or you found Social Security numbers in the logs somewhere – there can be plethora of different scenarios by which you might find log data or need to modify these logs in some way. However, PCI Requirement 10.5.2 requires that you protect these logs from unauthorized modification. Your assessor is going to be looking for those situations where you might need to modify these logs and how that approval process would take place. The assessor might look for the access control, making sure that individuals who do not have access to these logs actually do not have access to them. We’re also going to make sure that these logs are appropriately backed up and that you’re pulling all of those logs that reside out in the DMZ into your internal environment to prevent those individuals that might access those environments, such as Hacker Joe, that might want to modify those logs to hide their tracks. You need to secure those logs once they’ve been created.
