Securing PKI: Compromise Response

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

As with any other critical piece of infrastructure, it is vital to have a plan of action in the event of a PKI compromise. Unfortunately there is not a one-size-fits-all formula for what to do when a PKI is compromised or presumed compromised. Depending on the type and severity of the compromise, you may have several response options, each with their own positive and negative attributes. This section will focus on steps that can be taken prior to compromise and during response to help you make the best decisions to protect the security and availability of your business.

Inventory PKI Consumers

It is very important to know who the PKI consumers are and to identify systems dependent on PKI. For a Microsoft PKI using Enterprise CAs, use the certificate database to get a general idea of the types of certificates issued using the CA MMC snap-in or using the certutil –view command. In general, the certificate templates used by the CA can help to identify the consumers. However, the database may have entries removed and there is a configuration option for certificate templates to allow high-volume certificates to be issued without being entered into the certificate database. Consumers using certificate templates requiring input for the subject name, such as those used for issuing certificates to web servers, or consumers requiring a Certificate Manager approval or an Enrollment Agent need to be handled individually. Consumers using certificate templates with autoenrollment where the request processing is transparent merely need a refresh of their certificate.

Understanding Compromise Scenarios

There are many Compromising PKI for a PKI. In general, attack scenarios can be broken down into four main categories.

Full Key Compromise

An attacker has a copy of the private key and can sign whatever they desire. An example is a case where an attacker steals a code-signing certificate and can sign arbitrary code from any system of their choosing, or where a PKCS#12 file containing the CA private key is exported from the CA.

Full Key Access

An attacker has access to the private key, such that the CA does not have sufficient information to determine the set of certificates that needs to be revoked. An example is when an attacker gains access to a CA where the key is stored on an HSM, but allows arbitrary requests to be signed such as with certutil –sign in a Windows® environment.

Limited Key Access

An attacker has access to a certificate issuance system and can get certificates, but the system has full records of the unauthorized certificates issued. In this situation, revocation is possible. An example is if enrollment agent credentials are obtained. The CA will still log all issued certificates.

Other Attacks

This category includes other attacks such as Denial of Service (DoS) which may block the issuance of new certificates and revocation lists, theft of an HSM without access token, or theft of partial set of HSM access tokens which may make it easier for the attacker to obtain the CA’s private key.

Full Key Compromise and Access

When a CA is compromised, assume that every certificate issued by the CA is potentially compromised. The response from an End Entity perspective is slightly different, and the handling of the CA or PKI in general depends on the type of compromise.

There are two major compromise possibilities for full key compromise or access for a CA - an operating system compromise or a cryptographic compromise. Both of these compromises are covered below.

Operating System Compromise

There are a number of attack vectors for the operating system of a CA server and the response depends on many factors. Operating systems can be compromised physically or remotely.

Examples of physical attacks involve an attacker gaining access to a server by using the console due to:

• An unlocked server

• An attack against credentials

• An insider attack using stolen or known good credentials

• The use of storage media to inject an exploit or create a unique bootable operating system partition to make changes to the primary operating system drive

Both offline and online CA server types are susceptible to physical attack, whether it is by an intruder, an insider attack, or an unknowing person via a social engineering attack or infected file transfer device. If an offline CA is kept offline, it is not susceptible to remote attacks. However, online CA servers as well as web servers responsible for enrollment services or enrollment validation are susceptible.

Examples of remote attacks are:

• Brute force attacks against credentials to gain access using Remote Desktop Services or other remote management tools

• Utilizing an operating system vulnerability to gain access to a system

• Malware introduced by an operating system vulnerability or an unknowing person with access to the system being coerced into installing the malware

For CA servers, regardless if the operating system compromise is physical or remote, the severity of the compromise and the corresponding response depends on whether the private key integrity is known to be good or if the key integrity is unknown or compromised.

Cryptographic Compromise

Another attack vector that can lead to full key access is the cryptography of the PKI. For each public key, there is only one mathematically unique private key and the algorithm to perform encryption and decryption is well known. Researchers or dedicated attackers can dedicate multiple servers and build testing algorithms to try to derive the private key by brute force. If a weakness is found in an algorithm used by the CA, the weakness could be further exploited to identify the private key or issue certificates that appear to come from the CA.

CA Compromise Response Actions

After identifying there has been compromise, the first actions taken after determining the nature and degree of damage are to restore functionality and assurance of the CA and any End Entity certificate consumers. Some actions are more severe than others and which actions you execute depends on the type of compromise. You should document response actions in an Operations Guide or in Business Continuity plans. The following are some examples of response actions.

• Revoke individual CA certificate and publish parent CRL

  • Log on to the parent CA and revoke the subordinate CA certificate

  • Publish a new full CRL

  • Ensure CRL is copied to CDP locations

  • Force CRL Cache renewal on client workstations

  • Update parent OCSP Responders

• Force new issuance of End Entity certificates

  • Auto enrollment to replace user or computer certificates as possible

  • Certificates requiring an enrollment agent, certificate manager approval, or other intervention handled individually.

• Addition of CA certificate to untrusted store

  • Publish in Group Policy

• Retire CA server

  • Copy any data, logs, or databases needed for retention

  • Reformat or destroy the hard drives

  • Recycle server chassis parts

• Complete server replacement and HSM re-initialization

  • Obtain new CA server hardware

  • Re-initialize HSM security world or partition

  • Perform a new key ceremony

• Use existing server or replace server hardware and restore backup

  • Use existing CA server hardware as possible or obtain new hardware

  • Reinstall operating system and dependent parts

  • Restore a known good backup

• Update exploited vulnerability

  • Utilize existing hardware as possible or obtain new hardware

  • Reinstall operating system and dependent parts

  • Restore a known good backup

  • Update system after operating system is restored

• Renew CA Keys [For the entire chain/ use a larger key size / use an uncompromised algorithm]

  • Offline and Online renewal of CA Keys

  • Ensure certificates are published to AIA locations

• Migrate Key Archive

  • Extract key archival data

  • Migrate to new server

• Establish new Enrollment Agents

  • Enroll for certificates

• Establish new Key Recovery Agents

  • Enroll for certificates

  • Configure Key Archive for new agents

Correlating Compromise Types and Response

Once you understand the types of compromises and have established the potential actions for response, put a response plan in place. The diagrams below shows an example correlation between compromise and actions for a server operating system compromise and an example correlation between compromise and actions for a cryptographic compromise.

Example Compromise Action Correlation for Server Operating System Compromise

Example Compromise Action Correlation for Cryptographic Compromise

Once the response plan is complete, perform drills to practice execution of a compromise response in a test environment. Some compromise types can be addressed using the same set of actions. For example, the response for the compromise type in the diagram Example Compromise Action Correlation for Server OS Compromise | Online | Remote\Vulnerability | Unknown\Compromised is identical to the response in the diagram Example Compromise Action Correlation for Cryptographic Compromise \Online\Logical\OS Vulnerability compromise type.

Conclusion

While it is not possible to enumerate every potential avenue of compromise, having a generalized response plan in mind prior to an event will accelerate the efforts for recovery and remediation. For a complete list of the recommendations for compromise response, along with the level of business impact at which you should consider implementing them, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.

See Also

Securing Public Key Infrastructure (PKI) Securing PKI: Introduction 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: 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