Control Objective 5: Regularly Monitor and Test Networks
This includes monitoring all systems/network access and regularly testing systems security and processes. This control objectives covers the following PCI DSS requirements:
Requirement 10: Log and monitor all access to system components and cardholder data.
Requirement 11: Test security of systems and networks regularly.
PCI Requirements Under This Objective Supported by Tenable
Requirement 10: Log and monitor all access to system components and cardholder data
Audit logs are required which capture all individual user access to cardholder data. PCI DSS requirements highlight the criticality of having a process or system that links user access to system components accessed. Log mechanisms which record relevant events are an important component in detecting unauthorized access and potential breaches. Systems should have synchronized clocks to ensure that log entries are consistent and accurately reflect the timing of events.
By keeping logs and monitoring them, organizations not only meet regulatory compliance, they can quickly identify and respond to potential security incidents and breaches. In the event of a data breach, logs provide a crucial understanding of what happened, how the breach may have happened, and the impact of the breach. While Tenable does not directly collect and store system logs, there are several checks that assist organizations with this requirement.
The Regularly Monitor and Test Networks widget within the PCI-DSSv4.0 Audit Summary dashboard covers topics within PCI requirement 10 and 11.
Both of these requirements cover tracking and monitoring all access to network resources and cardholder data, and the regular testing of security systems and processes. This widget provides details on each of the compliance controls for the compliance family group being referenced. The compliance control reference number is followed by a count, and compliance result for the compliance control. The specific controls being referenced are: 10.2.2 | 10.6.2 | 11.5.2 | 10.2.1 | 10.6.1 | 10.2.1.7 | 10.2.1.5 | 10.3.2 | 10.2.1.2 | 10.4.1.1 | 10.6.3 | 10.2.1.4 | 10.6 | 10.5.1 | 10.2.1.1 | 10.2.1.3 | 10.3.3 | 10.2.1.6
Requirement 11: Test Security of Systems and Networks Regularly
PCI DSS requires that vulnerabilities are identified and assigned a risk ranking based on industry best practices and consideration of potential impact. Continuous vulnerability scanning is essential for maintaining a robust security posture, adapting to changes, ensuring compliance, and effectively managing and mitigating risks.
Tenable assigns an Asset Criticality Rating (ACR) to each asset based on indicators of business value and criticality. ACR is based on several key metrics such as business purpose, asset type, location, connectivity, capabilities, and third-party data. An ACR score is a range from 0-10. Low scores are not considered to be business critical, and high scores represent the organizations most critical, and have a greater business impact if compromised. Organizations that are also Tenable Lumin customers have the ability to adjust the default Tenable ACR value to more accurately reflect organizational risk.
Not all vulnerabilities pose the same risk. By combining ACR and VPR, prioritization efforts focus on the most critical vulnerabilities first.
Organizations may also utilize CVSS and Severity ratings for risk prioritization. For more information on prioritization of vulnerabilities reference this document.
For additional scanning under Requirement 11 organizations should utilize the pre-configured Nessus scan templates, available in Nessus, Tenable Security Center, and Tenable Vulnerability Management. These PCI scan templates allow organizations to get started quickly, with minimal configuration, however they can not be edited. When these scans are completed they can be submitted to Tenable’s ASV Engineers for review. To maintain a set continuous scanning schedule, Nessus scans can be easily automated to run at specific times/days.
More information on this process can be found here: Submitting Scans for PCI ASV Validation.
As a PCI Approved Scanning Vendor (ASV), Tenable offers two built-in scan policies designed for PCI scanning: 'PCI Quarterly External Scan' and 'Internal PCI Network Scan'. While only the 'PCI Quarterly External' policy is valid for official attestation, both policies can be used anytime for organizational scanning purposes. For official attestation, the PCI ASV add-on is required. The two policies differ in terms of settings and plugins included- the 'External' policy is designed for an 'outside-in' perspective of the target vector and therefore only executes remote checks, while the 'Internal' policy is better suited for scanning various connected devices within an organization's network.
Mandatory Requirement: PCI Requirement 11.3.1 requires that vulnerability scans be conducted at least once every three months, and that high risk and critical vulnerabilities are resolved. Rescans are to be conducted to verify that any identified high risk and critical vulnerabilities have been resolved. Tenable’s PCI Scan policies assist organizations in meeting this requirement.
As the official External policy is approved and designed specifically in accordance with the specifications set forth by the PCI Security Standards Council, there is little customization possible with it- users are limited to adjusting the scan's performance settings to allow for proper analysis per the network's capabilities. No other customization to the External policy is permitted. The Internal policy, however, allows users to control the scan's Discovery, Assessment, Report, and Advanced settings, although plugins are not modifiable. Additionally, the Internal policy allows for the input of credentials to enable the local checks included in the scan's configuration.
A comparison between the two policies (default settings)
| Setting | Internal | External |
|---|---|---|
| Use fast network discovery | enabled | disabled |
| Override firewall detection (for TCP port scanner) | automatic | soft |
| Credentialed access (local checks possible) |
yes |
no |
| Only use NTMLv2 | yes | no |
| Paranoia level (Override normal accuracy) | normal | high |
| Perform thorough tests (slow) |
disabled |
enabled |
| CGI scanning | disabled | disabled |
| Only use credentials provided by the user | enabled | disabled |
| Elevate privileges |
disabled |
enabled |
| Test default accounts (slow) | disabled | enabled |
| Check for PCI DSS compliance | yes | yes |
| Enable Web Application tests |
no |
yes |
| Max simultaneous hosts per scan | 30 | 20 |
| Network timeout | 5 | 15 |
| Port scan range |
default |
1-65535 |
While the policies differ in terms of their various settings, the main idea for the external scan is that the policy demonstrates the publicly-visible attack vector currently present in the environment. The policy is meant to show what an attacker may be able to leverage from the external perspective, with the understanding that they would not be privy to valid authentication methods.
The settings that tend to make the biggest difference in the outcome of the two policies are the ability to authenticate with the Internal PCI policy and the increased paranoia in the External PCI policy. Use of credentials for the internal scan policy is preferred. Valid credentials allow the Internal policy to utilize a variety of local plugins, including the enumeration of missing patches. The increased paranoia of the External policy may result in some plugins reporting a vulnerability with lower confidence that would otherwise not be reported. Another key difference between the Internal and External PCI policies is how the port scanners operate. Especially if the Internal policy is provided with target credentials, the port scanner can enumerate the services running on the data plane, whereas the External policy will enumerate exposed ports, and can potentially enumerate the services running on the control plane.
Monitoring Internal Scans as part of Requirement 11.3.1
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. 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. Tenable provides Vulnerability Intelligence attributes that assist in identifying vulnerabilities used in ransomware attacks and other emerging threat categories.
To meet PCI scanning requirements, Tenable Vulnerability Management and 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 Web App Scanning
Tenable Web Application Scanning contains a built-in PCI scan template. The PCI ASV Scan is a scan that assesses web applications for compliance with Payment Card Industry Data Security Standards (PCI DSS) for Tenable PCI ASV. (This scan also allows you to view and edit the Request Redirect Limit. The default value for this limit is 3.) This scan template helps organizations who are using web servers or APIs meet the requirements for PCI 11.3.2.
