SIEM Use Cases for PCI DSS 3.0 – Part 2

January 15, 2015 by

Security Ninja

So as promised, I have come up with some more use cases for PCI DSS 3.0 requirements. I will try to cover as many requirements and use cases as possible in this document. So as we learned in Part 1 of this document series, we will learn more on how we can build up SIEM use cases for PCI DSS 3.0 requirements. I will not cover the basics of what PCI DSS is in this article. as it has already been covered in great detail earlier.

Use Case 5

PCI DSS requirement no 2.2.5: "Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers."

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 DSS guidance: "Unnecessary functions can provide additional opportunities for malicious individuals to gain access to a system. By removing unnecessary functionality, organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited. Including this in server-hardening standards and processes addresses the specific security implications associated with unnecessary functions (for example, by removing/disabling FTP or the web server if the server will not be performing those functions)."

Possible Threat: Possible threat in this use case will be the presence of vulnerable or unauthorized services running on servers.

Possible Log Sources: All servers.

Possible SIEM Use Case: Perform a search for insecure protocols, services, scripts, etc. Some services to look out for in the logs which are considered insecure include those like Telnet. In looking for insecure protocols, look out for usage of SSL version after the PODDLE attack.

Possible SIEM Rule: SIEM can be to look out for or perform a group-by clause for all the insecure ports and services. In Splunk, a reference list can be made which includes all the insecure ports, services etc. while a search runs. Splunk provides a look up fields list with parameters such as "dest_port", "is-required", "is_prohibited", "is_secure". These fields can be very useful in determining the insecure usage of ports, services and protocols.

Use Case 6

PCI DSS requirement no 5.1: "Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers)."

PCI DSS Guidance: "There is a constant stream of attacks using widely published exploits, often called "zero day" (an attack that exploits a previously unknown vulnerability), against otherwise secured systems. Without an anti-virus solution that is updated regularly, these new forms of malicious software can attack systems, disable a network, or lead to compromise of data."

PCI DSS requirement no 5.3: "Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period."

PCI DSS guidance: "Anti-virus that continually runs and is unable to be altered will provide persistent security against malware. Use of policy-based controls on all systems to ensure anti-malware protections cannot be altered or disabled will help prevent system weaknesses from being exploited by malicious software. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active—for example, disconnecting the unprotected system from the Internet while the anti-virus protection is disabled, and running a full scan after it is re-enabled."

Possible Threat: Malware spreading.

Possible Log Source: Antivirus logs.

Possible SIEM use case: Detect when anti-virus protection is disabled on the machines.

Possible SIEM rule: Search antivirus logs for "QID" related to "protection disabled". Please note that different AV vendors will have different strings to tell that AV protection is disabled.

Use Case 7

PCI DSS requirement no 5.2: "Ensure that all anti-virus mechanisms are maintained as follows:

• Are kept current
• Perform periodic scans
• Generate audit logs which are retained per PCI DSS Requirement 10.7."

PCI DSS Guidance: "Even the best anti-virus solutions are limited in effectiveness if they are not maintained and kept current with the latest security updates, signature files, or malware protections. Audit logs provide the ability to monitor virus and malware activity and anti-malware reactions. Thus, it is imperative that anti-malware solutions be configured to generate audit logs and that these logs be managed in accordance with Requirement 10."

Possible Threat: Spread of malware.

Possible Log Source: Antivirus logs.

Possible SIEM Use Case: To detect when agents are not receiving any updates from online repository.

Possible SIEM rule: Search antivirus logs for "QID" related to OLD DATABASE or OLD SIGNATURE. Please note that different AV vendors will have different strings to tell about this QID.

Use Case 8

PCI DSS requirement no 6.1: "Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as "high," "medium," or "low") to newly discovered security vulnerabilities."

PCI DSS Guidance: "The intent of this requirement is that organizations keep up to date with new vulnerabilities that may impact their environment. Sources for vulnerability information should be trustworthy and often include vendor websites, industry news groups, mailing list, or RSS feeds. Once an organization identifies a vulnerability that could affect their environment, the risk that the vulnerability poses must be evaluated and ranked. The organization must therefore have a method in place to evaluate vulnerabilities on an ongoing basis and assign risk rankings to those vulnerabilities. This is not achieved by an ASV scan or internal vulnerability scan, rather this requires a process to actively monitor industry sources for vulnerability information. Classifying the risks (for example, as "high," "medium," or "low") allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited."

Possible Threat: Exploitation of vulnerabilities.

Possible Log Source: Integrated Vulnerability Management Logs.

Possible SIEM Use Case: Identify all the vulnerable systems running in the organization.

Possible SIEM rule: Check out for Vulnerable Systems in VM logs.

Use Case 9

PCI DSS requirement no 6.3.1: "Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers."

PCI DSS Guidance:" Development, test and/or custom application accounts, user IDs, and passwords should be removed from production code before the application becomes active or is released to customers, since these items may give away information about the functioning of the application. Possession of such information could facilitate compromise of the application and related cardholder data."

PCI DSS requirement no 6.4.4: "Removal of test data and accounts before production systems become active."

PCI DSS Guidance: "Test data and accounts should be removed from production code before the application becomes active, since these items may give away information about the functioning of the application or system. Possession of such information could facilitate compromise of the system and related cardholder data."

Possible Threat: Unauthorized access to production data/systems.

Possible Log Source: All servers.

Possible SIEM Use Case: Identify all the systems using default accounts.

Possible SIEM rule: Create a baseline of default accounts and check for authentication events related to those accounts.

Use Case 10

PCI DSS requirement no 7: "Limit access to system components and cardholder data to only those individuals whose job requires such access."

PCI DSS Guidance: "The more people who have access to cardholder data, the more risk there is that a user's account will be used maliciously. Limiting access to those with a legitimate business reason for the access helps an organization prevent mishandling of cardholder data through inexperience or malice."

Possible Threat: Unauthorized access to production data/systems that could lead to disclosure of confidential data.

Possible Log Source: All servers storing confidential data and databases.

Possible SIEM Use Case: Detect unauthorized access to confidential data.

Possible SIEM rule: Create a baseline of default accounts and check for authentication events related to those accounts.

In the next article of this series, I will cover the next set of requirements and their possible SIEM use cases.

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