Windows logging for PCI-DSS

Various organizations strive to be PCI-DSS compliant, and they often have a hard time deciding what to log from Windows Systems so as to retain all the essential logs. However, there are issues with over-collection, like the increase of time in analysis (noise), increased storage capacity, and even sometimes increased SIEM cost. In this article, we will cover what essential logs should be collected from Windows Systems.

Refresher on PCI-DSS v3.1 requirements for logging along with Guidance

10.2.1 All individual user accesses to cardholder data

Guidance: "Malicious individuals could obtain knowledge of user account with access to systems in the CDE, or they could create a new, unauthorized account in order to access cardholder data. A record of all individual accesses to cardholder data can identify which accounts may have been compromised or misused."

10.2.2 All actions taken by any individual with root or administrative privileges.

Guidance: "Accounts with increased privileges, such as the "administrator" or "root" account, have the potential to greatly impact the security or operational functionality of a system. Without a log of the activities performed, an organization is unable to trace any issues resulting from an administrative mistake or misuse of privilege back to the specific action and individual".

10.2.3 Access to all audit trails

Guidance: "Malicious users often attempt to alter audit logs to hide their actions, and a record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account. Having access to logs identifying changes, additions, and deletions can help retrace steps made by unauthorized personnel."

10.2.4 Invalid logical access attempts

Guidance: "Malicious individuals will often perform multiple access attempts on targeted systems. Multiple invalid login attempts may be an indication of an unauthorized user's attempts to "brute force" or guess a password."

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

Guidance: "Without knowing who was logged on at the time of an incident, it is impossible to identify the accounts that may have been used. Additionally, malicious users may attempt to manipulate the authentication controls with the intent of bypassing them or impersonating a valid account."

10.2.6 Initialization, stopping, or pausing of the audit logs

Guidance: "Turning the audit logs off (or pausing them) prior to performing illicit activities is a common practice for malicious users wishing to avoid detection. Initialization of audit logs could indicate that the log function was disabled by a user to hide their actions."

10.2.7 Creation and deletion of system level objects

Guidance: "Malicious software, such as malware, often creates or replaces system level objects on the target system in order to control a particular function or operation on that system. By logging when system-level objects, such as database tables or stored procedures, are created or deleted, it will be easier to determine whether such modifications were authorized."

My only purpose to refresh these PCI-DSS requirements is to make sure that when we map these Windows audit actions, everyone should be able to understand it.

Now suppose I have a folder on my machine which holds credit card data named 'CHD.' Windows offers very granular level settings like shown below:

Now let's map the PCI –DSS requirements with these audit settings:

After setting the "Security Setting" for the in-scope PCI-DSS object, then configure each object container to be audited. IN this case I will open my CHD file >Properties>Security >Advanced>Auditing>Edit>Add

Enter 'Everyone' >OK

Now comes one of the scariest parts before doing which most of you will have your hands over your head. After clicking 'Ok', the following screen will appear. As a requirement, you will have to audit all successes and failures in this object container so select all. This is where the scope will come into play. If the scoping exercise has been done well, then you have no other option but to enable the access audit.

IF enough is too much for your organization to log as the PCI-DSS objects scope could be huge, below are windows settings which should be set at minimum:

• Req 10.2.1 is for All directories which store cardholder data: Enable for Everyone.
• Req 10.2..2 : Enable for Adminstrators(Domain, Local, Enterprise)
• Req 10.2.3,10.2.6: Location of Windows Event files(%SystemRoot%System32WinevtLogs) : Enable it for Everyone
• Req 10.2.7: All system directories (example: %SystemRoot%System32) – Enable for Everyone.

PCI-DSS Requirement 10.3 states what all information should be logged in an event log:

Below are PCI-DSS 10.3 requirements

• 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.

If you have all the above getting recorded for all in scope PCI-DSS objects, then you are fine.

Some events of interest to monitor in SIEM

Now I will tell you some events of interest from events logs that should be monitored in SIEM for PCI-DSS in-scope objects. Please note that this is an exhaustive list of Event IDs that should be used for Monitoring purpose/

Sources

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf