PCI-DSS Scanning
The effectiveness of the Payment Card Industry (PCI) standards to secure systems responsible for credit card transaction processing is a question of debate among information security professionals. Regardless of the hype or negativity surrounding PCI, it remains a requirement for many organizations to follow. Nessus has built-in PCI-DSS compliance checks that compare scan results with the PCI standards and produce a report on your compliance posture. It is very important to note that a successful compliance scan does not guarantee compliance or a secure infrastructure. Compliance scanning is just one tool to be used as part of a comprehensive program that includes the appropriate policies and procedures to ensure that assets are appropriately protected.
I recently tested the Nessus PCI-DSS auditing functionality to determine how some of my scans compared to PCI-DSS standards. I started by acquiring a system that would most likely be governed by the PCI standard. I located a free virtual appliance configured with osCommerce, an open source online merchant site and shopping cart system. After I got the system running, I noticed the pre-installed software was already out-of-date. For example, the version of osCommerce included in the virtual appliance I used was two versions behind according to the osCommerce web site. This is a perfect testing ground for Nessus and PCI because there will most likely be areas where the PCI compliance fails, and other areas that pass.
Configuring a PCI-DSS Nessus Scan
The PCI standards council publishes a guide titled “Payment Card Industry (PCI) Data Security Standard Security Scanning Procedures” which outlines how to conduct a scan when performing a PCI-DSS audit and states:
“The ASV scanning solution must include an exhaustive fingerprinting scan on all transmission control protocol (TCP) and user datagram protocol (UDP) ports.”
The above requirement leads us to the following steps to configure our scan policy:
Step 1 – Configure your scan policy to scan all of the UDP and TCP ports on the remote host. This can be done in one two ways. If you are not scanning with credentials (this is the case for most QSVs, or Qualified Scanning Vendors), then configure the network-based portscanners:
If you have credentials on the target host(s), then only select the local portscanners:
The netstat portscanners will invoke the netstat program on the target host and collect open port information rather than testing via the network. The local scanners are more efficient; issuing a local command is much faster than probing all ports and waiting for a response.
In both cases the “Port scanner range” is set to “1-65535″, which is applied to any of the selected portscanners. The UDP scanner is not new to Nessus, but versions prior to Nessus 4.0 were only available for ProfessionalFeed customers and required that you download a separate plugin from the Tenable web site . It is now included in Nessus 4.0 and has been updated with various improvements.
Step 2 (Optional) – If you have credentials on the target host(s), enter them for your target system on the Credentials tab. Our target system is Linux, so we will use SSH to authenticate. For production use, generate a public/private keypair for your Nessus server, and then copy the public key to your production systems. See the Tenable blog post “Configuring Nessus To Scan Through Firewalls” for an example of this. The Tenable portscanners and plugins that perform local scanning activity require that you scan with credentials. In our test case, the osCommerce virtual appliance was built using Fedora Core release 5, so we will use local security checks from Nessus.
Step 3 – Enable all plugins:
To perform a successful PCI-DSS compliant scan, all plugins must be enabled including the policy compliance checks shown above. For more information about the specifics of these plugins, refer to the Tenable blog post, “PCI-DSS Plugins For Nessus“).
Step 4 – Modify your global variable settings:
In the configuration screen above, enable thorough testing and experimental scripts, both of which are required for a successful PCI compliant scan
Step 5 – Enable PCI DSS compliance checking:
Finally, we will need to enable the compliance checking in the Advanced tab. At
this point we are done configuring our scan policy and can click “Save”.
Step 6 – Disable the firewall on the target:
On the target host the local firewall must be disabled. PCI requires that no firewall exist between the scanner and the server being tested. To do this within Fedora Core release 5, I’ve issued the following command:
# service iptables stop
Disabling the firewall also helps the scan run faster, as scanning all UDP ports over the network through a firewall is a very time consuming task.
While removing the firewall from the equation can help speed up the scan and allow the scanner to enumerate all of the vulnerabilities available from the network, leaving it enabled can also have value. If the firewall is enabled then a vulnerability scan is launched against it and the scan fails, this shows that your defenses are working properly (provided there was no DoS condition on the target host). The primary reason to disable it here is to allow the scan to complete in a reasonable amount of time. However, its is good to test your firewalls with the vulnerability scanner to ensure they are blocking the correct ports and functioning per your policy and procedures.
Scanning & Reporting
Now we are ready to initiate the scan, which will take a bit longer than many Nessus scans you may have performed, as we have enabled all plugins, thorough tests, and UDP scanning. When the scan is complete, we can see that our system is not compliant with PCI-DSS specifications. Plugin 33929, “PCI DSS compliance“, has analyzed the results and determined that we are not compliant due to several vulnerabilities identified during the scan.
The PCI compliance scan results are mixed into the report; some are in the “general/tcp” section and others are appended to the entries associated with a particular open port and service. The best way to gather all of the scan results is to use the filtering feature in conjunction with the report template feature introduced in Nessus 4. The first step is to create a filter that will only display results from the PCI compliance plugin:
Clicking “Apply Filter” will bring you back to the NessusClient where the filtered results will be displayed. You can then choose a report template, such as “Sort By Vulnerability Detail” and click “View template…”. Your web browser will open and display your custom report:
The new report displays all of the alerts that caused the scan results to be not in compliance with PCI-DSS. This report can now be used to go back to the web server and remediate the problems until the scan passes the PCI compliance checking.
Conclusion
The PCI-DSS standard is focused primarily on finding vulnerable web servers. If your organization is a level 3, 4 or 5 merchant you also have PCI requirements to demonstrate usage of access control, anti-virus protection, system logging, and many other types of security monitoring. NessusProfessional Feed users have access to a variety of configuration auditing polices to help test for these PCI requirements. Tenable Security Center and Log Correlation Engine users can also monitor system logs and network activity in real time to monitor and report on a many different types of PCI audit requirements. For more information about Tenable’s enterprise PCI monitoring, please contact our sales staff to request our Real Time PCI Monitoring white paper.
References
