SIEM Use Cases for PCI DSS 3.0 – Part 4
So we have finally reached the final part of this series of articles. First of all I would like to thank you readers for such an outstanding response to Part 1, Part 2, and Part 3 of this series, which cover the use cases for the PCI DSS 3.0 to an extent, and this article will focus on the remaining requirements and possible use cases around them.
Use Case 16
PCI DSS Requirement 10.2.1: “All individual user accesses to cardholder data.”
PCI DSS Guidance: “Malicious individuals could obtain knowledge of a 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.”
Possible SIEM Threat: “Disclosure of information.”
Log Sources: Server storing confidential data.
SIEM Use Case: Access to sensitive data should be recorded.
SIEM Rule: Enable auditing on the sensitive file and look for access related events.
Use Case 17
PCI DSS Requirement 10.2.2: “All actions taken by any individual with root or administrative privileges.”
PCI DSS 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.”
Possible SIEM Threat: “Misuse of privileges.”
Log Sources: Active Directory, Applications, Databases.
SIEM Use Case: Detect all the actions taken by any individual with root or administrative privileges.
SIEM Rule: Define the privileged users in the privileged users building block and look for the actions taken by those users.
Use Case 18
PCI DSS Requirement 10.2.7: “Creation and deletion of system level objects.”
PCI DSS 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.”
Possible SIEM Threat: “Unauthorized modifications.”
Log Sources: Databases
SIEM Use Case: Alert when system-level objects, such as database, tables or stored procedures, are created or deleted.
SIEM Rule: Enable auditing and search for the events related to creation and deletion of system-level objects and then include those events in the rule.
Use Case 19
PCI DSS Requirement 10.2.6: “Initialization, stopping, or pausing of the audit logs.”
PCI DSS 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.”
Possible SIEM Threat: “Unable to track.”
Log Sources: Systems, Databases, Applications
SIEM Use Case: Alert when audit services are stopped on a compliance host.
SIEM Rule: Define the hosts in the compliance definition BBs and verify that the events for the audit service stopped for your host are in the Auditing Stopped building block.
Use Case 20
PCI DSS Requirement 10.2.3: “Access to all audit trails.”
PCI DSS 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.”
Possible SIEM Threat: “Modification”
Log Sources: Application Servers
SIEM Use Case: Alert when someone is trying to access the audit/log file of any application/system.
SIEM Rule: Enable auditing on the audit file and check for the access related events.
Use Case 21
PCI DSS Requirement 8.5: “Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
- Generic user IDs are disabled or removed.
- Shared user IDs do not exist for system administration and other critical functions.
- Shared and generic user IDs are not used to administer any system components.”
PCI DSS Guidance: “If multiple users share the same authentication credentials (for example, user account and password), it becomes impossible to trace system access and activities to an individual. This in turn prevents an entity from assigning accountability for, or having effective logging of, an individual’s actions, since a given action could have been performed by anyone in the group that has knowledge of the authentication credentials.”
Possible SIEM Threat: “Unaccountability”
Log Sources: Active Directory
SIEM Use Case: Alert when a privileged account is shared between two or more employees.
SIEM Rule: Look for authentication events made for the same username by different IP addresses.