Exactly which settings need to be enabled for the audit (logging) policy on Windows systems in order to meet the intent of PCI DSS requirements 10.2.x? Trying to understand all the individual events IDs associated with each Windows audit policy is your first step in trying to determine the answer to this question! But after a bit of digging (thank goodness for Google) I found the answer. Both articles provide great information on the details of each event ID and how you can align this with PCI requirements for auditing:
Windows 2003 – https://technet.microsoft.com/en-us/library/cc163121.aspx#EKH
Windows 2008 – https://support.microsoft.com/default.aspx?scid=kb;EN-US;947226
If reading these articles doesn’t quite excite you…Well, here is the quick answer to what audit policies to enable:
- Account Logon – Success and Failure
- Account Management – Success and Failure
- Logon Events – Success and Failure
- Object Access – No Auditing
- Policy Change – Success and Failure
- Privilege Use – No Auditing
- Process Tracking – No Auditing
- System Events – Success and Failure
Account Management provides a wealth of information – including password changes, creation of a new user account and changes to group membership (i.e. Additions to the Domain Admin group).
Object Access auditing is just that – logging when a user accesses an object such as a file, directory or registry key. However, enabling this policy alone will not generate events. A SACL (System Access Control List) has to be specified on the object in addition to enabling this audit policy to generate alerts. In my opinion, a File Integrity Monitoring (FIM) solution is better suited to log and track “object access”.
Don’t be deceived by “Privilege Use” auditing, as it provides minimal value add and enabling this policy quickly fills up the audit logs.
Process Tracking is typically used for debugging purposes and logging of this type of activity is not required for day to day business purposes.
But don’t forget requirement 10.5.3 – sending audit logs to a centralized log server.
Shelina Samji, PCI QSA
Senior Consultant, PCI Compliance Services
HALOCK is headquartered in Schaumburg, IL, in the Chicago area and advises clients on information security and conducts PCI preparedness assessment, scoping, remediation, validation, and compliance maintenance services throughout the US.
PCI DSS Requirements
PCI DSS Requirement 5.4.1: Anti-spoofing controls such as DMARC, which stands for Domain-based Message Authentication, Reporting and Conformance, Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM) can help stop phishers from spoofing the entity’s domain and impersonating personnel.
Clarification on eCommerce Outsourcing PCI DSS requirements 6.4.3 and 11.6.1
Unpacking the New PCI DSS Password Standards
Is Your Organization Prepared for PCI DSS Automation – Requirement 10.4.1.1?
What is the PCI DSS v4 Authenticated Scanning Mandate – Requirement 11.3.1.2?
What is the PCI DSS v4.0.1 Requirement for PoLP – Requirement 7.2.5?
The New PCI DSS v4.0.1 Software Catalog Mandate – Requirement 6.3.2
How to Analyze An Attestation of Compliance (AOC)
PCI Compliance New Requirements and Targeted Risk Analysis (TRA)
RESOURCES & NEWS
Learn more about Penetration Testing and new exploits in HALOCK’s Exploit Insider.
The Dangers of Legacy Protocols
PCI Targeted Risk Analysis & DoCRA
https://www.halock.com/pci-compliance-new-requirements-and-targeted-risk-analysis/
HIPAA & Penetration Testing & Incident Response Plans
Top Threats in Healthcare
https://www.halock.com/top-cyber-threats-in-healthcare/
Cloud Security Risk Management
https://www.halock.com/prioritized-findings-and-remediation-in-cloud-security-reporting/
Penetration Testing Reports to Manage and Prioritize Risk
https://www.halock.com/a-threat-based-approach-to-penetration-test-reporting/