2

The PCI DSS v3 standard states the following:

Network Segmentation

To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.

Say we have a cloud based system that we want to be PCI compliant, and the source code for this system is in another cloud based system like Bitbucket. Can an Octopus Deploy server that is connected to or inside the CDE connect to our source control repository via HTTPS and then deploy, or would this bring Bitbucket into scope, as a compromised repository could affect the security of the CDE? What would be a compliant way to do this automatically?

Improve this question
2

I dont know if this is PCI compliant, but you could sign the code inside the PCI compliant enviroment before uploading code to the cloud deployment system. Since the code is signed, it should in PCI sense be unmodifiable (e.g. if the repo is compromised, CDE wouln't accept data from it), thus you should be able to show that the cloud system CANNOT compromise the CDE.

You could ask your PCI assessor if a setup with signed code that is signed inside the PCI compliant system would be okay.

Improve this answer
  • Where would the code be pulled from prior to signing? Isn't this the same risk as simply pulling from Bitbucket with extra steps? e.g. Pull -> Sign -> Push -> Pull -> Check Signature -> Deploy instead of Pull -> Deploy? – SilverlightFox Oct 24 '14 at 16:57
  • No. (First upload: Write code -> Sign -> Upload.) (Modify code: Pull -> Verify -> modify -> Sign -> Push.) (Deploy: Pull -> Verify -> Deploy.) – sebastian nielsen Oct 24 '14 at 19:55
  • 1
    You propably also need to add a interlock to the signing system that prevents signing code that hasnt been verifyed, to gain PCI out-of-scope for the repo. This can ideally be performed by a HSM, where you have to feed the hash and signature of the previous modify, Before it signs the new modify. And then you have the HSM to store the signature so it will not allow Another signature than the stored, to prevent developers from bypassing the system by double-feeding the same signature. – sebastian nielsen Oct 24 '14 at 20:07
  • @sebastiannielse, that's actually exactly what Git does by default. Each commit ID is a hash of itself and its parent. Each commit, tag, etc. can also be signed with a public key. – Asbjørn Ulsberg Sep 9 '16 at 10:34

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.