Organisations that handle payment card information are legally required to regularly scan and test their systems, but too few understand that these are separate things.
Any organisations that process, transmit or store cardholder data must comply with the PCI DSS (Payment Card Industry Data Security Standard). This is a complex set of requirements, which includes the need to conduct regular vulnerability scans and penetration tests to identify weaknesses that could be exploited by cyber criminals.
Unfortunately, many organisations are under the impression that scanning and testing are simply two phrases for the same thing. That’s not true: they are distinct activities with their own requirements and purposes, which we explain in this blog.
What is vulnerability scanning?
Vulnerability scans are automated tests that look for weaknesses in organisations’ systems and applications.
Organisations can use a variety of off-the-shelf tools to conduct vulnerability scans, each of which runs a series of ‘if–then’ scenarios that identify system settings or features that may contain known vulnerabilities.
A completed scan will provide a logged summary of alerts for the organisation to act on.
What is penetration testing?
Penetration testing is essentially a controlled form of hacking in which an ethical hacker, working on behalf of an organisations, looks for vulnerabilities in same way that a criminal hacker would.
The objective of penetration testing is similar to vulnerability scanning, but it is more thorough and requires expertise and human interaction.
Additionally, penetration tests are designed to not only identify weaknesses in an organisation’s system architecture but also how they could be exploited. Armed with this knowledge, organisations can pinpoint how effective their security controls are and which areas need to be improved.
For the purposes of PCI DSS compliance, there are four types of penetration test:
- Network penetration tests
- Web application penetration tests
- Wireless penetration tests
- Social engineering penetration tests
How vulnerability scanning fits into your PCI DSS compliance project
All organisations have vulnerabilities; they’re simply unavoidable in any complex system like modern IT environments, especially when that system is subject to complex change.
Vulnerability scans can help identify many types of weaknesses, which you can regularly review and address where necessary.
Internal and external scans must be configured to scan specific interfaces, like internal or external IP addresses and portal services in order to identify vulnerabilities.
You’ll need to bear in mind that quarterly external scans are a separate requirement from quarterly internal scans, and must therefore be conducted separately. The PCI DSS also requires that internal vulnerability scans be conducted by a qualified person who is independent of the device or component being scanned. This individual will need to take responsibility for configuring the appropriate tools and performing the scans.
To pass a PCI DSS external scan, all items listed as critical, high risk or medium risk (i.e. those with a CVSS (Common Vulnerability Scoring System) score of 4.0 or higher and specific findings that are considered automatic failures) must be remediated or disputed by the organisation. Remediation is usually the best approach.
If your scan fails, you must schedule a rescan within 30 days to prove that the critical, high-risk or medium-risk vulnerabilities have been patched. Many organisations simplify the task by performing monthly scans to keep on top of any emerging vulnerabilities.
How penetration testing fits into your PCI DSS compliance project
PCI DSS requirements 11.3.1 and 11.3.2 state that penetration testing must be performed at least annually and after any significant changes to your network or applications.
Penetration tests require a great deal of technical expertise and must therefore be carried out by a qualified professional. Those with the necessary qualifications are bound by strict ethical rules, which should resolve any concerns you might have about giving someone access to your systems and inviting them to attack your organisation.
Penetration tests are relatively easy to schedule from an organisation’s perspective, because the penetration tester will oversee most of the technical work. That said, organisations should have a clear plan about what the test will entail and how it will affect their staff and business operations.
For example, you might prefer to schedule the test outside of office hours to minimise the disruption to the networks or applications that are being tested. Alternatively, you might want to look at how staff would react to an attack (as is the case with a social engineering penetration test).
You also need to factor in the level of access that you’ll give the tester. Will you give them background and system information (white-box testing) or ask them to start from scratch (black-box testing)?
White-box testing is the more direct option, because the tester will have more to work with at the outset. Meanwhile, black-box testing creates a more realistic simulation of a criminal attack, and you’ll be able to see exactly how a crook would infiltrate your organisation.
What are your security testing requirements?
The specific testing requirements that apply to your organisation are determined by your assessment status.
All organisations should consider some form of penetration testing, but you won’t be required to if you fall into the criteria of any of the following SAQs (self-assessment questionnaires).
- SAQ A: For merchants that outsource their entire card data processing to validated third parties. This includes e-commerce merchants and mail/telephone order merchants.
- SAQ B: For e-commerce merchants that don’t receive cardholder data but do control the method through which data is redirected to a third-party payment processor.
- SAQ B-IP: For merchants that don’t store cardholder data in electronic form but use IP-connected point-of-interaction devices. These merchants may handle either card-present or card-not-present transactions.
- SAQ C-VT: For merchants that process cardholder data via a virtual payment terminal rather than a computer system. A virtual terminal provides web-based access to a third party that hosts the virtual terminal payment-processing function.
- SAQ P2PE: For merchants that use point-to-point encryption. It’s therefore not applicable to organisations that deal in e-commerce.
Scanning and testing with IT Governance
IT Governance is a CREST-accredited provider of security testing services. Our range of testing services enables organisations of all sizes to effectively manage cyber security risk by identifying vulnerabilities that could expose infrastructure, applications, wireless networks and people to attack.
You can receive more of our advice on complying with the Standard in Security testing and the PCI DSS.
This free guide unpacks the complexities of the Standard, providing practical guidance on how to test the security of your systems and processes, and better protect the payment card information you store.
IT Governance is your one-stop shop for information security and regulatory compliance. Our range of books, toolkits, training courses, staff awareness solutions and consultancy services can help you with whatever you’re looking for, and our blog helps you stay informed of the latest industry news and advice.
