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 Appendix A2 ARC analyzes policy statements related to Appendix A2 of PCI DSS requirements. This section mandates that organizations using SSL and early versions of TLS must work toward upgrading to a strong cryptographic protocol. The requirement seeks to establish minimum requirements for the protocols used to encrypt traffic. Secure encryption protocols can protect an organization against compromise or data theft. The requirement mandates that all service providers must provide a secure service offering by June 30, 2016. Merchants have until June 30, 2018 to comply with the requirement. Any existing implementations that are unable to comply by the deadlines must have a formal risk mitigation and migration plan in place. Monitoring network traffic for the use of insecure protocols is the first step to ensuring that all cryptographic methods are updated. Security teams can use this ARC to identify and monitor encryption protocols in order to meet the requirements laid out in Appendix A2 of PCI DSS.
Organizations can configure repositories or asset lists in order to tailor the focus of the ARC. When the dashboard is added from the Tenable.sc Feed, the appropriate assets, IP addresses, or repositories can be specified. Assigning one of the options to the dashboard 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
Tenable's Tenable.sc provides extensive network monitoring by leveraging a unique combination of detection, reporting, and pattern recognition utilizing industry recognized algorithms and models. Tenable.sc is continuously updated with plugins to detect and audit system configurations and regulatory compliance. Tenable constantly analyzes information from our unique sensors, delivering continuous visibility and critical context and enabling decisive action that transforms the security program from reactive to proactive. Event normalization and correlation allows deeper visibility into the network. Continuous data analysis enables security teams to more effectively detect insecure network traffic. Monitoring the network to ensure that all systems are using secure encryption protocols is essential to ongoing security efforts. Tenable’s extensive network monitoring capabilities can verify that systems are securely encrypting traffic in accordance with security policies, enabling ongoing improvements to an organization’s security posture.
This ARC includes the following policy statements:
No systems are capable of supporting weak SSL or TLS ciphers: 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 systems use insecure communication protocols: This policy statement displays the ratio of 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 systems have cryptographic vulnerabilities: This policy statement displays the ratio of systems with cryptographic vulnerabilities to total systems. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Cryptographic vulnerabilities can cause systems to be at risk of exposing information due to improper encryption. Systems could transmit unencrypted data via typically secure protocols without the user’s knowledge. Systems with cryptographic vulnerabilities should be prevented from transmitting data until the vulnerabilities can be remediated.