Article

Published June 2014

All organizations that exchange information over the Internet are susceptible to attack from malicious users. Electronic credentials that prove identity are a critical part of security measures. Microsoft IT has developed recommendations to help other enterprises design and protect an infrastructure that supports these credentials.

Situation

Many organizations deploy a Public Key Infrastructure (PKI) to support critical business functions, such as strong authentication of users for remote access or for helping to protect access to sensitive data. Attacking a PKI infrastructure is typically not the end goal of attackers. But compromising a PKI can provide attackers with credentials that they can use to gain further access. Security of the systems and processes that compose a PKI is an important consideration in te design and deployment of a PKI.

Solution

Whether you're operating an existing PKI or planning to deploy a new PKI in your environment, Microsoft IT has developed recommendations that can help you provide basic security controls for key business processes. The recommendations include specific approaches along with general guidance to keep in mind when you're considering the threats in your environment.

Planning a CA Hierarchy

Deciding on what type of certification authority (CA) hierarchy to implement (one tier, two tier, or three tier) is one of the first decisions that you need to make. When you're designing your CA hierarchy, consider your long-term business goals, as well as your business needs in the near term (12–18 months). It's possible to overcomplicate your PKI by trying to plan for every possible use case.

Providing Physical Controls

Malicious physical access to a system will inevitably lead to compromise. Before you deploy PKI systems, identify the key physical security controls that those systems will need, based on the impact that a compromise would have to your business. Recommendations include:

• Keep PKI assets separate from general computing assets (for example, separate locked rack, room, and cage).
• Track and audit physical access to PKI assets.
• Use strong authentication to physically access PKI assets.
• Prevent tailgating (one person following another) to sensitive areas where PKI assets are stored.
• Use alarm systems to detect access to PKI assets.
• Use camera systems to monitor physical access.
• Take advantage of existing datacenter security controls where possible (for example, alarms and cameras).

Establishing Processes

A large portion of the work that's involved with running a successful PKI is establishing repeatable processes that are well documented and consistently followed. The extent that partners, suppliers, and internal customers trust your PKI will determine how formal you need to be in documenting your processes. Your documentation may also have to meet regulatory and compliance requirements.

For externally trusted PKIs, a proper Request for Comments (RFC)–compliant certificate policy or Certification Practice Statement (CPS) may be required. If it isn't required, we recommend it. For an internally trusted PKI that isn't ever intended to be trusted outside the company, you should, at a minimum, document your practices for internal reference.

For all PKIs, provide adequate training to support staff. Develop change management procedures to ensure that changes are properly scrutinized prior to implementation. For high-impact deployments, develop a PKI Policy Authority to govern the PKI and approve any changes to the policy. For high-impact PKIs, create key ceremony documents when you create new CA keys. These documents can provide an auditable trail to show that the keys were generated according to your policy.

Providing Technical Controls

It's important to treat PKI systems as critical systems and deploy strong technical controls to help protect them from unauthorized access. As with other critical systems, you should implement hardened baselines and strict management access for them. Give special consideration to PKI systems that are always kept offline. Implement controls for offline systems so that they are never brought online and don't have malicious software introduced to them. Additional recommendations include:

• Eliminate unnecessary services and software that are running on CAs.
• Restrict access to Internet content.
• Restrict access to PKI systems by using proper configuration settings and techniques.
• Delegate PKI tasks to limit the need for privileged accounts.
• Use network isolation and firewalls as appropriate.
• Secure certificate templates and control the use of user-specified alternative names.

Planning Certificate Algorithms and Usages

Another key decision in PKI design is the suite of cryptographic algorithms to use, and the length of time that certificates are valid for. Advances in computing capabilities and cryptographic research continue to show that cryptographic algorithms have a finite lifespan. Ensure that you select the strongest cryptographic algorithms that are possible for your environment. Be aware of potential compatibility issues between operating systems and cryptographic software packages.

After you select the proper algorithms, ensure that the attributes that you allow in your certificates enable only the intended usages and do not expose your organization to misuse of issued certificates. Selection of proper algorithms will help ensure that data and processes have the best possible chance of remaining secure for their useful life.

Additional recommendations for planning for cryptographic algorithms and certificate usages include:

• Constrain issuing CAs to limit the impact of a CA compromise.
• Carefully determine the required extended key usages and grant only the usages that the use case requires.
• Use key generation and hash algorithms that are comparable in strength.

Storing and Managing Keys and Artifacts

A primary security control in a PKI is how private keys are stored and managed, particularly for CAs. Additionally, a well-run PKI will require the storage of several artifacts, such as hardware security module (HSM) activation cards or tokens, backup files, and documents. Improper storage of these artifacts can lead to the compromise of the entire PKI, without an attacker ever having to compromise a CA system. Recommendations for helping to protect CA keys and PKI assets include:

• Use HSMs for CAs, especially high-impact CAs.
• Use multiple-person control for access to high-impact keys, such as root CAs.
• Store PKI artifacts, such as HSM tokens and backups, in locations that have sufficient security measures.
• Use tamper-evident containers to store sensitive artifacts.
• Maintain a chain of custody for sensitive artifacts.
• Maintain an inventory of all sensitive artifacts and their locations.

Monitoring

A key component of any PKI security plan is ongoing monitoring of the infrastructure and supporting processes. With critical systems such as a CA, it's vital to collect the right information and have appropriate alerting and review processes in place so that if an issue occurs, it can be properly investigated. Treat CAs as a high-value systems and monitor them closely for suspicious activity.

Monitor the following PKI-specific conditions:

• Changes to critical security groups that control access to the PKI
• Changes to account attributes for users who have privileged access to the PKI (for example, userPrincipalName and userAccountControl)
• Changes to certificate templates
• Changes to CA security settings
• Suspicious use of service accounts that have permission to enroll for others, or enroll for sensitive templates (for example, smart-card management system account or Network Device Enrollment Services account)
• Physical access events, such as opening a server rack, entering a cage, or accessing a safe

When creating a PKI monitoring plan, Microsoft IT took advantage of the built-in event mechanisms in Windows. These mechanisms include enabling Active Directory Certificate Services (AD CS) auditing, configuring the CA audit filter properly, and auditing specific registry values.

Developing a Compromise Response

As with any other critical piece of infrastructure, it's vital to have a plan of action in the event of a PKI compromise. Unfortunately, there is no standard 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 option has its own positive and negative attributes. The main types of compromise are:

• Full key compromise. The attacker has a copy of the private key and can sign anything that he or she wants.
• Full key access. The attacker has access to the private key such that the CA does not have sufficient information to determine the set of certificates that must be revoked.
• Limited key access. The attacker has access to an issuance system, but the system has full records of the unauthorized certificate that was issued.
• Other attack. An attack such as denial of service, theft of HSM without access tokens, or partial sets of HSM access tokens has occurred.

When you're planning for compromise, ensure that you understand what relying parties and systems depend on the PKI. That way, any changes that you introduce will cause minimal interruption.

Conclusion

If a PKI is properly implemented, it becomes a foundational component for building effective security controls for information systems. A PKI plays a critical role in the protection of sensitive business data and is an enabling technology that helps promote the security of electronic business and electronic commerce. No IT infrastructure is immune from attack. However, implementing appropriate policies, procedures, and technical controls can limit the extent of a compromise and help keep critical systems, such as a PKI, protected.

This article is a brief look at Microsoft IT’s best practices which are fully explained here: " Securing Public Key Infrastructure (PKI)"

For more information:

http://aka.ms/securingpkidl.

http://www.microsoft.com

http://www.microsoft.com/microsoft-IT

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Order Centre at (800) 933-4750. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:

© 2014 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY