Securing PKI: Introduction
Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012
Attacks against computing infrastructures, whether simple or complex, have existed as long as computers. However, within the past decade, increasing numbers of organizations of all sizes, in all parts of the world have been attacked and compromised in ways that have significantly changed the threat landscape. Cyber-warfare and cybercrime have increased at record rates. “Hacktivism,” which attacks are motivated by activist positions, has been claimed as the motivation for a number of breaches intended to expose organizations’ secret information, to create denials-of-service, or even to destroy infrastructure. Attacks against public and private institutions have become ubiquitous, with the goal of exfiltrating the organization’s intellectual property (IP).
When looking at your environment, an appropriate mindset is to assume that you have already been breached or a breach will occur at some point. No organization with an information technology (IT) infrastructure is immune from attack, but if appropriate policies, processes, and controls are implemented to protect key segments of an organization’s computing infrastructure, escalation of attacks from penetration to complete compromise might be preventable. The principles and recommendations provided in this document are intended to help secure your environment against external attackers and misguided or malicious insiders.
The information and recommendations provided in this document are drawn from a number of sources and derived from practices designed to protect Public Key Infrastructure (PKI) installations against compromise. Although it is not possible to prevent attacks, it is possible to reduce the attack surface and to implement controls that make compromise much more difficult for attackers. This document presents some of the most common types of vulnerabilities observed in compromised environments and most common recommendations to improve the security of PKI installations.
While many of the recommendations found in this document are specific to PKI installations that utilize Active Directory® Certificate Services (AD CS) as a technology platform, many of the recommendations are also vendor agnostic and can be implemented in any PKI deployment.
If you operate a PKI within an Active Directory® (AD) environment, it is strongly recommended that you also read Best Practices for Securing Active Directory. Since the security of the AD CS installation is in many respects directly dependent on the security of the Active Directory® installation, an understanding of the avenues to compromise and methods to secure Active Directory® will greatly enhance your ability to secure your PKI deployment.
About this Document
Content Origin and Organization
Much of the content of this document is derived from knowledge gained from years of PKI and Active Directory® assessments performed by numerous Microsoft information security professionals. Additional recommendations are gathered from extensive experience gained from operating numerous PKIs at Microsoft, both for external and internal uses. Although individual customer data was not used to create this document, the most commonly exploited vulnerabilities identified from our assessments and the recommendations to improve security of AD CS installations are utilized. Not all vulnerabilities are applicable to all environments, nor are all recommendations feasible to implement in every organization.
PKI Assessments and Consulting
Within Microsoft, numerous organizations provide consulting services for PKI. Depending on the needs of the customer, an engagement may include PKI design, implementation, compromise response, or assessment for health and security. Microsoft provides customers with recommendations based on their organization’s unique characteristics, practices, and risk appetite. PKI assessments performed internally at Microsoft and those of our customers have contributed to the recommendations in this paper.
Content Scope
This paper is not intended to address all potential security issues across PKI, but rather is focused on providing actionable content for areas in which Microsoft has seen deficiencies while performing assessments over several years with many customers. Specifically, this document does not attempt to provide recommendations for other Active Directory® Certificate Services roles such as Network Device Enrollment Services (NDES) or Online Certificate Status Protocol (OCSP).
Introduction to PKI
PKI Components
Within any PKI regardless of the technical implementation, a number of components and actors are present. This brief introduction will help provide context and definition of terms used throughout this whitepaper.
Subscriber/End Entity – The person or computer listed as the subject in a certificate. In the context of this whitepaper, an End Entity certificate is any certificate issued to a person or computer.
Relying Party – A user or system that consumes the certificates generated by the PKI. Examples of relying parties would be users of web browsers visiting an SSL protected web site, a VPN server authenticating a remote user, or a computer validating that an executable is signed correctly before running it.
Certification Authority (CA) – Broadly, a CA is a set of systems and practices used by an organization to issue and manage certificates. For the context of this paper, the CA will be the system responsible for signing certificates and running CA software such as Active Directory® Certificate Services.
Registration Authority (RA) – A CA may delegate some of the tasks related to verifying identities and processing certificate revocation requests to a Registration Authority (RA). An RA could be a person performing manual checks or a system automating the required validation checks. The CA will accept certificate requests processed by the RA and sign them, trusting that the RA has done the proper validation.
PKI Repositories – A PKI repository is a location accessible by relying parties where PKI information is stored. This information could include certificates, revocation information, or information regarding the policies of the PKI. For example, this information can be posted to internal or external web locations.
For a glossary of terms used in this whitepaper, refer to Securing PKI: Appendix D: Glossary of Terms.
For basic information about PKIs, refer to Securing PKI: Appendix E: PKI Basics.
PKI Governance
Maintaining the trust of relying parties is an integral component to running a PKI. If a relying party does not know the policies a PKI uses for governance, or the PKI has no formal policies, they cannot make an informed decision to trust that the certificates issued by the PKI are correct. To facilitate trust, a PKI must be operated with some level of oversight, and with policies, standards, and procedures in place to control how the PKI is managed. The level of oversight required will vary depending on the intended use. For example, a PKI trusted and used internally at a company to issue certificates for wireless network authentication does not need the same amount of oversight as a PKI used to issue SSL certificates trusted by default by all major web browsers. Governance is not a topic unique to PKI- other critical infrastructure systems should also be run with formalized change control and oversight.
Business Drivers for PKI
Whenever a new piece of technology is introduced to an environment, it should be for a defined business reason and PKI is no exception. In many cases, we have observed a PKI introduced at a company in support of a specific solution or product. For example, a PKI could be constructed to provide end user certificates in support of secure remote access. In general, PKI can be thought of as an enabler for providing solutions for the following high-level business requirements:
Data Encryption – PKI provides several solutions for securing data in transit and at rest. PKI is commonly included as a part of a solution to securely exchange data between partners, customers, or internal sites. Common implementations include using certificates to enable Transport Layer Security (TLS) for secure transmission of data, S/MIME certificates for sending encrypted email, and Encrypting File System (EFS) certificates to encrypt files on a workstation.
Authentication – PKI is often used as a solution to provide high-assurance authentication credentials. Common implementations include issuing certificates for private keys that reside on a smart card for multifactor authentication and issuing certificates to computers and devices for network authentication.
Data Integrity – PKI can be used to ensure that critical data has not been altered and that it comes from a trusted source. One common implementation is code signing, where files are signed by the developer when a software package is released. Another example is electronic document signing, where certificates can be used to allow a person to “sign” a document to show the document has not been altered since the signature took place.
Elements of a Successful PKI
For a PKI deployment to be successful, several factors must be in place:
Understanding of Business Requirements and Objectives – Like any investment made by an organization, the business requirements and value provided by the PKI should be well understood prior to implementation. Understanding how the PKI supports the business, what processes it supports or enables, and any externally imposed requirements allows you to make informed decisions on the level of risk you are willing to accept when designing the system. For example, an internal PKI supporting wireless LAN authentication will be designed and secured differently than a PKI built for issuing SSL certificates that are trusted by external organizations.
Risk Assessment – A proper risk assessment and threat modeling should be performed prior to deploying a PKI. A risk assessment will determine the level of security and the investment that should be made in the PKI.
Executive Support – As with any other large-scale IT project, support from executive management is crucial in the deployment of a PKI that meets large-scale needs. A properly implemented PKI often represents a significant investment, both in capital and human resources. Executive management needs to have a clear vision of why PKI must be designed and operated differently from commodity IT services, as well as have a clear understanding of the business requirements the PKI helps to satisfy.
Planning and Foresight – A PKI deployment is often unique from deployments of other technologies, because more stringent security controls are required for the deployment to succeed. A PKI deployment also requires the development of rigorous operating procedures. For a PKI to succeed, careful planning must occur to ensure that the policy, procedures, and technical implementation meet the needs of the business, both now and into the future. If a PKI is configured incorrectly, frequently the only good solution is to start over and implement a new system. With proper planning, you will be able to avoid costly rework or compromise.
When planning a deployment, pay special attention to any shorter term (12-18 months) uses of the PKI. If you do not plan at the very beginning to accommodate known future uses, you may end up setting up parallel infrastructures in the future, or be forced to modify the existing infrastructure in ways that make it more complex and costly to operate.
Defined Policies – Prior to implementing any certification authorities or issuing certificates, define and agree upon the policies which govern the use of the PKI. Applications either inside or outside your environment will be dependent on the PKI, and these policies will provide clear guidance on what to expect for topics such as certificate issuance, security, disaster recovery, etc. Policies do not need to be overly complex, but it is critical to develop and follow them.
Ongoing Governance and Oversight – Governance plays a significant role in a successful PKI because a PKI is not a static system. There will likely be ongoing changes within your environment that will drive operational or security changes to your PKI. Proper governance ensures the risk of any changes introduced are well understood, carefully considered, and are well communicated to the community of relying parties.
Determining the Level of Protection Required
As stated in the prior section, it is critical to perform a risk assessment and develop a threat model prior to deploying a PKI. The recommendations provided throughout this paper are not one-size-fits-all for every PKI deployment; each deployment is unique in its requirements. To assist in determining what recommendations may apply to your deployment, each recommendation has been categorized based on impact level, which (at a high level) is a measure of the impact a CA breach would have on the business it supports. The following impact levels are used to classify the recommendations:
High Business Impact – Customer or Partner Impacting – This classification relates to CAs that, if compromised, could impact your customers or partners, as well as have an internal impact.
High Business Impact – Internal Impact – This classification relates to CAs that if compromised, could impact internal operations of your company significantly. Examples include CAs that issue certificates used to protect proprietary data, or allow authentication to internal systems or networks. Many ADCS deployments, regardless of intended use, will fall into this category.
Moderate Business Impact – This classification relates to CAs that are not widely trusted in your environment or do not support critical business processes.
Each CA should be analyzed to determine the impact of a breach. In most cases, all CAs in a hierarchy will have the same impact level. However, there are some cases where a subordinate CA may have a lower impact level than the root or other subordinate CAs because technical constraints may prevent it from being used in more critical use cases. For a complete list of recommendations in this paper along with the recommended impact level at which to implement them, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.
Compromising PKI
Except in exceptional cases, compromise of a PKI is not the ultimate goal of an attacker. Rather, an attacker’s motivation is typically to acquire other desirable data such as trade secrets, payment card data, or other data. Compromising a PKI in an environment may be a necessary step for attackers to gain the credentials required to access the desired data. There are several compelling reasons why an attacker may attempt to compromise a PKI as part of an enterprise breach:
Elevation of privilege – An attacker can leverage the PKI to gain credentials that will allow them to gain full access to desired systems or potentially all systems across the target environment.
Persistent access – While many attacks begin with attackers using backdoors on systems to maintain access to an environment, compromising a PKI and obtaining credentials can allow attackers to use the “front door” and access the environment through legitimate means such as a Virtual Private Network (VPN) or DirectAccess (DA).
Impersonation – Compromising a PKI can allow an attacker to create credentials of VIP users who have access to desired data.
In many cases, compromising a PKI and obtaining fraudulent certificates allows an attacker to traverse the network using methods that look very similar to normal user activity and are difficult to detect.
How PKI Compromises Occur
PKI systems should be guarded as some of the highest security systems in an environment, so an attacker may require several steps to accomplish a compromise. In a typical breach, attackers gain a foothold into the environment by exploiting systems not current with security patches or outdated applications. For a more complete list of common attack vectors in an Active Directory® environment, refer to Best Practices for Securing Active Directory. Once the attacker gains some basic level of access within the network, the following are some of the common scenarios that result in a compromise of the PKI:
Misconfigurations
A common method of compromise is for attackers to leverage misconfigurations within the PKI to issue certificates for other users of systems for which the requesting user should not have rights to request, or certificate types that the user should not be able to request. Examples include misconfigurations in template permissions, such as overly broad enrollment permissions, or misconfigurations on the CA that allow users to request certificates with user-defined data. Misconfigurations in allowed certificate usages and constraints could also allow attackers to create subordinate CAs with arbitrary attributes.
Inadequately Secured Certification Authority Systems
In many cases, the CA servers are run and managed similarly to any other system in the environment. This includes the CA systems being built from the same image as other systems and includes many unnecessary applications that increase the attack surface of the CA. Operating a CA in this manner exposes it to many additional attack vectors, including attacks from other enterprise systems such as monitoring, update management, backup, inventory, etc. PKI attacks are sometimes opportunistic in the sense that an attacker may not have been planning on compromising PKI, but because they gained a credential for an account that had access to the PKI, they leverage it. Common vectors for attack in this scenario are passwords left with default build values, generic configurations of software that allow overly broad access, or excessive administrator rights on the CA.
In other cases, the CA is built using a custom “one off” configuration where adequate documentation does not exist and the configuration has not been thoroughly tested. While custom installations can lessen the attack surface when done correctly, they can also introduce misconfigurations, as standard processes are often not followed. Compromised CAs often do not adequately protect the CA keys, leaving them vulnerable to attackers either on the system or in backups.
Inadequately Secured RA Systems
Many PKI designs use a front end RA system to handle validating requests for certificates. While the back end CA may have good security, in some cases the RA systems are not secured in the same manner. If this is the case, attackers may be able to compromise the RA and use its credentials to issue the certificates they need to further their attack. Some examples of RA systems include smart card management software, Network Access Protection (NAP) Health Registration Authority (HRA), and Network Device Enrollment Services (NDES).
Social Engineering
Each CA should implement its own set of practices, both logical and process-driven to ensure the identity of the subject requesting a certificate is validated. If there are deficiencies in these practices, it is possible for an attacker to use social engineering techniques to have certificates issued to them. For example, an attacker could have an employee smart card shipped to them by pretending to be a remote employee if home addresses are not validated. An attacker pretending to be a web administrator could have an SSL certificate issued on behalf of a highly sensitive payroll system to perform a man-in-the-middle attack.
Protecting a PKI Deployment
Whether you are operating an existing PKI or planning to deploy a new PKI in your environment, the recommendations provided in this paper are intended to mitigate many of the common insecurities and shortcomings addressed in the previous section. Beginning with recommendations to consider during the design phase, each section will cover an aspect of PKI systems and provide recommendations for specific approaches or general guidance to consider for the threats in your environment. Not all the recommendations provided in this paper will be applicable to every environment. Consider the Determining the Level of Protection Required would have on your business through a risk assessment and implement those controls which help to mitigate the known threats. A comprehensive list of all recommendations in the paper is provided in Securing PKI: Appendix F: List of Recommendations by Impact Level, along with the impact level at which you should apply the recommendation.
See Also
Securing Public Key Infrastructure (PKI) Securing PKI: Planning a CA Hierarchy Securing PKI: Physical Controls for Securing PKI Securing PKI: PKI Process Security Securing PKI: Technical Controls for Securing PKI Securing PKI: Planning Certificate Algorithms and Usages Securing PKI: Protecting CA Keys and Critical Artifacts Securing PKI: Monitoring Public Key Infrastructure Securing PKI: Compromise Response Securing PKI: Appendix A: Events to Monitor Securing PKI: Appendix B: Certification Authority Audit Filter Securing PKI: Appendix C: Delegating Active Directory PKI Permissions Securing PKI: Appendix D: Glossary of Terms Securing PKI: Appendix E: PKI Basics Securing PKI: Appendix F: List of Recommendations by Impact Level Security and Protection Secure Windows Server 2012 R2 and Windows Server 2012