Monitoring Internal Scans for PCI 11.3.1

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.

PCI DSS helps entities understand and implement standards for security policies, technologies and ongoing processes that protect their 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 4.x. Any organization that handles payment card information must comply with the PCI DSS and must demonstrate compliance annually. Tenable Security Center is able to help organizations monitor ongoing PCI DSS compliance.

As part of the PCI DSS version 4.x the requirement for authenticated internal vulnerability scanning was introduced. Tenable has always emphasized that credentialed scanning is required to get the most accurate information, now the PCI Council requires credentialed scanning where possible. The Council recognizes that all systems may not be accessible as part of a credentialed vulnerability scan, but those systems must be clearly documented. As part of the vulnerability scanning, Tenable uses two methods to perform elevated vulnerability scans, Nessus and Nessus Agents. Nessus vulnerability scans access the system over a network protocol such as SMB, SSH, and etc, while the Nessus Agents run a local version of the Nessus scan engine as a system level service. (Note: When using Nessus Agent, uncredentialed port scans are still required to identify open ports) There are benefits to each method, however each provides the ability to enumerate vulnerabilities based on the operating system, system configurations, and installed software.  

As part of the requirement 11.3.1.2 (Internal vulnerability scans are performed via authenticated scanning), the internal systems located within the Cardholder Data Environment (CDE) are to be documented as accessible with and without credentials. Using Nessus to scan devices on the network will provide the necessary information as to the accessibility of a system using the defined protocols and supplied credentials. Nessus will report on the success of authentication and the status of collecting vulnerabilities. Once authenticated, Nessus will enumerate vulnerabilities found on the system. The vulnerabilities detected are identified using industry-recognized vulnerability databases and our research teams.

As directed in the 11.3.1 (Internal vulnerability scans are performed), the organization must conduct internal scans every three months and perform rescans to confirm all high and critical vulnerabilities are resolved. Tenable Security Center supports the scheduling of scans, allowing the assessment teams to continuously monitor the CDE accordingly. The dashboard consists of widgets that provide an overview of how internal scanning is being performed. These information based queries provide authentication, scan health, and diagnostic information to assist risk managers with ability to drill down into the appropriate data and better understand the problems that need to be addressed to mitigate risks or solve scan heath related issues.  While the vulnerability based queries are filtered for high and critical severity vulnerabilities, along with other attributes such mitigation status, risk categories, and risk accepted; allowing assessors to focus on vulnerabilities of particular concerns identified during the scans. Identified vulnerabilities are tracked by time, severity, and host in order to provide multiple perspectives into the vulnerability status of the organization.

Tenable provides several solutions for organizations to better understand vulnerability management. Security leaders need to SEE everything, PREDICT what matters most and ACT to address cyber risk and effectively align cybersecurity initiatives with business objectives. Tenable Vulnerability Management (formerly Tenable.io) discovers and analyzes assets continuously to provide an accurate and unified view of an organization's security posture. The requirements for this report are: Tenable Vulnerability Management.
 

Widgets

• PCI-DSS - Scan Health: This component provides details about authentication status and the scan process. The details include the most recent scan and the health of the scan. System and network devices must be routinely scanned to ensure they are operating in compliance with organizational and regulatory requirements for vulnerability and configuration management.
• PCI-DSS - Scan Health Trending (50 Day trend): This chart provides a trend analysis about authentication status and the scan process. The evidence of scanning activities is often required by regulatory frameworks and Service Level Agreements (SLAs). The lines within the chart provide a historic view of how effective the scanning process has been over the past 50 days.
• Understanding Risk - Details by Severity: This matrix presents details by severity on vulnerabilities found to exist in the environment. At each severity level, the number of vulnerabilities is displayed, along with three percentage columns and the number of hosts affected. The percentage columns show the percentages of the vulnerabilities that are exploitable, that were published more than 90 days ago, and that have had a patch available for more than 30 days. Ideally, all of these percentages should be 0%, because all exploitable vulnerabilities, old vulnerabilities, and vulnerabilities with patches available should have been mitigated already. If more details are desired (for example, what are the specific critical vulnerabilities that are exploitable?), click on the appropriate matrix cell to display more information.
• InfoSec Team - Track Accepted and Recast Risk: This matrix tracks currently Accepted Risk and Recast Risk items. The Accepted Risk row displays vulnerabilities based on the associated Accepted Risk Workflow. The Recast Risk row displays vulnerabilities based on the associated Recast Risk Workflow. The accepting or recasting of risk has does not have any effect on VPR or CVSS scores. Both rows display the vulnerabilities by total, severity, exploitability, number of hosts, patch, or vulnerability being published. Workflow actions allow organizations to accept or recast risk and configure alerting. These functions allow organizations to be set rules on how notifications should occur so incoming vulnerabilities can be handled properly.
• Mitigated Patch Rates - Remediation Rates: The matrix component displays vulnerabilities across categories of interest to analysts. The rows relate to time and assist analysts with context of vulnerability remediation efforts. Many organizations remediate vulnerabilities approximately every 30 days in line with vendor patch releases. The rows approximate the last two "patch cycles" to display efforts of vulnerability remediation within the organization.
• Qualitative Risk Analysis - Vulnerabilities by Subnet: The Vulnerabilities by Subnet table provides a cumulative number of medium, high, and critical vulnerabilities for the top most vulnerable subnets. For each subnet, the total number of vulnerabilities is displayed, along with a bar chart of the vulnerabilities by severity (red = critical, orange = high, and yellow = medium). By grouping all detected vulnerabilities by IP address into representative Class C subnets, this table can assist an organization both in identifying the weakest areas of the network and in understanding the scope of the network. This information can help an organization detect unauthorized subnets or rogue devices.
• Executive Vulnerability Metrics - Vulnerability Trend: This component presents a trend chart of both current and previously mitigated vulnerabilities over the last seven days. Information presented within this component can provide organizations with a comprehensive view into how often systems are being scanned, patched, and rescanned. Current vulnerabilities are identified and set to the “Never Mitigated” filter. When a vulnerability moves from the mitigated section to the active section, the mitigation status is set to "Previously Mitigated." Previously Mitigated or recurring vulnerabilities can be the result of systems not being restarted after a patch was applied, virtual systems reverting to previous snapshots, and services that were disabled or failed to restart. Organizations can use this component to focus efforts on remediating both current and previously mitigated vulnerabilities.