Due to potentially steep fines and loss of customer good will, retail and financial services companies are guardedly concerned about PCI (Payment Card Industry) compliance. The PCI Data Security Standard (PCI DSS) is a set of prescriptive data security specifications laid out to ensure the safe handling of cardholder information at every stage. The PCI DSS provides an actionable framework for developing a robust payment card data security process — including prevention, detection, and appropriate reaction to security breach incidents. In a previous blog we briefly explain how NetFlow helps you maintain PCI compliance. This blog will educate you on how Scrutinizer accomplishes PCI DSS Compliance specific to individual requirements.
The Scrutinizer Incident Response System leverages flow data from existing routers and switches to provide continuous monitoring in every corner of the network. The system fills in the gaps between application logging and traditional, signature-based, IDS/IPS appliances. Scrutinizer also helps organizations achieve and demonstrate comprehensive, network-wide compliance for sections 1, 2, 10, and 11 of the PCI standard [source].
Scrutinizer helps you maintain PCI DSS Compliance by:
- Supplying real-time visibility and awareness of network- and host-based behaviors down to individual users
- Increasing user accountability for introducing network threats
- Tracking, measuring, and prioritizing network risks, via threats index, for faster remediation
- Providing the in-depth data needed to conduct forensic analysis for security incidents
- Extending network monitoring to virtual environments
Specific PCI Compliance Support
1.1.2
Requirement: Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks.
Compliant: The Scrutinizer system can be configured to monitor for traffic patterns that should not exist on the network (e.g. Internet communications or communications outside of specific ports).
1.1.6
Requirement: 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. Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2.
Compliant: All internal communication ports can be documented. Communications on ports outside of those defined can trigger events that lead to alarms. Alarms can trigger actions such as blocking ports and services.
1.2
Requirement: Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.
Compliant: All major firewall vendors export messages regarding the flows they are allowing or denying. Odd behaviors found in those messages can trigger events which execute scripts that take action. Since all data is archived, it can be used for future segmentation planning and monitoring efforts. All traffic can be monitored for specified unwanted behaviors and violations can trigger alarms.
2.2.1
Requirement: Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)
Compliant: Once the normal traffic behavior from a virtual machine has been observed, documented or even baselined, communication outside of its normal profile can trigger alarms.
2.2.2
Requirement: Enable only necessary services, protocols, daemons, etc., as required for the function of the system.
Compliant: Loaded with a list of allowed protocols and ports, communications outside of what is pre-approved will trigger alarms.
10.1
Requirement: Implement audit trails to link all access to system components to each individual user.
Compliant: 100% of all communications are archived and saved for future reference. Scrutinizer can be integrated with authentication systems such as Microsoft Active Directory, Cisco ISE or any type of radius authentication to provide user name details related to IP addresses.
10.1 – 10.3
Requirement: Implement automated audit trails for all system components to reconstruct the following events:
- All individual user accesses to cardholder data
- All actions taken by any individual with root or administrative privileges
- Access to all audit trails.
- Invalid logical access attempts
- Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts andelevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges
- Initialization, stopping, or pausing of the audit logs
- Creation and deletion of system level objects.
Record at least the following audit trail entries for all system components for each event:
- User identification
- Type of Event
- Date and Time
- Success or failure indication
- Origination of event
- Identity or name of affected data system component, or resource.
Compliant: Since Scrutinizer can be integrated with authentication services, it can provide details on when a host likely logged into and out of the network. All traffic can be tied to specific end systems which help expedite and streamline the incident response process.
10.5.3, 4
Requirement: Promptly back up audit trail files to a centralized log server or media that is difficult to alter.
Write logs for external-facing technologies onto a secure, centralized, internal log server or media device.
Compliant: Since 100% of all communications pass through routers or switches that send the flow data to Scrutinizer, virtually every connection to and from the payment card application is archived. Data can be saved for decades with the largest limitation being storage space. Retrieval of the data takes only seconds.
11.2
Requirement: Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
Compliant: Applications, IP addresses and other elements can all be baselined. Future communications are compared to baselines and abnormalities are increase Threat Indexes which ultimately lead to alarms.
11.4
Requirement: Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.
Compliant: Scrutinizer Flow Analytics constantly compares end system behaviors to unacceptable profiles. Any system found to be scanning the network, communicating to known C&C servers or possibly exfiltrating confidential data are identified and posted to the alarms.
If you have any questions about how we can help you accomplish PCI DSS compliance in your network, give us a call or send us an email; we’re always here to help.