The Payment Card Industry Security Standards Council (PCI SSC) maintains, evolves, and promotes Payment Card Industry standards for the safety of cardholder data across the globe. The PCI SSC provides technical and operational requirements for organizations accepting or processing payment transactions. The guidance also applies to software developers and manufacturers of applications and devices used in those transactions.
The Payment Card Industry Data Security Standard (PCI DSS) helps entities understand and implement standards for security policies, technologies, and ongoing processes that protect payment systems from breaches and theft of cardholder data. The standards have historically been revised on a 2-3 year cycle, but the PCI SSC is transitioning to a posture of revising the PCI DSS as required based on changes to the current threat landscape. The current standard revision is PCI DSS Version 3.2, released in April 2016. Any organization that handles payment card information must adhere to the PCI DSS and must demonstrate compliance annually. Tenable's Tenable.sc Continuous View (CV) is able to help organizations monitor ongoing PCI DSS compliance by integrating with Tenable Nessus, Tenable Nessus Network Monitor (NNM), and Tenable Log Correlation Engine (LCE).
The PCI Requirement 4 ARC analyzes policy statements related to the fourth PCI DSS requirement. This requirement mandates organizations to encrypt CHD (cardholder data) across open and public networks. CHD is sensitive information that needs to be protected and should be encrypted internally at all times when possible, and must be encrypted if it is being transmitted outside of the CDE.
When CHD needs to leave the organization, such as to send the data to a partner organization, the CHD must be encrypted. Security mechanisms used to encrypt the data may not be up to the appropriate standards for secure communication for data in motion nor storing the data securely at rest. Inadequate security mechanisms can lead to a false sense of security and could be easily compromised. Security teams can use this ARC to identify systems and network devices that expose CHD or are not adequate to protect CHD to adhere with requirement 4 of PCI DSS.
Organizations can configure repositories or asset lists in order to tailor the focus of the ARC. When the ARC is added from the Tenable.sc Feed, the appropriate assets, IP addresses, or repositories can be specified. Assigning one of the options to the ARC will update all filters in the components. By creating static or combination asset lists that include all systems in the Cardholder Data Environment (CDE), each component can be filtered to display results directly related to ongoing PCI security. Using an asset list filter will also allow traffic into and out of the CDE to be monitored. In order to accurately measure an organization’s PCI security posture, asset lists need to be applied as filters to provide results focused on the CDE.
This ARC is available in the Tenable.sc Feed, a comprehensive collection of dashboards, reports, Assurance Report Cards, and assets. The ARC can be easily located in the Tenable.sc Feed under the category Compliance. The ARC requirements are:
- Tenable.sc 5.3.1
- Nessus 8.5.1
- NNM 5.9.0
- LCE 6.0.0
Tenable's Tenable.sc Continuous View (CV) provides continuous network monitoring, identification of sensitive data such as cardholder data, and PCI security monitoring. Tenable.sc CV is continuously updated with information about advanced threats and zero-day vulnerabilities, and new types of regulatory compliance configuration audit files such as PCI DSS compliance standards. Tenable constantly analyzes information from our unique sensors, delivering continuous visibility and critical context, enabling decisive action that transforms your security program from reactive to proactive. Active scanning examines the systems on the network, running processes and services, configuration settings, and vulnerabilities. This process helps analysts to identify systems and processes that may be leaking sensitive data such as cardholder data. Continually and passively scanning the network traffic to analyze the servers, desktops and applications helps prioritize security efforts to mitigate threats, data leakage, and weaknesses. With increasing mobile and transient network devices, it is important to have a system in place that continuously monitors for data leakage across environments. Tenable enables powerful, yet non-disruptive, continuous monitoring of your network.
This ARC includes the following policy statements:
No data protection compliance checks failed (4): This policy statement displays the number of failed to total data protection compliance checks. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Data protection settings may include encryption and access control requirements, among other things. Compliance is measured against those policy checks that reference one or more of the following standards:
- PCI DSS requirement 3 (Protect stored cardholder data)
- PCI DSS requirement 4 (Encrypt transmission of cardholder data across open, public networks)
- PCI DSS requirement 7 (Restrict access to cardholder data by business need to know)
- Cybersecurity Framework PR.DS-1 (Data-at-rest is protected)
- Cybersecurity Framework PR.DS-2 (Data-in-transit is protected)
- NIST 800-53 control SC-8 (TRANSMISSION CONFIDENTIALITY AND INTEGRITY)
- Center for Internet Security Critical Security Control 14 (Controlled Access Based on the Need to Know)
- Center for Internet Security Critical Security Control 13 (Data Protection)
- DoD Instruction 8500.2 control ECCD (Changes to Data)
- DoD Instruction 8500.2 control ECCR (Encryption for Confidentiality (Data at Rest))
- DoD Instruction 8500.2 control ECCT (Encryption for Confidentiality (Data in Transit))
- DoD Instruction 8500.2 control ECNK (Encryption for Need-To-Know)
No external facing systems use insecure communication protocols (4.1): This policy statement displays the ratio of external-facing systems using insecure communication protocols to all external-facing systems. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. External-facing systems are especially susceptible to malicious activity, and the use of insecure communication protocols dramatically increases the risk of exploitation. The number of systems using insecure communication protocols should be limited and carefully monitored to ensure data security.
No servers running SSL or TLS support weak ciphers (4.1): This policy statement displays the ratio of servers running SSL or TLS that support weak ciphers to the total number of systems running SSL or TLS. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. The use of weak ciphers heightens the risk of data exposure, especially on systems used for transmitting data. Systems running SSL or TLS should be configured to use strong ciphers if possible to reduce the risk of data leakage.
No wireless compliance checks failed (4.1.1): This policy statement displays the number of failed to total wireless compliance checks. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Wireless settings may include requirements to deactivate wireless interfaces and set specific configurations, among other things. To improve wireless security and protect against unauthorized access, wireless compliance issues must be addressed.
No cardholder data has been transferred unencrypted (4.2): This policy statement displays the number of failed to total unencrypted CHD (cardholder data) compliance checks. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Critical data such as CHD is important to protect in motion and at rest. Organizations need to ensure this data is encrypted to prevent unintentional data leakage or intentional data theft.