Attack Surface
The Certification Authority role service is susceptible to the same security attacks as any CA. To identify the attack surface for this role service, you need to identify the:
Installed files. The files that are installed as part of the Certification Authority role service.
Running services. The services that run as part of the Certification Authority role service.
Note You can use the RootkitRevealer and Sigcheck utilities that are part of Windows Sysinternals to verify the integrity of the installed files and the files that the services run.
Firewall rules. The Windows Firewall rules that the Certification Authority role service uses.
Role dependencies. The dependencies for the Certification Authority role service.
The details of the attack surface for the Certification Authority role service are included in the Windows Server 2008 Attack Surface Reference workbook that accompanies this Solution Accelerator. To view the attack surface for this role service, on the AD CS tab of the workbook, view the sections that correspond to each of the items in the previous list.
Security Measures
This section describes the security measures that you can incorporate into your Certification Authority role service configuration to protect the server against malicious attacks. The recommendations that follow assume that you have only selected the Certification Authority role service option on the Select Role Services page of the Add Roles Wizard. Recommendations for other role services are not included.
The following table summarizes the recommended security configuration tasks for hardening servers performing the Certification Authority role service. If you need help to complete any of the checklist items, see the following sections in this chapter for additional details and recommendations.
Table 9.1 Configuration Checklist
|
Configuration tasks
|
|
Deploy an offline root certification authority (CA).
|
|
Protect CAs by using a hardware security module (HSM).
|
|
Deploy an offline policy CA.
|
|
Publish the certificates and CRLs in AD DS.
|
|
Deploy enterprise subordinate CAs.
|
|
Publish both CRLs and delta CRLs.
|
|
Limit the types of certificates that a CA can issue.
|
|
Implement role separation based on Common Criteria specifications.
|
|
Require multifactor authentication for users with PKI management roles.
|
|
Avoid placing policy OIDs and CDP or AIA certificate extensions in root certificates.
|
Note These recommendations are based on the assumption that your public key infrastructure (PKI) is based on the Rooted Trust Model.
Deploy an Offline Root CA
Although all CAs in a public key infrastructure (PKI) are sensitive, the root CA is the most sensitive because if it is compromised, the entire PKI can be compromised. The root CA is the single point of trust for an entire organization for several organizations.
Important In larger environments, subordinate policy CAs may play the same role as a root CA for different divisions or business units. Deploy these subordinate policy CAs as offline CAs.
To help prevent the root CA from being compromised, Microsoft recommends taking the following security measures:
Deploy the root CA as an offline, stand-alone CA. Deploy the root CA as an offline CA to help prevent network attacks. To deploy an offline root CA, you must deploy the CA as a stand-alone CA because offline enterprise CAs are not supported. For more information about deploying stand-alone CAs, see the following topics in the Help and Support for Windows Server 2008:
"Stand-alone Certification Authorities."
"Enterprise Certification Authorities."
"Install a Root Certification Authority."
Protect the computer that is the root CA. To further protect the root CA, implement one or more of the following security measures:
Store the offline CA computers in a physically secure room. Rather than storing offline CA computers in the standard server room, consider storing the offline CAs in a limited-access server room or in a safe. Allow only those with CA Administration roles to enter the server room or open the safe, and record all attempts to access the server room. Alternatively, you could enforce physical access logs, where any access to the CA computers is logged.
Store the CA computers in a secured cage. Certain models of server cages are available that require PIN codes to open. Some models even track all attempts to access the server cage and allow retrieval of the access logs via serial connections.
Store offline CA-related hardware in a separate, secured location. Some organizations remove the hard disk drives from the CA computers and store them in a remote safe, which requires an attacker to gain access to both the server computer and the hard disk drives before gaining access to an offline CA. This methodology allows companies to use the offline server computer for other uses when the CA is removed from the network.
Install the root CA in a virtual environment and store this virtual image in a separate, secured location. This is a variation of storing offline CA computers in a physically secure room. In this case, the offline CA computer is a virtual image instead of a physical computer.
Protect CAs by Using an HSM
Protect CAs, especially the root CA, using a hardware security module (HSM) with an HSM-operator hardware token to limit access to the CA private key. In addition to limiting access to the CA private key, most HSMs are also hardware cryptographic accelerators that provide better performance than a normal software-based cryptographic system. For more information about HSM, see "Set Up a Certification Authority by Using a Hardware Security Module" in the Help and Support for Windows Server 2008.
Deploy an Offline Policy CA
A policy CA is a type of intermediate CA that is typically used to separate classes of certificates that can be distinguished by policy. For example, policy separation includes the level of assurance that a CA provides or the geographical location of the CA to distinguish different end-entity populations. A policy CA can be online or offline.
Use secure procedures to publish the certificate and CRL of an offline CA. You only need to publish the certificate of the offline CA one time. However, the CRL for the offline CA must be published at regular intervals that correspond to the CRL publication interval value that is configured in the Revoked Certificates Properties of the offline CA.
If the offline CA is maintained in a secure location, such as a data center or vault, it is best if more than one administrator or trusted person publishes the offline CRL within that location, as prescribed in the certificate policy and certificate practice statements for your organization. After the CRL is published, you must transfer it manually from the data center or vault to a location where it can be distributed to your CRL distribution points.
Publish the offline CRL at least several days before the previously issued CRL is set to expire. This allows you to correct any hardware problems or publication failures in advance, ensuring that no interruption in service happens when your offline CRLs are published and replicated to all CRL Distribution Point (CDP) locations.
After the offline CA is installed, configure the various constraint and policy options for certificates that the offline CA issues. These extensions are necessary to ensure that the applications and clients that use the certificates in the hierarchy can perform revocation and chain building as needed.
Microsoft recommends deploying an offline policy CA by using the same recommendations listed in "Deploying an Offline Root CA" earlier in this chapter. The offline policy CA should be treated similarly to the root CA from a security perspective. However, the policy CA will be brought online more frequently than a root CA.
Publish Certificates and CRLs in AD DS
If your organization uses its PKI to provide certificates for domain users and computers, Microsoft recommends publishing certificates and CRLs in AD DS. AD DS provides a secured repository for certificates and CRLs. By default, the certificates and CRLs are accessed by using Lightweight Directory Access Protocol (LDAP). If the certificates and CRLs cannot be accessed by LDAP, then other methods are attempted if your PKI is configured to publish certificates and CRLs using other publishing methods, such as HTTP.
Both enterprise and stand-alone CAs can publish the certificates and CRLs to Active Directory. By default, enterprise CAs publish certificates and CRLs to the domain in which the CA is a member. You must manually publish certificates and CRLs to other domains and forests. You also must manually configure a stand-alone CA to publish certificates and CRLs in Active Directory.
To install a stand-alone CA so that it will publish its CA certificates and CLR to AD DS, you must be a member of the Domain Admins group of the parent domain in the enterprise, or an administrator with Write access to AD DS. For more information about how to publish a certificate or CRL to Active Directory on a stand-alone CA, see "To publish as certificate or CRL to Active Directory" in Certutil tasks for managing CRLs.
Deploy Enterprise Subordinate CAs
If your organization primarily uses its PKI in your intranet, deploy enterprise subordinate CAs because they automatically publish certificates and CRLs in AD DS. For more information about the advantages of publishing certificates and CRLs in AD DS, see the previous section "Publish Certificates and CRLs in AD DS" in this chapter.
For more information about deploying enterprise subordinate CAs, see the following topics in the Help and Support for Windows Server 2008:
"Enterprise Certification Authorities."
"Install a Subordinate Certification Authority."
Publish Both CRLs and Delta CRLs
CRLs can become very long on large CAs that have experienced significant amounts of certificate revocation. This can become a burden for client computers to download frequently. To help minimize frequent downloads of lengthy CRLs, you can publish delta CRLs. This allows client computers to download the most current delta CRL and combine that with the most current base CRL to maintain a complete list of revoked certificates. Because client computers normally store CRLs locally, using delta CRLs can potentially improve performance.
To use delta CRLs, the client application must be aware of and explicitly use delta CRLs for revocation checking. If the client computer does not use delta CRLs, it will retrieve the CRL from the CA every time it refreshes its cache, regardless of whether a delta CRL exists or not. For this reason, ensure to verify that the intended applications use delta CRLs and configure the CA accordingly. If the client computers do not support the use of delta CRLs, either do not configure the CA to publish delta CRLs or configure it so that CRLs and delta CRLs publish at the same interval. This allows new applications that support delta CRLs to use them, while providing current CRLs to all existing applications.
Note All applications that use CryptoAPI in Windows® XP, Windows Vista®, Windows Server® 2003, and Windows Server 2008 use delta CRLs.
Limit the Types of Certificate That a CA Can Issue
Deploy CAs that will issue a specific type of certificate. For example, if you need to issue certificates for smart card authentication or e-mail signing, deploy a CA dedicated to issuing smart card authentication certificates and another CA dedicated to issuing e-mail signing certificates. You can restrict the types of certificates that a CA may issue by using certificate templates. For more information about certificate templates, see Certificate Template Overview.
Implement Role Separation Based on Common Criteria Specifications
Role-based administration is used to organize CA administrators into separate, predefined task-based roles. Microsoft recommends distributing the management roles among several individuals in your organization to ensure that a single individual cannot compromise PKI services. Role separation enables one person to audit the actions of another person.
Important Limit the number of users that manage your CAs because CAs play a critical security role in a PKI.
Some Common Criteria PKI management roles include the following:
PKI Administrator. Configures and maintains the CA, designates other CA administrators and certificate managers, and renews CA certificates.
Certificate Manager. Approves or denies certificate enrollment requests and revokes issued certificates.
Backup Operator. Performs backups of the CA database, the CA configuration, and the CA’s private and public key pair (also known as a key pair).
Audit Manager. Defines what events are audited for Certificate Services and reviews the security log in Windows Server 2003 for success and failure audit events that are related to Certificate Services.
Key Recovery Manager. Requests retrieval of a private key stored by the service.
Enrollee. Requests certificates from the CA.
For more information about implementing role separation based on Common Criteria specifications, see Defining PKI Management and Delegation.
Require Multifactor Authentication for Users with PKI Management Roles
Human authentication factors are generally classified into the following cases:
The user knows specific information, such as a password, pass phrase, or personal identification number (PIN).
The user has a specific device, such as a smart card, security token, software token, phone, or cell phone.
The user provides a human attribute through an action, such as a fingerprint or retinal pattern, DNA sequence, signature or voice recognition, unique bio-electric signals, or another biometric identifier.
Often organizations use a combination of these methods. For example, a debit card and a PIN, which is also known as two-factor authentication.
You can use multifactor authentication to enhance the level of authentication in your organization, compared to only requiring users to provide a password. Multifactor authentication typically includes a physical device, such as a smart card reader, USB security token, or fingerprint reader. Selecting physical devices for multifactor authentication is based on nonsecurity related requirements.
For example, your organization could require smart cards for users that include picture identification, as you can print a picture and a name on the smart card. However, a smart card requires a reader, which may introduce additional costs. A USB token can include flash memory for storing documents and files, and users can plug a USB token into existing USB ports on their computers.
This form of security is recommended for accounts with PKI management roles. Specifically, require multifactor authentication for users who perform the following PKI management roles:
PKI Administrator
Certificate Manager
Backup Operator
Audit Manager
Key Recovery Manager
Note If possible, use multifactor authentication throughout the organization to ensure that the strongest possible passwords are required for user accounts. Using multifactor authentication causes the system to automatically generate cryptographically strong random passwords for accounts.
Avoid Placing Policy OIDs and CDP or AIA Certificate Extensions in Root Certificates
As a best practice, Microsoft recommends to avoid placing policy object identifiers (OIDs) in root certificates. By definition, a root CA implements all policies. This applies to both Enterprise and Stand-alone CAs.
At some point in the hierarchy, a CA can have one or more policies defined. When a CA certificate is encountered with any policy OIDs, all certificates below that CA in the hierarchy must also have a subset of those policy OIDs. A certificate chain with no valid policy set will be considered invalid, whereas one with no policy OIDs at all will be considered valid and match the "any policy" OID. This is valid only for Application Policies and not Issuance Polices. For issuance policy, the absence of the certificatePolicies extension in a nonroot certificate implies no issuance policy.
In addition, avoid placing the CRL Distribution Point (CDP) and Authority Information Access (AIA) extensions in root certificates because some applications do not check for root CA revocation.
|
