My name is Ron Arestia, and I am a Security Researcher with Microsoft’s Detection and Response Team (DART). We respond to customer cybersecurity incidents to assist with containment and recovery from threat actors. In this brief blog post, we will discuss the “why” behind your PKI. This is part 3 of a series on practical PKI implementation based on my experience with customer interactions working as a Microsoft engineer.

Feel free to catch up on previous blog posts or jump right into this one

Secure Configuration and Hardening of Active Directory Certificate Services

Implementing and Managing an ADCS Offline Root Certificate Authority (Practical PKI Part 1)

CRL & AIA Publishing Guidance (Practical PKI Part 2)

In Part 3 of our series, understanding why you are implementing and managing PKI is critical to understanding the level of effort you should endeavor to start using one or keep one going. This brief non-technical discussion is meant as a primer to determine if what you are about to implement is truly going to benefit your organization as a whole.

Determine Your Technical Outcomes

This subject is the target of much debate and disagreement across my peer groups. On the one side, you have engineers who argue for or against the very provisioning of a PKI while on the other side, you have engineers who argue that regardless of purpose, administration is more important. Far be it for me to be a fence-sitter, so I stand firmly in the former group arguing that if you do not need it, you should not bother standing it up in the first place.

A few years ago, I was working with a customer with a substantial PKI presence: three issuing CAs, fully redundant HTTP CRL publishing, CEP/CES, and cross-forest publishing. When we were assessing their environment, I noticed immediately that they had a scant few templates published across those three issuers, but they had over 100,000 issued, active certificates. I dug deeper and noticed that every one of their templates except two were configured with autoenrollment. Every user and every computer in their organization was getting a certificate that was published to Active Directory. They were issuing server authentication certificates with enrollee-supplied Subject Alternative Names (SANs) without manager approval. And they were even issuing code signing certificates without manager approval albeit to a constrained group.

After lengthy discussions with them about their reasons for managing a PKI, I discovered a few very telling things:

1. Despite aspirations to use 802.1x for user and computer authentication, the infrastructure was never implemented and remained in a state of development for the last few years.
2. Despite a project to setup smart card authentication, they never moved past a pilot group of developers and administrators who were not bothering to leverage this powerful method of authentication across most of their enterprise anyway.
3. Approximately 90% of their certificates issued for web endpoints were either development endpoints that never made it to production or misconfigured certificates that had to be reissued to correct spelling errors or to add or remove nodes from SANs that were not in the original configuration.
4. More than 1,000 code signing certificates were issued, but no official code was signed by their recollection.

By the end of the engagement, they realized how much administrative overhead was going into maintaining a massive solution with little actual value for the organization. They had short root CA CRL lifetimes requiring quarterly “signing parties,” and despite a very astute team of engineers maintaining the PKI, they had built in “automation” paths that left their environment vulnerable to attack if a threat actor ever found their way in. All told, we determined that less than 2% of the total number of issued certificates (approximately 2,500) were actively used for a regular production task.

Even after discussing options to downsize, streamline, and harden their PKI infrastructure, we eventually discussed options to offload much of their certificate needs to third-party solutions. Why would I convince a customer to rid themselves of an in-house PKI?

Are You Experienced?

I believe the most important fundamental question to ask as an enterprise is if you have the staff to manage and maintain a PKI, and if so, to what extent? I would argue that having at least two engineers dedicated to this task is critical for personnel fault tolerance. If one engineer goes on vacation or suddenly resigns, you have someone who can continue to operate the environment to the same level of fidelity expected of it. This guidance scales upwards the larger your PKI grows. If you are a multinational enterprise with issuing CAs spread around the globe, you need, at the least, regional expertise to navigate administration and maintenance tasks. Ideally, you would have a resource local to each environment to ensure someone can put hands on the systems without relying on global networking.

The second fundamental question you should ask: what is the primary purpose of my public key infrastructure? Are you using it to manage an 802.1x authentication scheme across your enterprise? Are you managing smart cards or certificate-based authentication for your organization? Are you looking to issue a large number of server authentication certificates to support internal web endpoints or development efforts? Or do you believe that by maintaining your own PKI you are maintaining some level of sovereignty over your cryptographic operations that you do not want to offload to a third-party or a cloud provider?

All of these are perfectly valid reasons to maintain your own PKI, but each comes with challenges and interoperability requirements that should be documented and thoroughly understood. In 802.1x configurations, you should ensure all of your subordinate infrastructure is prepared and up to the task of handling authentication traffic and overall maintenance. One network appliance outage overnight could mean an entire office is unable to work the next morning. Smartcard and certificate-based authentication require a robust infrastructure and a team of individuals dedicated to the task of identity attribution for assignment and provisioning of those certificates. Web endpoint certificate management can quickly grow into a full-time role for an engineer in an environment with rapid iteration, and there is a delicate balance to be struck between reasonable validity periods and the possibility of regular revocation due to changes that can balloon a CRL. Finally, the decision to maintain sovereignty over certificates is often driven by cost. A true cost-benefit analysis can aid in reinforcing or diminishing from the need to stand up a dedicated PKI, and the reality is that having publicly-trusted certificates is often a much simpler solution than relying on visibility to internal publishing endpoints that require a number of security solutions.

Decisions, Decisions

The decision to stand up a dedicated, in-house PKI is not one that should be taken lightly. Sit down with your management and leadership team to outline the high-level outcomes expected of the solution and be the sober voice in the room to explain both the benefits and disadvantages of the proposed solution. If the determination to proceed is not grounded in realistic capabilities of the enterprise, do not be afraid to pull the security card, at a minimum. The security of your PKI is paramount. Without it, you are paying money to power infrastructure that is, at best, churning out unnecessary certificates, and at worst, putting your entire enterprise at risk of a cybersecurity incident.

How do we secure and maintain your PKI once the decision is made to deploy one? In Part 4, we will get back into the technical discussions about your PKI security and how to maximize your security without compromising functionality.