4

Should a test/demo/non-prod system be prohibited from using the same HSM as production? Since the same master key would be used for both test and prod it seems like it could raise eyebrows but I can't find any specific guidance around this topic.

1

Yes.

Sharing the same HSM(s) across multiple environments (e.g. dev, test, pre-prod, production) is the corporate equivalent of using the same password on multiple web sites.

Many large corporations periodically copy their production data into their QA/test environments. These lower environments typically have much less stringent data access controls in place. This means that if the same HSMs are in use in both locations, the data that had been properly protected in the production environment could possibly be improperly accessed in a non-production environment and then leaked to the outside world (or "exfiltrated", for those of you using Google to find this). So the defense against this is to ensure that there is no possible way in which the non-production systems can access the keys that the production systems used to protect the data. Which means separate HSM infrastructures for production and non-production.

And from a PCI perspective, if you can simply say to your auditors that your non-production environments simply have no way to access the keys used to protect the production data, that would save you more than the cost of the additional HSMs.

0

The big thing is this:

Although the HSM takes care of a lot of the management for you it doesn't relieve you of the obligations outlined in any standards you are working under.

I'm sure there is similar verbiage in any other standard that you'd be working under.

From a PCI-DSS Perspective:

In the PCI-DSS 2.0 standard, section 3.5.1 and 3.5.2b:

3.5.1 Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary.
3.5.2.b Identify key storage locations to verify that keys are stored in the fewest possible locations and forms.  

Generally speaking a QA environment has a much larger number of folks with access to the system, which would breach 3.5.1. If a breach in the QA system allowed for a breach in production I'm sure 3.5.2.b would also get pulled out.

  • Thanks @Tim 3.5.1 is not really relevant in this case. The keys themselves are on the hsm which only a few folks have access to and even then the hsm's will not export a private key. 3.5.2.b would seem to enforce using the same hsm for test/prod in order to ensure that the keys are stored in the fewest locations. All the encryption operations use DUKPUT. I'm wondering what risk, if any, is there from using the same master key for both test and production data? – gnomer Sep 10 '14 at 18:30
  • @gnomer, I agree with Tim. Using the same HSM in dev/test as in prod increases the amount of people with access to the data, as everyone on dev/test/prod can now access it rather than just those users on prod. As for 3.5.2b, three different HSM's would use three different keys, therefore not storing the same key in more than one place. – Chris Murray Sep 11 '14 at 8:13
0

One concern you may have with using a single HSM for different environments is that the key management requirements for the Dev/Test environments may not be consistent with the requirements of a production environment.

For example my understanding is that some HSMs can be placed in a "development or test" mode which may allow for key material to be retrieved from the HSM.

This might be desirable in a dev. environment for debugging purposes but would be extremely undesirable in a production environment.

So my conclusion would be that if the HSM is managed at all times as a production HSM, there shouldn't be any particular problem but that this could reduce its usefulness as a test/demo HSM...

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.