PCI scanning and penetration testing

Question

We are moving a web app from an internal merchant hosted setup to a general service we can offer to other organisations. The actual credit card data handling is done by a level 1 PCI compliant third party via an iFrame, so we never see any of the data. Even so the SAQ is jumping from A to D according to the discussions we've had with a QSA.

I'd like to get an understanding of scanning and penetration testing from those that have been through it before. That seems to be the largest external cost for us and may affect our architecture.

The vulnerability scanning seems to be an automated service which looks for major issues. The costs appear to start from a few hundred dollars a year.

Penetration scanning seems to be a manual process where someone actively looks for holes in the security. The costs appear to start from 3k-4k a year. The scanning is broken into external and internal scanning, I'm not clear on where the border is between internal and external. For example, does external include a logged in user? It also seems possible to do the internal scanning yourself if you have done the correct training.

We had planned to have a setup (webserver etc) per client so that all their data etc would be completely siloed and allow customisation, each client would have their own subdomain. I'm wondering now if that would require a penetration test per setup?

From the examples in the SAQ around penetration testing it seems that a new one must be done for (what I would consider) fairly small changes e.g. updating the OS. How does this relate to the application level? Will we be able to do new releases without having to do a new penetration test?

Any advice on how a startup should approach this is appreciated. Of course I understand only a QSA can give the final word.

Update: Thanks for the responses, I should've read the PCI penetration testing guidance document before posting this question. From that document the scope of the system seems particularly important to get right.

Answer 1

I'm not clear on where the border is between internal and external. For example, does external include a logged in user?

Internal penetration testing is done within your network itself. External penetration testing would be outside of that. It does not really consider a users authentication status, only network layout.

We had planned to have a setup (webserver etc) per client so that all their data etc would be completely siloed and allow customisation, each client would have their own subdomain. I'm wondering now if that would require a penetration test per setup?

In your setup, where the payment page is hosted in an Iframe, PCI-DSS only applies to the Critical Systems, ie the actual website(s) that host the Iframe based payment page. While your PCI-DSS compliance exposure is reduced in the scenario, you do still have to attest to compliance, but on a more limited basis. If architected correctly, your app servers would not fall under PCI-DSS scope.

Unless you really need to host the payment page, you could actually outsource that website to a 3rd party hosting service, and monitor their own PCI-DSS compliance. See PCI Penetration Testing Guidance Section 2.2.1 This would remove the requirement for you to manage penetration testing completely. Again, if architected to isolate these Iframe payment servers to a PCI-compliant 3rd party, you could legitimately bypass your own PCI-DSS compliance requirement completely.

If for technical or other reasons you need to host that page, then again, your penetration testing scope is limited to those critical systems.

Though you may want to do penetration testing on your actual application servers, hopefully you can bypass the PCI-DSS requirement and cost by clearly dividing the app and payment servers in your network.

From the examples in the SAQ around penetration testing it seems that a new one must be done for (what I would consider) fairly small changes e.g. updating the OS. How does this relate to the application level? Will we be able to do new releases without having to do a new penetration test?

The above Penetration Testing Guidance document also spells out what is considered a Significant Change of a designated Critical System section 2.6 page 8. It is up to you to consider the impact of a configuration change per your environment and processes. Assuming you have isolated card holder data from your app servers, you can isolate your releases from your PCI-DSS compliance scope.

See also PCI DSS E-commerce Guidelines page 22, for roles and responsibilities under an Iframe based eCommerce setup.

Answer 2

It depends a lot on the specific companies you choose to use - there are some common terms, but it is not unheard of to come across "automated penetration testing", or "manual vulnerability scanning".

In general, a vulnerability scan is designed to look for common flaws: it will detect out-of-date server software, unpatched systems, open ports which should be filtered, and a few more specific flaws, such as default usernames and passwords being used on publicly available systems. It can also either take place externally, where it looks at what is visible from the outside of your network (usually a remote service, hosted by the security company), or internally, where it looks at what can be seen from the perspective of a user on your network (usually a pre-configured appliance which the security company provides, and which you host on your network somewhere).

On the other hand, a penetration test tends to be more targeted, looking specifically at your systems. A tester will look at open ports and software on the systems they can see, and work to abuse them. This might include testing for things like SQL injection or cross-site scripting issues, or running brute force attacks against passwords or usernames. These types of test can be more dangerous to the systems being tested, so automated testing tends to err on the side of caution, to prevent accidental outages. Pen testers are also more likely to pick up on logical errors, where the application does something that it shouldn't (can you buy goods without paying? Can you change your user privileges?), which automated vulnerability testing won't detect.

Internal and external scanning for pen testing is usually the same as mentioned above - internal tests look at the system from the point of view of a device connected to the internal network, and often find issues which could be exploited by malicious activity by company staff. External tests are more like standard attacks by malicious third parties.

Both are very useful tools, and can be used in conjunction very well - have an initial vulnerability scan to pick up on any low hanging fruit. Fix those, then have a penetration test, which is likely to pick up on any more difficult issues (by sorting the low hanging fruit, the penetration testers will have more time to look at the more specialist parts of your system - they have to report the simple stuff if it's there). Then have a regular scheduled vulnerability scan to ensure any new deployments don't have issues. You can get a penetration test for new systems too, if you like, or if there are major changes to your code or systems, but assuming you make use of a secure development life cycle, you shouldn't need to test every little change, unless you're in a business area with high levels of compliance (e.g. banking applications are often tested after even minor changes).

Answer 3

We had planned to have a setup (webserver etc) per client so that all their data etc would be completely siloed and allow customisation, each client would have their own subdomain. I'm wondering now if that would require a penetration test per setup?

This would require both internal and external vulnerability scans, but not necessary penetration testing. The external vulnerability scan must be done by an ASV, and should include all external IPs and domains in scope. The internal vulnerability scan should include all internal, private IPs and should be done by an internal qualified resource, or by an external company specialising in security.

As per the guidance the penetration testing can be done in a pre-release environment. Page 7 states:

2.3.4 Separate Testing Environment

Because of the nature and the intent of penetration testing, such testing in a production environment during normal business hours may impact business operations, and attempts to avoid disruption may increase the time, resources and complexity of the testing. This is especially important for high availability systems that may be impacted by penetration testing in a production environment. To avoid disruptions and to speed up testing, a separate environment that is identical to the production environment may be used for testing instead of the production environment. The penetration tester would need to ensure the same application and network-layer controls as production exist in the testing environment. This may be accomplished through methods to map out the production environment to verify it matches the testing environment. This should be included in the rules of engagement. All exploitable vulnerabilities identified during the testing must be corrected on production systems and testing repeated to verify that security weaknesses have been addressed.

So as long as each customer environment mirrors the pre-release environment where your pen-testing took place, I would expect this would be sufficient.

Yes, you should provide logins. This way the tester can ensure that permissions have been appropriately setup for each of your documented access levels.

In addition to the above, remember that all custom code should have some type of security assessment (PCI DSS 6.6):

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: 􏰀

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes 􏰀
• Installing an automated technical solution that detects and prevents web- based attacks (for example, a web- application firewall) in front of public- facing web applications, to continually check all traffic.

See here for official guidance on this.