After I got an outstanding response to my previous article on SIEM use cases, I have now prepared a series of articles for some SIEM use cases. In this article, I will show SIEM use cases for PCI DSS 3.0 compliance. I will cover specific use cases pertaining to each requirement of PCI DSS.

What is PCI DSS?

The Payment Card Industry Security Standards Council (PCI SSC) had developed a standard known as PCI Data Security Standard (PCI DSS) which is comprised of 12 core security areas to protect credit card holder data from theft, misuse etc. These requirements apply to all entities involved in payment card processing, including merchants, processors, and 3rd party service providers that store, process and transmit cardholder data. PCI DSS originally began as five different programs:

  • Visa’s Cardholder Information Security Program.
  • MasterCard’s Site Data Protection.
  • American Express’ Data Security Operating Policy.
  • Discover’s Information Security and Compliance.
  • JCB’s Data Security Program.

The motive of the above listed companies was to protect the card holder by providing some guidelines to merchants or any other entity which is involved in storing, processing and transmitting cardholder data. From the above listed companies, a PCI Security Standards Council (SSC) was formed, and the first version of PCI DSS 1.0 was released in December 2004. Because of rapid changes in technology, new modes of payments, attack vectors, regulatory laws etc., this version got back to back updates from 1.1 to 1.2. PCI subsequent versions 2.0 and 3.0 were released in October 2010 and November 2013 respectively.

SIEM Use Cases

The below section will illustrate various use cases pertaining to PCI DSS requirements.

Use Case 1

PCI DSS requirement No 1.1.1: “A formal process for approving and testing all network connections and changes to the firewall and router configurations.”

Guidance by PCI: “This requirement is intended to prevent malicious individuals from accessing the entity’s network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner (for example, to send data they’ve obtained from within your network out to an untrusted server.) Implementing a rule that denies all inbound and outbound traffic that is not specifically needed helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic in or out.”

PCI DSS Requirement No 1.2.1: “Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.”

Guidance by PCI:Firewalls and routers are key components of the architecture that controls entry to and exit from the network. These devices are software or hardware devices that block unwanted access and manage authorized access into and out of the network. Configuration standards and procedures will help to ensure that the organization’s first line of defense in the protection of its data remains strong.”

Possible Threat: “Unauthorized or Unapproved access”

Possible SIEM Use Case: The SIEM use case for this requirement will be to detect all the unauthorized network connections to/from an organization’s IT assets. For removing the false positives from this use case, correlate the results of unauthorized access with the change management process to remove any synch up issue with any change allowed.

SIEM Rule: Correlate all the connections with destination port and make a reference with critical assets in the organization. For example, “CORRELATE” command in Splunk.

Possible Log Sources: Since this requirement wants to check for network connections, then possible log sources can be perimeter devices like firewalls and interconnected devices like routers and segregation devices like switches.

Ethical Hacking Training – Resources (InfoSec)

Use Case 2

PCI DSS requirement no 1.1.6: “Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.”

Guidance by PCI: “The DMZ is that part of the network that manages connections between the Internet (or other untrusted networks), and services that an organization needs to have available to the public (like a web server). This functionality is intended to prevent malicious individuals from accessing the organization’s internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner.”

Possible Threat: “Insecure port, protocols and services.”

Possible SIEM Use Case: Perform a search for insecure protocols and services. Some insecure services to look out for in the logs are those such as Telnet. To look for insecure protocols, look out for usage of SSL versions 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”, and “is_secure”. These fields can be very useful in determining the insecure usage of ports, services and protocols.

Possible Log Sources: Possible log sources would be end user systems or servers like Windows and Linux servers.

Use Case 3

PCI DSS requirement no 1.3.1: “Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

PCI DSS Requirement No 1.3.2: “Limit inbound Internet traffic to IP addresses within the DMZ.”

Guidance by PCI: “The DMZ is that part of the network that manages connections between the Internet (or other untrusted networks), and services that an organization needs to have available to the public (like a web server). This functionality is intended to prevent malicious individuals from accessing the organization’s internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner.”

PCI DSS Requirement NO 1.3.5 “Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.”

Guidance by PCI DSS:All traffic outbound from the cardholder data environment should be evaluated to ensure that it follows established, authorized rules. Connections should be inspected to restrict traffic to only authorized communications (for example by restricting source/destination addresses/ports, and/or blocking of content).”

Possible Threat: Unauthorized or malicious traffic.

Possible Log Source: Since the requirement talks specifically about the DMZ zone, the security and network components like routers, switches and firewalls will be the log source for this requirement.

Possible SIEM use case: Possible SIEM use case will be to check how traffic is flowing across the DMZ to/from the internal but publicly accessible services, etc.

Possible SIEM rule: This SIEM use case can be implemented by configuring flows monitoring. Analyze the flows data and check out for inbound and outbound traffic not destined for legitimate servers.

Stay tuned for more use cases in the remaining requirements of PCI DSS 3.0.

References