The Benefits of Correctly Deploying a PKI Solution

With new threats to data emerging every day, public key infrastructure (PKI) has become an increasingly larger part of enterprises’ information security and risk management strategies. Research has found that 43% of organizations have a consistent, enterprise-wide encryption strategy, and the main drivers for encryption are: 

• To protect information against specific, identified threats
• To protect enterprise intellectual property
• To protect customer personal information
• To comply with external privacy or data security regulations and requirements
• To limit liability from breaches or inadvertent disclosure
• To reduce the scope of compliance audits
• To comply with internal policies
• To avoid public disclosure after a data breach occurs

What is PKI and how does it work?
At the highest level, PKI is a set of software and hardware technologies designed to manage the creation, storage, transmission and authentication of digital certificates and their associated encryption keys.

Unlike traditional identity processes where users are identified by passwords, a PKI issues a certificate via known, trusted channels and binds the certificate to a cryptographic key pair. The key pair consists of a widely shared public key, and the holder of the certificate maintains a private key that is unknown to anyone else. A cryptographic function ties these two keys together so that actions performed by one can be verified or decrypted by the other. 

Deploying a PKI Solution
There are a lot of misperceptions and assumptions about PKI and frankly, deploying PKI in an environment is not a quick process. Almost every environment we have been brought into  has had at least one PKI that was deployed previously that was undocumented, poorly engineered, or lacking essential security controls. The data and identities based on these PKIs offer little value. As a result, we often need to remove these legacy PKIs. Here's how to begin:

1. Start with defining a Certificate Policy (CP) and Certificate Practice Statement (CPS) (RFC 3647). This will guide you through creating, defining and implementing controls for your PKI. This is where you will determine what and how your PKI will be used, managed, and secured. While (CP/CPS) are completely optional, your environment will reap stronger protection through the enforcement of these policies. We particularly like to start with the NIST 7924 Draft CP/CPS. Although it requires a good deal of customization but is a great starting point.
2. At this point you will be faced with deciding if a Hardware Security Module (HSM) is required for your Certificate Authorities (CAs). The odds are, they are, but your budget may or may not accommodate them. This is a critical decision and must be done before deploying any of the PKI servers. While you can technically integrate HSMs into an existing PKI, they only offer limited protection compared to using them initially. Take the time can consider it carefully early. Typically, an organization that doesn’t choose a HSM winds up migrating to an entirely new PKI in five years or less once it realizes the growing use and adoption of PKI in the organization. A well-designed PKI is typically in use for decades.
3. Create a clear set of build docs, configuration steps and procedures. You can often spot missing information, specifications, or dependencies by taking the time to document it all ahead of time. Identify information you need to collect and share your plan with colleagues to see if you have missed anything. A lab/sandbox environment is a great way to put your plan to work, test your build docs and see what you missed. At the end of your build, you should be able to run pkiview.msc on your certificate authority and see that all of your configuration settings are correct and in a healthy state. Use scripts or other easily reproducible automation so that once the lab is built, you can repeat the process in production. Many of the settings and properties of your CAs can only be configured at creation and can never change. This includes typos and misconfiguration of properties.
4. Prior to placing the PKI into production, ensure you are able to properly test certificates across your various platforms, appliances and applications. Create a list of the certificates you need in the environment and create the templates for them one by one. Start by manually enrolling members of the IT department and verify the process and trust of the certificates. Slowly roll out to a large group of users and computers. Autoenrollment to the entire enterprise should be the last step.
5. Your PKI is an ongoing affair. You are going to need to maintain and care for the PKI. Items in your CP/CPS will define data retention requirements, audit, security and access rights. It takes effort to define and create your PKI and unfortunately many environments neglect their PKI over time. The integrity and assurance provided are diminished. Don’t forget about the CRL intervals—especially for offline CAs. Most new PKI environments will forget to publish something during the first year. It usually will happen once and rarely happens again, as it can have a significant impact on the environment. In fact, we call our customers at the first few CRL publish dates to remind them, just in case!

Don’t shy away from implementing a PKI solution. Following steps to implement a PKI solution, including planning, installing, configuring, and testing, will help you manage the creation, storage, transmission, and authentication of digital certificates and their associated encryption keys — which is exactly what’s needed in organizations and enterprises to protect and manage data today.