Let's say you have some sensitive user data you need to protect (e.g., for PCI compliance) and you have done this by having the server code encrypt it before storing it in a separate server where no single user has access to both.

But what could be done to stop whoever is deploying the code modifying it to save it elsewhere unencrypted (or encrypted with his own key), or otherwise querying and decrypting the database manually (since the server itself would need a way to decrypt it)?

It feels like something DRM would be used for, but I somehow doubt that's what happens in practice (and DRM is inherently insecure). I don't see how a TPM would help either due to the server needing to be able to both encrypt and decrypt.

What is required with regards to this when applying for PCI compliance? What is often done to prevent the above "decryption"? What would change if the server only needed to encrypt ("write") and not decrypt ("read")?

Note: I'm not applying for PCI compliance - I'm just interested in how it's done.


There's actually no control in the application itself. Often how this is checked in practice is by employing two-eye principles for deployments (no one user can access or change the system on its own) or they use solutions which perform full command accounting like Powerbroker or CyberArk.

Note that these systems should then also be managed by independant teams.

  • How would one implement such a two man principle for deployments other than with the the command accounting tools you mentioned? My first thought goes to "how can I stop an authorised user gaining superuser without another authorised user present?" – 小太郎 Feb 15 '16 at 9:21
  • @Lucas-Kauffman It's also possible to hardened a server by only allowing signed code run on it (at least, on Windows servers). It can be disabled by an administrator but that can easily be audited. That doesn't make it impossible for someone with system access to tamper with the process but it makes it quite a bit harder (at least, without leaving a trace) – Stephane Feb 15 '16 at 11:15
  • @小太郎 these solutions provide virtual shells, meaning a super user never can get direct access but has to go through a hopping server running the auditing software. The software can be configured in such a way that it refuses connection at certain times or when certain conditions are not met: – Lucas Kauffman Feb 16 '16 at 2:36

The best thing here, would be to sign the code, using a custom root imported into the server. (Internal PKI is permitted for PCI compliance if the PKI system in question is only used internally)

Preventing someone from modifying the server software if they have physical access is impossible, so what you need to do, is to put the server physically secured such as so 2 persons need to scan their access card at the same time to gain physical access to the server. Preferable, the dual control is handed out to developer (one that writes the code) and deployer (one that deploys the code).

The best here would be to have 2 doors to the server room (in series), wherer the deployer has the access card to the first door, and the developer has the access card to the second door. This means both of them needs to be come together to be able to do physical maintenace on the server.

Then you can have a deployment terminal between these 2 doors, where the server will only accept code from the deployment terminal if its signed by the custom root. Since this deployment terminal is behind the first door, only the deployer have access to this terminal, not the developer. This means that the developer and deployer does not need to come togheter to install new software on the server, but still, both developer and deployer needs to accept the very same code, but can do so at separate locations.

Note that everyone, even those that do only have partial access to a system that is PCI certified for storage of cardholder information (with partial access, I mean when a access is locked so 2 persons need to come together and autenticate, and the person is only holding one half of whats required to gain access) needs to be fully vetted, eg you need to request rap sheets from police department, and possibly you even need to check the relatives of the person to be employed, so the person applying for employment don't have a father that previously have robbed a bank. (For example, in sweden, the whole social network is checked when applying for very sensitive employments, and this check is done by "Security Police", in sweden called SÄPO, and you as a applyer only get a yes or no, you don't get to know who in your social contact net that was "untrustworthy", to protect the privacy of these persons, and its even that you are not allowed to been suspected for any crime in the latest 5 years either, even if you never was convicted)

So the requirements are that those persons that do have the possibility to gain access to a PCI enviroment that is certified for storage of cardholder data, MUST be carefully vetted, and if you carefully vet them, you shouldn't have this problem from the very beginning that they go "rogue" and possibly disable any security protection on the server.

The protection outlined in PCI requirements, is there to protect against outside access primarly, eg if someone breaks into the server hall with, lets say a C4, and steals the server, the data should be unreadable. Thus, preferable any encryption keys should only exist in RAM (where a password, that preferable only exist in 2 parts, one half in the head of the developer, and one half in the head of deployer, must be typed at boot), and any attempt to tamper should be protected with a alarm that will shut down the server before someone comes way too close.

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.