A Public Key Infrastructure (PKI) is a set of hardware, software, people, policies and procedures needed to create, manage, distribute, store and revoke digital certificates and manage public key encryption. It is often said (especially within the consultant community) that PKI implementations follow the 80/20 rule… 80% planning and 20% execution. This concept cannot be overstated. But it’s most often applied to those PKI specific, cryptography-related decision points such as namespaces, key lengths, signature hash algorithms and so forth. These are critical, to be sure… and difficult, if not impossible, to change after the fact. But equally important – especially in the medium to large enterprise space – are the non-technical, organizational aspects of PKI.
This blog post will focus on the organizations within the enterprise that are PKI stakeholders, whether they know it or not, and their touch points that can be leveraged toward an optimal deployment, and thus ultimately an optimal ROI.
Policy
Prior to making the technical design decisions like those listed above, use cases should be carefully analyzed and a policy should be developed, solicited, reviewed, revised if necessary, and ultimately published. Following the Certificate Policy/Certificate Practice Statement standard in RFC3647, the policies specify – among many other things – certificate subscribers, acceptable usage, revocation requirements and physical and logical access control conditions. The successful creation and adoption of – and adherence to – an approved CPS are the keys to a claim of PKI auditability.
If the PKI in question is publicly-facing and will provide any level of trust between your organization and any others, it should be specified up front at the project level that your Corporate Legal and Control & Audit/Compliance departments have hands in a formal review and sign-off process. Even for an internal-only PKI, it is a best practice, in our view, that these groups be involved in the development, review and approval of said policies.
Implementation
Two organizations that can play vital roles in the enterprise PKI space are Change Management and Problem Management. While it’s unlikely that they would need to be involved in the technical design decision-making processes, an hour or two PKI implementation overview and an attached Q&A session with these groups can be invaluable.
Change Management
PKI discussions with the Change Management group should focus on:
- Changes required to the environment for implementation
- Standing/reoccurring change definition and scheduling
- Steady-state change types and associated risk levels
These are examples of PKI events that – compliant with the enterprise’s formal Change Management standards – should be submitted, reviewed, approved and logged.
- Publication of root CA certificate(s) and deployment of issuing CAs (these tasks generally require Enterprise Administrator-level access)
- Implementation of PKI role-based access control (e.g., local server Administrators, audit log settings changes, certificate template delegation, etc.)
- Root CA CRL publication: A “standing”, or reoccurring, change request can be established for this task. If an offline root CA’s CRL must be generated and published manually, as is often the case, having a formal Change Management process around it provides a couple of advantages.
- It allows for the appropriate parties to be tracked and notified (in the case of required multi-part authentication and segregated physical access controls for the cryptographic materials)
- It allows for an enterprise-wide “set of eyes” on the process, decreasing the chances that the task could get overlooked if managed, for example, in one or two individuals’ calendars
- Revocation of any certification authority in the PKI hierarchy
- Any changes to the PKI’s security model or access controls
- Any changes to the PKI’s trust boundary (in either direction)
- Any enterprise-wide changes required for PKI operations, such as enabling certificate auto enrollment on the “Default Domain Controllers” policy
- New certificate template deployment; changes to (or removals of) existing templates
Generally considered out-of-scope in enterprise Change Management are day-to-day PKI operations such as certificate requests and issuances, unless specific circumstances dictate otherwise.
Problem Management
The Problem Management team generally has its finger on the pulse of who’s responsible for what across the IT organization. The reason for having them in a PKI overview/Q&A (as mentioned above) is to make that true for the PKI environment as well.
If an enterprise PKI is implemented without the up-front involvement of this organization, significant delays can be added to problem resolutions and root cause analysis efforts down the road. For example, if a company’s office Wi-Fi environment depends on certificate authentication from end to end, it should be known to check a Microsoft NPS RADIUS server certificate for validity should an entire site be affected by a Wi-Fi outage.
This can expand into other areas as well (far beyond the length of this blog), such as the corporate Help Desk and Desktop Support organizations, especially where the PKI and its components become more mission-critical to the end user.
Conclusions
Across policy, design, implementation, testing and support, involvement and awareness are key. Documentation (and keeping it current) is critical. As a parting thought, the enterprise’s PKI project owner could create a PKI e-mail distribution list spanning all of these organizations for, if nothing else, periodic updates as to what’s been deployed, what issues have arisen (and how they were resolved) and what’s coming down the road… will all internal web servers require SSL by a certain date? Will client certificates be required next quarter for Wi-Fi or Direct Access? Toward the end of a CA’s validity period, is it time to circle the wagons and start planning for the refresh?
All questions that Certified Security Solutions (CSS) can help with as far as your requirements definitions, planning and implementation approach.
