Securing PKI: PKI Process Security

Article
08/31/2016

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012

As mentioned above in the Securing PKI: Introduction section, maintaining the trust of relying parties is an integral component to managing a PKI. If the PKI has no formal policy defined, the relying parties cannot make an informed decision whether to trust certificates issued by the CAs. This is especially important when certificates are distributed to external third parties. Otherwise, there is no clear understanding of how the PKI is managed.

To facilitate this trust, you should deploy and operate a PKI with some level of oversight, and with policies, standards, and procedures in place to manage the PKI. The level of oversight and the number of controls required will vary depending on the intended use and security impact of issued certificates. For example, a CA trusted and used internally to issue certificates for wireless network authentication does not need the same amount of oversight as a CA that issues SSL certificates to customers. In both cases, define and set the security bar for the PKI from the start.

PKI Policy

Prior to deploying any CA or issuing a certificate, define and agree upon the policy which governs the use of the PKI. A policy usually takes into consideration regulatory and industry requirements as well as unique requirements for your company. The policy may also specify technical aspects of the PKI such as the cryptographic algorithms that must be used as well as operational controls for the CAs.

It is likely that other services either inside or outside of your environment will depend on the PKI, and the PKI policy should provide a clear guidance on what can be expected for certificate issuance, security, disaster recovery, etc. The policy does not need to be overly complex, but it is critical to develop and follow it from the beginning to have a level of assurance in the operated PKI.

In addition to PKI policy, you may need to develop CA-specific policies before implementing the PKI. These policies may be expressed differently depending on the required level of assurance. They can be expressed either as documented statements about certificate usage and issuance controls for a simple internal CA or as a formal Certificate Policy/Certification Practice Statement that follow IETF Public Key Infrastructure X.509 Certificate Policy and Certification Practices Framework (RFC 3647) with accompanying standard operating procedures.

Certificate Policy

As defined by IETF, a Certificate Policy (CP) is “a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.” That is, a CP defines the expectations and requirements of the relying party community that will trust the certificates issued by its CAs. For example, the CP explains what methods are used to establish the identity of a subject before issuing a certificate. A Certification Practice Statement (CPS) outlines the operation of the PKI from a security perspective and must be followed from the initial deployment of a company’s CAs. These formal documents may be overkill for a typical enterprise PKI deployment, but they provide a good structure to think about for your PKI and risk assessment.

It is quite common to delay creating a CP/CPS until after some CAs are already deployed in the environment. However, it is recommended to not begin server deployment or even CA hierarchy design without clear definition of your PKI policy based on your own risk assessment and with approval from all affected parties within the company. Consider getting input from both the legal and audit departments while defining the policy if it affects external parties. The existence of a comprehensive and accurate policy and certification practices is critical in creating a reliable PKI.

Certification Practice Statement

The CPS sets the security standard for the PKI solution and is used as the source for the PKI security requirements. Note that you may choose to not create this formal document, but it is quite useful to follow the CPS structure to develop and document your own policy. A CPS is important when certificate subscribers exchange or use certificates with partners and entities outside of the company's network. When external trust is implemented, you need to align PKI policies and practices as part of external contract terms and a CPS is a good way of achieving this.

The CPS basically translates CPs into operational procedures on the CA level. The CP focuses on the make-up and uses of a certificate; the CPS focuses on a CA.

It is important to make conscious decisions about what practices will be used for certificates. You should include both the decision and reasoning behind it in the documentation. By doing this, you are able to state what your practices are so that these practices can be tested and evaluated in production. When setting up monitoring, use this documentation to specify what should trigger an alert and what is acceptable per certificate issuance best practices.

Effective key management controls and practices expressed in the CPS or similar documentation within your company are essential to the trustworthiness of the PKI. These practices should cover CA key generation, CA key storage, backup and recovery, CA public key distribution, CA key usage, CA key destruction, CA key backup, and the management of CA cryptographic hardware through its life cycle.

The certificate lifecycle is at the core of the services provided by the CA. The user certificate lifecycle usually includes the following:

Registration (the identification and authentication process related to binding the End Entity to the issued certificate)
Renewal/rekey of certificates
Revocation of certificates
Timely publication of certificate status information

Effective controls over the registration process are essential because poor identification and authentication controls jeopardize the ability of clients and relying parties to rely on the certificates issued by the CA. Effective revocation procedures and timely publication of certificate status information are also critical elements because it is critical for relying parties to know when they are unable to rely on certificates that have been issued by the CA.

The establishment and maintenance of a trustworthy CA environment is essential to the security and reliability of the CA’s processes. The CPS (or similar documentation) must describe how logical and physical access to the PKI and data is restricted to authorized individuals, how the continuity of key and certificate management operations is maintained, and how CAs development, maintenance and operations are properly authorized and performed to maintain PKI integrity. Without strong CA environmental controls, strong key and certificate life cycle management controls are severely diminished in value. CA environmental controls must include:

PKI policy management
Security policy management
Security management
Asset classification and management
Personnel security
Physical and environmental security of the PKI facilities
Operations management
System access management
Systems development and maintenance
Business continuity management
Monitoring and compliance
Auditing

PKI Governance and Oversight

This section is applicable to big enterprises or government organizations because of the complexity of their environments. A common error for organizations during PKI solutions deployment is the lack of PKI governance or oversight. The goal of governance is to ensure the consistent management of the policy including its formulation, the applicability of policy, and measurement of compliance with policy. Governance plays a significant role in a successful PKI because a PKI is not a static system. There will likely be ongoing changes within the environment that will drive operational or security changes to the PKI. For example, ongoing risk assessments will uncover new risks which the governing body of the PKI should take into account when developing the policy. The governance structure for the PKI policy is usually known as the Policy Authority. The Policy Authority is responsible for identifying the appropriate set of requirements for a given community and oversees the CAs that issue certificates for that community. Proper governance will ensure that any changes introduced are well understood, carefully considered, and are well communicated to the community of relying parties. The following are some recommendations s for ensuring proper governance and oversight:

The Policy Authority should use existing policy structure
If a policy team exists already, get them involved
Whenever a PKI may affect external customers or partners, involve the legal department in the work of the Policy Authority
Formalize the work that the Policy Authority does. For example, if members of the Policy Authority approve changes, ensure that the approval process is documented and tracked. Take formal votes and keep meeting notes.
Establish regular meetings to review and update the PKI policy

Roles and Responsibilities

PKI process security relies on trustworthy personnel to deploy and operate the PKI. Personnel security plays a critical role in the PKI’s overall security. Design personnel security to prevent both unauthorized access to the PKI facility and CAs and compromise of sensitive CA operations by CA personnel. Inadequate personnel security procedures or negligent enforcement of personnel security policies can pose potentially serious threats to security. These threats can include unauthorized access, data loss and corruption, denial of service, and even facility sabotage or terrorism. Such events can erode or destroy confidence in the PKI.

While planning for CA deployment or operations, clearly define and assign individuals to trusted roles. A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. It is essential that the people selected to fill trusted roles be held accountable to perform designated actions correctly because if they fail to do so, the integrity of the CA and the PKI is weakened. The functions performed in these roles form the basis of trust in the CA. There are two approaches to take in order to increase the likelihood that these functions can be successfully carried out. The first approach is to minimize the number of trusted roles and ensure that the people filling those roles are trustworthy and properly trained. The second is to enforce the concept of least privilege and distribute the functions of the roles among several people, so that any malicious activity requires collusion (multi-party control).

Trusted roles include the following responsibilities:

Overall responsibility for administering the implementation of the CA’s security practices
Approval of the generation, revocation, and suspension of certificates
Installation, configuration, and maintenance of servers that operate the CA
Day-to-day operation of the servers
CA backup and recovery
Maintenance and review of audit records
Cryptographic key life cycle management functions (for example, key component custodians)
Development and validation of the CA

The mandatory trusted roles usually defined are the CA administrator, certificate manager (or security officer), the CA operations staff, and security auditors. Multiple people may hold the same trusted role with collective privileges sufficient to fill the role. Maintain lists for those who act in trusted roles and define the number of persons required per task. When multi-party control is required, all participants shall hold a trusted role. Do not achieve multi-party control using personnel that serve in an auditor role with the exception of audit functions.

The following tasks usually require two or more persons:

Generation, activation, and backup of CA keys
Performance of CA administration or maintenance tasks
Archiving or deleting CA audit logs. At least one of the participants must be in an auditor role.
Physical access to CA equipment
Access to any copy of the CA cryptographic module
Processing of third party key recovery requests

Some roles require separation of duties. For example, individuals serving as auditors shall not perform or hold any other trusted role. Therefore, only an auditor may perform internal auditing functions, with the exception of those security audit functions (configuring, archiving, deleting) that require multi-person control. Enforce roles separation by requiring that an individual who performs any trusted role have only one identity when accessing CA equipment. The way to achieve this in AD CS is described in Securing PKI: Technical Controls for Securing PKI.

Personnel considered to fulfill trusted roles should present some proof of the requisite background, qualifications, and experience needed to perform their prospective job responsibilities competently and satisfactorily. In some cases it might be wise to ask persons fulfilling trusted roles to pass a comprehensive background check (in accordance with local privacy laws) and ensure that they periodically undergo background checks.

All personnel performing duties with respect to the operation of CAs should receive training to perform their duties. This training could be formal or informal, and is like the training for other IT systems. In some higher security environments, it is beneficial to formalize the training and track completion prior to granting access. Training should cover the following topics:

PKI security principles and mechanisms
All PKI software versions in use on the system
All PKI duties they are expected to perform
Disaster recovery
Business continuity procedures
Stipulations of established PKI policy

Key Generation Ceremonies

As mentioned previously, secure CA key generation is essential to the trustworthiness of the CA and PKI. An important portion of secure CA key generation is to ensure that CA key pairs are generated in accordance with the PKI’s established policy. This is achieved by following predefined procedures specified within detailed key generation ceremony scripts. As mentioned before, plan the key generation ceremony in advance and include relevant parties in its approval.

The CA key pair generation must create a verifiable audit trail demonstrating that the security requirements for procedures were followed. The ceremony must be documented in sufficient detail to show appropriate multi-party control and role separation were used. Depending on the established security policy, generation of CA keys should be witnessed by an independent party and/or videotaped and all CA key generation activities must be logged.

Develop a ceremony document that contains a list of the materials used, the trusted roles and responsibilities, the ceremony roles list, and a detailed step-by-step script for HSM setup, CA deployment, and CA configuration. The ceremony script must contain fields for signatures of operator and witness, and be specific on produced ceremony artifacts. Below is an example of a ceremony script:

Step	Description	Operator Initials	Witness Initials
1	Prepare Hardware Resources Confirm that the appropriate hardware resources are present and inspect each for tampering: Private network switch Monitor, Keyboard, Mouse HSM Transport media Tamper-evident security bags Confirm the hardware is not connected to any external systems or network.
2	Server Configurations
3	Pre-Generation Configurations
4	CA Installation Connect to HSM Begin CA installation Copy artifacts to the transport media
5	Request CA Certificate
6	Install CA Certificate
7	Post-Issuance Configurations
8	Backing Up server

Sample Key Generation Ceremony Script

Conclusion

Defining a Certificate Policy/Certification Practice Statement, regardless of how formal you choose to be, provides a baseline expectation of what relying parties can expect from your service. Creation of these documents also act as a forcing function to ensure that all aspects of your PKI management have been given some consideration. Enforcing the concept of trusted roles helps ensure those operating the PKI meet a minimum standard of training and experience prior to being granted access to high value assets. Performing key signing ceremonies provide assurance that proper steps were followed, which mitigates risks associated with keys being created or managed insecurely.

For a complete list of the recommendations for creating PKI processes and documentation, along with what level of Determining the Level of Protection Required at which you should consider implementing them, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.