3

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.

2

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.

  • I don't want to disagree with you, but I think some clarification needs to happen. PCI Scope is anything that CC data touches, which is why network segregation is brought up so much. However, if you host a web page that calls out to third party service, and physical servers those web pages are hosted on are in scope, and if they are virtual, those virtual servers, and their management layer are in scope. I guess I am not on board with the definition of "critical systems". AD can be critical to the organization, but that doesn't mean it needs to be in scope. – Shane Andrie Oct 22 '15 at 17:07
  • Agreed, if you host the payment pages on your network. But if the Iframe payment site, and the payment processor are both hosted by PCI-compliant 3rd parties, then the merchant themselves are not responsible PCI-wise for those servers, as nothing on their network would touch CHD. I would clarify that Iframe code itself would be in scope, and should be scanned by an ASV. There is some XSS/site redirection and SSL compliance risk there. – Rodrigo M Oct 22 '15 at 17:30
  • I like the idea of reducing the scope, but are you suggesting a redirect? Pragmatically I see the risk is that an attacker breaks in and either changes the source of the iframe or the redirect to a page they control, I don't see away around that. Just so we're talking about the same thing, the iframe code is on my page, but the contents that is being loaded into that iframe is from the third party. Could you explain a little more about separating the app and payment server? I'm not sure how that would look. – Richard Oct 24 '15 at 19:05
  • To reduce scope, you should separate the application servers from the payment servers. Say the payment server (Iframe host) is store.example.com and the application server is app1.example.com. If app1.example.com does not touch/store CHD, then only the payment server would be required to. In this way store.example.com could even be hosted by a 3rd party, apart from 3rd party merchant processor service and your app. – Rodrigo M Oct 26 '15 at 14:14
3

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).

  • In our case we don't really have an internal network yet, we use AWS so would that mean giving access to each segmented section? For the retesting, is it possible to retest just the application? If the network stays the same? I do see the software changing a lot in the first year or two at least. – Richard Oct 24 '15 at 18:53
  • You would probably need to provide a jump off box which was "internal" to the network being tested - usually, in the same firewall group, so it can speak to boxes in the same way as the boxes speak to one another. You will also need to get specific pen test authorisation from AWS (see aws.amazon.com/security/penetration-testing for current details - there is a form to fill in). You can scope a retest for just an application, yes. Depending on the changes, might be worth getting full tests on it though - retests tend to focus on known issues that have been fixed. – Matthew Oct 26 '15 at 8:42
1

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.

  • The infrastructure for each client would be the same though we were planning to have the app to be customised per client, with some having significant changes. We may have to wrap that into one app with different modules or something, not sure. I find 6.6 a little strange, why not do both? – Richard Oct 24 '15 at 19:23
  • From the linked document: PCI SSC recognizes that the cost and operational complexity of deploying both options may not be feasible. Further, one or the other option may not be possible in some situations (no access to source code, for example). However, it should be possible to apply at least one of the alternatives described in this paper, and proper implementation can meet the intent of the requirement. – SilverlightFox Mar 17 '16 at 11:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.