Before diving into technology, its best to start by asking the following questions:
- What kind of information are we trying to protect?
- What is its value?
- Who will have privileged access to the PKI and how much trust can be placed in them?
These questions are important to answer as it will drive the entire composition of the PKI. No matter what, you’re going to have to deal with the “T-word”: Trust. Business users will need to have at least some level of trust in the certificates that are issued. If there is no measurable degree trust, your PKI adds no value to your organization.
Establishing trust (or assurance / reputation) is a very demanding task and because PKI is a tightly integrated security mechanism, the stakes are much higher. It involves communicating, implementing, and managing a combination of technology and written procedures. While that sounds rather daunting, we’re really talking about two things: protecting private keys (especially Certificate Authority private keys) and managing the lifecycle of issued certificates.
So how do you know what measures are sufficient to establish trust? By nature, trust is a rather subjective concept that doesn’t translate well into Information Technology. Fortunately, it turns out that there are published standards you can leverage to help provide an objective model on which to base your design. One of them is the Federal Public Key Infrastructure Policy Authority (FPKIPA). Why the FPKIPA? It turns out that most of documents out there in the industry are derived from it, assigning it as a sort of de-facto standard for PKI operations. While most companies are not looking to cross-certify with government agencies, the documentation provided by the FPKIPA serves as an excellent starting point for classifying the level of trust that is appropriate for your environment. For example, it specifies the following levels of assurance in its certification policy:
|
Assurance Level |
Appropriate Certificate Uses |
|
Rudimentary |
This level provides the lowest degree of assurance concerning identity of the individual. One of the primary functions of this level is to provide data integrity to the information being signed. This level is relevant to environments in which the risk of malicious activity is considered to be low. It is not suitable for transactions requiring authentication, and is generally insufficient for transactions requiring confidentiality, but may be used for the latter where certificates having higher levels of assurance are unavailable. |
|
Basic |
This level provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but they are not considered to be of major significance. This may include access to private information where the likelihood of malicious access is not high. It is assumed at this security level that users are not likely to be malicious. |
|
Medium |
This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial. |
|
Medium Hardware |
This level is relevant to environments where threats to data are high or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk. |
|
High |
This level is reserved for cross-certification with government entities and is appropriate for those environments where the threats to data are high, or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk. |
In practice, most corporate environments fall under Rudimentary, Basic, or Medium classifications. While they are considered non-binding according to the FPKIPA, each one does have its own set of standards. In particular, be sure to pay attention to section 6.2.1 of each policy mapping matrix. This section stipulates what FIPS 104-2 security level needs to be implemented, which in turn drives a significant part of the PKI design.
An understanding these standards will provide you guidance on what, as a best practice, you should implement in order to meet the necessary level of trust. To help pull this together, I have classified common PKI uses to the following suggested assurance levels:
Rudimentary: No special operational procedures or hardware required.
- Machine certificates that are auto-enrolled to enable IPSEC domain isolation or enhanced machine authentication. These certificates do not safeguard actual data, but facilitate more secure communications through confidentiality.
Basic: Basic assurance requires meeting the functional requirements specified in the Common Criteria Protection Profiles (level 2), which includes enforced separation of responsibility for certificate approval vs. Certification Authority (CA) management. This is natively supported in Windows 2003 Certificate Services. An auditing process is also required. Enrollment requests must be made by end-users and the requests must be manually authenticated via a documented procedure.
- Application security. Example use cases are certificates for enhanced VPN authentication and digitally signed and encrypted email.
- Strong authentication for users (smart cards). For some environments, user certificates will require medium assurance.
Medium: Medium assurance builds on basic and ads the requirement of a Hardware Security Module (HSM) to protect the private key of each Issuing CA.
- Digital signatures for code, contracts, or approvals. Falsification or misuse of certificates in this instance would likely cause significant damage to company both financials and, perhaps more importantly, reputation.
- Data encryption. Accidental disclosure of data could lead to serious liability issues. This is especially important when personal information (social security numbers, credit card numbers, medical records) is at stake.
So if you’re looking at leveraging PKI to help secure your environment, start by contemplating the certificate assurance levels that are appropriate for the information you are trying to protect. Familiarize yourself with the documentation published by the FPKIPA and utilize its well established standards as a reference point for your design. This will help you start the process in a logical way and give you a path for achieving a recognized level of trust that will add value to your organization.
