CODEWITHSUNDEEP
release-managementpci-compliancepci-dss
Pavel Chernikov
Pavel Chernikov

Reputation: 2266

PCI DSS and release deployment automation

One of the PCI DSS rules is:

"The PCI DSS applies to all system components included in or connected to the cardholder data environment"

How would you go about handling an SCM/release automation server? There has to be a port open from some server in dev network segment making it's way to some server in prod network setgment.

Developers produce code, following by build manager producing release artifacts. Release artifacts must make their way to production. How do release artifacts make their way from dev to production – how do they make their way from “not in scope” dev box to “in scope” production box?

Upvotes: 5

Views: 1399

Answers (2)

Pavel Chernikov
Pavel Chernikov

Reputation: 2266

I've done a lot of research on this, and what we ended up doing is splitting up our SCM server into dvscm and pdscm.

dvscm:

  • All the developers commit code to this server
  • Build generation process stores release artifacts here
  • Dev Automated testing gets deployment artifacts from here

pdscm:

  • This server syncs the deployment artifacts from dvscm. Existing deployment artifacts are not updated, this is an add-only type of sync.
  • QA and PROD environments get deployment artifacts from there, using PSK-based connection via SSH with custom restrictive shell

This way there's a level of separation between DEV and QA/PROD. pdscm is locked down - developers don't have access to it, all firewall rules are DENY by default.

The only outgoing connection from pdscm is port 22 to dvscm, for the sync. The only incoming connections to pdscm are on port 22, connected to a user that has only premissions to read deployment artifacts, using a custom restricted shell.

Upvotes: 1

Hunter Green
Hunter Green

Reputation: 91

There's probably not a really good answer to this; to my knowledge you can't have a truly automated continuous deployment solution that doesn't cause 'in scope' to creep back to the development systems. So you have to have a manual step involved in deployment, but you can make that step as small as possible.

In the retail system I was recently working on (~100 cash registers in ~80 locations) we picked one register that happened to have some excess network bandwidth, and designated it as the 'island' system. We'd be able to take an update as a single file (zip or something) and drop it on that system, and it would install there, then propagate out to all the other registers in all locations. So we've narrowed the window of manual effort to a single file on a single register.

The safest and simplest way to cross that bridge is SneakerNet -- bring that file on a thumbdrive to that system every time there's a software update -- but it is possible to use a remote desktop approach to copy a file to that system and stay within scope, as long as the process is not automated and you're on entirely unrelated networks.

Upvotes: 2

Related Questions