3

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

Paul Mooney
  • 1,576
  • 12
  • 28
  • 2
    Our policy is to keep as much as possible out of PCI scope; anything that handles cardholder data is implemented as a minimal service that will communicate with out of scope components for business decisions, logging etc. We do this to minimise the PCI surface and because any software changes pushed to a PCI production environment must have gone through a code review/documentation process, something that is tedious & time consuming. – Alex K. Jun 20 '15 at 13:07

2 Answers2

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! :)

BrianB
  • 424
  • 2
  • 13
-1

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

Ron Robinson
  • 558
  • 1
  • 3
  • 8
  • When you say "put as much as you can behind PCI", I'm interpreting that as "Yes, host PCI-related features as separate processes to non PCI-related features, with well defined boundaries. As opposed to simply bundling PCI features into separate jar/dll files as non PCI-related features". Would you agree? – Paul Mooney Jun 19 '15 at 07:08
  • Paul, sorry my reply is so tardy - been working as National Digital Director for a presidential campaign and that keeps one very busy... to answer your question, I meant to create the understanding that one should use PCI security standards to protect *all* their client data. I had 1 security client (I was called in after the fact) who had only some email/shipping address info compromised as I suggested above. The hackers sent the same email to all the email addresses that the merchant had been hacked. The card companies hate that bad PR and will precipitate a forensic audit $10k expense! – Ron Robinson Aug 15 '16 at 00:23