What should I be logging in Windows to pass PCI DSS assessment v3.0? – this and similar questions come up rather often when it comes to fulfilling Section 10 of PCI DSS v3.0.
In Part 1, we are looking at Microsoft Windows and in Part 2 we will investigate CentOS. Note. This article is describing local logs configuration settings. If you are interested in the centralized logging and PCI DSS, please read the following article: Free Log Management and PCI DSS 3.0.
Microsoft Windows comes with very detail and comprehensive logging mechanism. Get it right and you will end up with very useful information, not only helping you to secure the environment but also to achieve high availability and spot things before the real disaster happens. In opposite, enable every possible auditing option and you will end up with thousands records per second, which may hinder the real attack.
The key is to optimize the settings and tweak the system, so it’s compliant with PCI DSS but also provides useful information to the staff involved in monitoring of such logs.
Lets have a look at what events must be logged to satisfy PCI DSS v3.0:
10.2 Implement automated audit trails for all system components to reconstruct the following events:
10.2.1 All individual user accesses to cardholder data
10.2.2 All actions taken by any individual with root or administrative privileges
10.2.3 Access to all audit trails
10.2.4 Invalid logical access attempts
10.2 5 Use of and changes to identification and authentication mechanisms?including but not limited to creation of new accounts and elevation of privileges?and all changes, additions, or deletions to accounts with root or administrative privileges
10.2.6 Initialization, stopping, or pausing of the audit logs
10.2.7 Creation and deletion of system-level objects
The screenshot below presents what Audit Policy Settings must be configured in the Group Policy Object to achieve the above PCI DSS requirements. In the example below it is configured on the Local GPO, but the same settings apply to the Domain Level GPOs.
Note. Windows offers much more granular auditing configuration settings, which can be found in Computer Configuration -> Windows Settings – > Security Settings -> Advanced Audit Policy Configuration. The advanced settings are beyond the scope of PCI DSS v3.0. As always, PCI DSS is a bare minimum, if you wish to log more, please investigate the advanced logging further.
The second part is to enable the above settings on the right directories. The screenshot below presents how to enable the Audit Policy (Object Access) on chosen directories:
The level of logging for each directory /file (screenshots below) will vary, depending on what directory/user the settings are applied to. For example:
For 10.2.2 all actions on all directories / files must be logged for Administrators. In such case all boxes would be ticked:
For 10.2.7 only creation and deletion of system-level objects would be ticked:
At minimum the following Windows directories should have the ‘Auditing’ settings enabled:
– [PCI DSS 10.2.1] Any directories/files, which store cardholder data – for Everyone
– [PCI DSS 10.2.2] All directories/files – for Domain Administrators, Enterprise Administrators, Local Administrators
– [PCI DSS 10.2.3 and 10.2.6] All directories/files, which store Windows event files (Default – %SystemRoot%\System32\Winevt\Logs\) – for Everyone
– [PCI DSS 10.2.7] All system directories (example: %SystemRoot%\System32\) – for Everyone. Note. System-level object: Anything on a system component that is required for its operation, including but not limited to database tables, stored procedures, application executables and configuration files, system configuration files, static and shared libraries and DLLs, system executables, device drivers and device configuration files,and third-party components.
Lastly, PCI DSS lists what entry should be logged for each event:
10.3.1 User identification
10.3.2 Type of event
10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system component, or resource.
The screenshot below presents an example of event with highlighted fields after the Audit Policy Settings have been enabled. As you can see, there is no need to configure any additional settings in order to fulfill PCI DSS Req. 10.3.x.
Part 2: Audit Trails in PCI DSS v3.0 – Logging in Linux -> Coming soon.