What Makes a Secure PKI Solution? Backups

I’ve often noticed that it can be difficult to find information in one place around PKI solutions and what makes them secure.

That’s why I’ve decided to create a PKI resource myself! This ongoing series will outline the elements that make up a secure PKI solution. This week we’re talking backups.

Backups

Just as with any other system within your organisation, PKI needs to be backed up regularly to ensure it can be restored in event of a disaster. So the Operating System, Disks and Virtual Machine are a given, but with PKI you also need to recover the following to restore your environment in case of total disaster:

• CA certificate(s) and private key(s)
• CA registry information
• CA database backup

There are a number of ways to effectively backup a CA;

• Perform a system state backup that includes:
  • Certification Authority Database
  • Registry Settings
  • CA Key information (including the private key if not using an Hardware Software Module (HSM)
• Manually back up the CA from the Certification Authority MSC Console:
  • Certification Authority Database
  • Doesn’t include the Registry nor any files to restore protected Keys
• Other methods:
  • Usage of either certutil.exe or PowerShell CA Backup and Restore cmdlets within a task scheduled frequency
    • Needs to include CA Database, Registry and Private Key Files

How can we reduce risk?

Use of HSMs (Hardware Security Modules) is a preferred way from a pure security/Microsoft perspective but this strategy can be complex to deploy and manage, restrictive, and a costly method of achieving this objective. Additionally a lot of organisations don’t have either the budget or the internal skills required to effectively deliver this method of security, regardless of whether it is the most secure option.

Are there any alternatives to HSMs? A common sense approach still applies here; if an HSM module is not a possibility or desired approach, back up the CA servers, database and registry without including the private keys and perform this backup independently so it can be stored more securely.

The Microsoft recommendation is to use an Artefact Chain of Custody, which is essentially a detailed, physical, audited paper trail of interaction with the backup. In the real world, as long as you know who touched it last and whose hands it has been through, this gives the organisation good visibility of the lifecycle of it. However it is stored (virtually or physically), as long as it is securely and reliably stored, the organisation should be able to recover technically with a strong business process/standard operating procedure defining the steps required to achieve this.

Whatever you decide for your organisation, ensure that you can securely make a backup, restore it successfully before you need it and then store it securely, both terms of physical security and environmentally.  You don’t want to be in a situation where you have limited your ability to restore from multiple points and found that your single restore media has been corrupted by magnetism, the environment or physical damage!

In summary, once again a common sense approach towards the level of security that is applied for backing up securely, versus the overall manageability of the solution, is paramount and individual to each organisation when considering the various options available. This is important not just when deploying these solutions, but ultimately when we have to rely on what we’ve implemented during routine maintenance (and hopefully never in disaster recovery situations!).

Rest of the Series

Here’s the series in full – I’ll be updating here each week as each part is released:

1. Multiple Tiers
2. RSA vs ECC
3. Access Control
4. Physical Access
5. Backups
6. Certificate Revocation Lists

If you have any questions on what I’ve discussed here or security in general, feel free to email in on info@poweronplatforms.com and I’ll be happy to answer any queries you have.