When in the context of the Payment Card Industry (PCI) categorizations, a company is almost always considered to be one of five types of entities: Merchant; Processor; Acquirer; Issuer; Service Provider; or both Merchant and one of the other four. If a company is not one of these entities, they likely have no need to be PCI certified. The vast majority of companies looking to go through PCI certification are categorized as Merchants or Service Providers. A Merchant is a company that handles front-end payments and submits requests to a processor for a payment transaction. Processors, Acquirers, and Issuers handle the card processing. Service Providers are everything else – an ISP, a security service, a managed provider, etc. If any one of the other categorized entities accepts credit cards for payment then they would also be considered a Merchant.
In the latest release of the PCI DSS (version 3.2) there has been significant confusion and misinformation around the new mandate regarding semi-annual testing. Contrary to much of what we have seen, the new mandate does not require semi-annual “penetration testing.” The specific new requirement as stated in section 11.3.4.1: Service Providers, specifically those that use segmentation as a security control to isolate the cardholder data environment (CDE), must perform the segmentation testing semi-annually. The requirement for internal and external penetration testing is unchanged and is still required annually or after every major infrastructure change.
We’ve seen confusion around this, in that most people think the change is requiring penetration testing to occur semi-annually. This costly misunderstanding can affect businesses two different ways: One, a business can pay more money than really needed to in order to get two penetration tests done every year. Second, a business may find they cannot get the tests done with sufficient frequency and find themselves on the failing end of a compliance audit. Neither one is a position anyone wants to be in.
In the PCI testing requirements, there are three different tests that are specifically called out:
1. Quarterly Vulnerability Scans
2. An Annual Penetration Test
3. Segmentation Tests
A Vulnerability Scan is a tool-based scan of the surface features of all of the operational systems and applications for obvious and/or scannable vulnerabilities. This scan is usually done entirely with an automated tool and minimal further validation besides false-positive verification. PCI DSS 3.2 calls out that the Vulnerability Scan must be done quarterly from both external and internal sources. Every vulnerability scan must be successful and if not successful, the vulnerabilities must be fixed and the scan re-run. However, for companies just entering into PCI compliance, only the last scan prior to the first PCI audit must be a fully successful test. Additionally, the external Vulnerability Scan must be performed by a PCI “Approved Scanning Vendor (ASV)”
A Penetration Test is a much more comprehensive testing of the network and applications based on industry standard guidelines for Penetration Testing (e.g. NIST SP800-115). It will involve both a Vulnerability Scan and a Segmentation Test, but only as starting points for much more extensive manual testing and review. In addition to the manual reviews and tests, applications are to be evaluated against an industry best practice guideline such as the OWASP Application Security Verification Standard (ASVS). In the same fashion as the Vulnerability Scan, the Penetration Test will be performed from both internal and external sources. PCI DSS 3.2 calls out that the Penetration Test must be done annually and after every infrastructure change.
A Segmentation Test is typically a simple connectivity scan done from a sampling of networks both external to the company and external to the CDE, as well as from each of the networks internal to the CDE to validate that the segmentation matches what is documented. This can be as simple as a port scan done with a tool such as ‘nmap’ or similar port scanner.
We have seen many companies looking to pass the PCI audit or companies selling compliance services pass off a Vulnerability Scan as a Penetration Test by simply verifying the scan results and reformatting the report. Some QSA’s may allow this, some may not. Many of those companies selling the compliance service will label the test as a Penetration Test, but unless there is proof of the application level testing the Penetration Test is invalid and will not pass an examination if one is ever necessary due to breach. This could expose the company to hefty fines.
EA is well positioned to perform your annual penetrations, and now soon to be semi-annual segementation tests. Feel free to contact us to find out how we can help.
Some other changes around PCI 3.2 are with regards to scoping and requirements placed on supporting systems. Stay tuned for a future post with regards to how those changes may affect you.