Best Practices to Minimise PCI DSS Exposure

Question

Michael Rembetsy from etsy.com offers some insight in terms of segmenting software components into PCI and non-PCI environments.

I'm trying to determine to most optimal solution in terms of software architecture. Is it best practice to segment your PCI-related software into separate services, or just separate software components?

For example, if we consider payment-processing; is it best practice to encapsulate logic into source code modules contained within a PCI environment, and push code changes to production in parallel with a non-PCI environment, or is it best to encapsulate payment-processing logic into individual services in a SOA fashion?

In other words, does any given feature from a non-PCI code base communicate with any given feature of your PCI code base (accepting a credit card, for example) over a communications protocol such as HTTP, or should I simply provide PCI-related features as a packaged dll/jar, etc., that the non-PCI feature references?

It seems to me that encapsulating PCI-related features, such as payment-processing, into individual services is more desirable, given that we can control the level of service discoverability and define explicit boundaries, whereas simply providing a dll/jar potentially exposes secure source code to decompilation by developers in a non-PCI environment

Answer 1

The answer really depends on what you wish to achieve with the segmentation.

If you goal is to somehow reduce/contain the in-scope systems for PCI DSS assessment, then in my experience source code modularisation will not help you. Your assessor will most likely define in scope "systems" by whether these systems process, transmit or store card holder data as defined by PCI DSS. In my experience, modularisation of the source code will not help you remove that machine/device from the scope of the assessment.

Should your goal be purely a software architecture decision, then I would suggest that the impact of both approaches on the non-functional requirements (i.e. performance, availability, security etc.) be reviewed to determine which approach suits best.

In saying all that, my advice would be in line with the other posters - abstract your PCI sensitive systems behind clear service boundaries. At a minimum this will allow you manage the life cycle of the two system separately. More importantly, it will give you the flexibility to change the deployment architecture of the PCI pieces without having to change the dependent systems. PCI DSS is a live standard so something that meets requirements this year may not next year. In my experience, having some level of agility through loose coupling and SOA helps you re-architect deployment models to suit new constraints.

I hope this helps! :)

Answer 2

Are you OK with hackers compromising your email list and shipping database and emailing all your customers saying that they hacked you, furnishing an accurate shipping address as proof they got into the database? (even if they did not really get to the PCI protected credit card numbers, etc.) If not, consider putting as much as you can behind PCI because it all needs protecting.

The credit card compamies will consider you 'post-compromise' if the above happens, even if no CC info was compromised. They hate the 'appearance' of a successful hack, probably more than you would...