SIEM Use Cases for PCI DSS 3.0 – Part 3

Welcome to the Part 3 of the series "SIEM Use Cases for PCI DSS 3.0". We have covered some very good use cases in Part 1 and Part 2. Let's look at some more interesting use cases as we move on with analyzing the next set of PCI DSS 3.0 requirements.

Use Case 11

PCI Requirement 8.1.2: "Control addition, deletion, and modification of user IDs, credentials, and other identifier objects."

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

PCI guidance: "To ensure that user accounts granted access to systems are all valid and recognized users, strong processes must manage all changes to user IDs and other authentication credentials, including adding new ones and modifying or deleting existing ones."

PCI Requirement 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."

PCI 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."

PCI Requirement 12.5.4: "Administer user accounts, including additions, deletions, and modifications."

PCI Guidance: "Each person or team with responsibilities for information security management should be clearly aware of their responsibilities and related tasks, through specific policy. Without this accountability, gaps in processes may open access into critical resources or cardholder data."

Possible Threat: Unauthorized or unapproved access.

SIEM Log Source: The main log source for these SIEM requirements will be a data store like Active Directory and Network Devices.

Possible SIEM Use Case: Monitor for any event that results in addition, deletion, and modification of user IDs, credentials, and other identifier objects.

Possible SIEM Rule: Include eventIDs that are related to addition, deletion and modification of users in the rule. For example consider the following AD event IDs(in 2008, 2008R2, 2012) to monitor. Please note that these eventIDs may get changed with changes in AD version. Also the respective Account Management Audit settings must be enabled for these events to get logged.

• EventID: 4720 - User Creation
• EventID: 4726 - User Deletion
• EventID: 5136 - User Details modification

Use Case 12

PCI DSS Requirement 8.1.3: "Immediately revoke access for any terminated users."

PCI DSS Guidance: "If an employee has left the company and still has access to the network via their user account, unnecessary or malicious access to cardholder data could occur—either by the former employee or by a malicious user who exploits the old and/or unused account. To prevent unauthorized access, user credentials and other authentication methods therefore need to be revoked promptly (as soon as possible) upon the employee's departure."

Possible Threat: Unauthorized access, e.g. terminated account activity detection.

SIEM Log Source: Data stores like Active Directory, Applications, and Databases.

SIEM Use Case: Detect any authentication event made by or for terminated users.

SIEM Rule: Create a list of terminated employees and perform a lookup for authentication events.

Use Case 13

PCI DSS Requirement 8.1.4: "Remove/disable inactive user accounts at least every 90 days."

PCI DSS Guidance: "Accounts that are not used regularly are often targets of attack since it is less likely that any changes (such as a changed password) will be noticed. As such, these accounts may be more easily exploited and used to access cardholder data."

Possible Threat: Detect any activity from a dormant account.

SIEM Log Source: Data stores like Active Directory.

SIEM Use Case: Look out for events from accounts which have been dormant for the last 90 days at least.

SIEM Rule: This SIEM use case can be conducted by various methods. For example, in Splunk we can maintain a list for all the dormant accounts and then perform a lookup against that list for all the authentication events. Another way is to use the attributes form AD like "Last Login" and calculate the difference with the detected authentication event time.

Use Case 14

PCI DSS Requirement 8.1.5: "Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:

• Enabled only during the time period needed and disabled when not in use.
• Monitored when in use."

PCI DSS Guidance: "Allowing vendors to have 24/7 access into your network in case they need to support your systems increases the chances of unauthorized access, either from a user in the vendor's environment or from a malicious individual who finds and uses this always-available external entry point into your network. Enabling access only for the time periods needed, and disabling it as soon as it is no longer needed, helps prevent misuse of these connections. Monitoring of vendor access provides assurance that vendors are accessing only the systems necessary and only during approved time frames."

Possible Threat: Possible threat around this requirement is of a malicious users login event from a trusted door.

SIEM Log Source: Perimeter/gateway security devices like VPN logs.

SIEM Use Case: All 3^rd party vendor account must be monitored for their usage.

SIEM Rule: This SIEM rule can be configured by creating a list of all the vendor accounts and looking for the authentication and access events made by those users.

Use Case 15

PCI DSS Requirement 8.1.6: "Limit repeated access attempts by locking out the user ID after not more than six attempts."

PCI DSS Guidance: "Without account-lockout mechanisms in place, an attacker can continually attempt to guess a password through manual or automated tools (for example, password cracking), until they achieve success and gain access to a user's account."

PCI DSS Requirement 10.2.4: "Invalid logical access attempts."

PCI DSS 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."

Possible Threat: A brute force attack pattern detected.

SIEM Log Source: Servers, AD, databases, etc.

SIEM Use Case: Detect invalid number of login attempts against a limit value within a specified time frame.

SIEM Rule: The above listed SIEM use case can be done by looking at event ID like 4625 in Windows and /var/log/secure file string such as "authentication failed". A possible query for this use case in Splunk is "sourcetype="WinEventLog:Security" (EventCode=4625 AND "Audit Failure") NOT (User_Name="*$" OR Account_Name="*$") NOT Failure_Code=0x19 | stats count by Account_Name | where count > 2"

So as we have seen, this article majorly focuses on use cases related to unauthorized access. We will see the next set of use cases in the next and probably final part of this article series. Stay tuned!!

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

References

• https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf