Securing PKI: Monitoring Public Key Infrastructure

Article
08/31/2016

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

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 is vital to collect the right information and have appropriate alerting configured and review processes defined so that if there is an issue, it can be properly investigated. CAs must be treated as a high value systems and be monitored closely for suspicious activity.

A security logging and monitoring plan for a traditional line of business application will typically include watching specific logs for indicators of suspicious activity. While this is a vital part of PKI logging and monitoring, there are more aspects to consider. If operating offline CAs, also monitor the physical access to the offline CAs, and create a process for reviewing logical access to those systems. You must also monitor and review physical access for all online systems, including RAs and CAs.

The events discussed in this section will assist you in creating a security monitoring plan for PKI. Monitoring PKI for operational issues is not considered in this paper. The recommendations are strictly for determining malicious or suspicious activity related to the PKI.

Monitoring Events

An event is defined as any activity recorded to provide a detailed history of actions that have taken place. Some events may be tracked electronically within the system, while others may be tracked via manual paper-based processes. Any event collected, electronic or otherwise, should contain the following information:

Type of event
Date and time of the occurrence of the event
Identity that logged the event
Success or failure where appropriate
Description of the event

Regardless of the technology being used to generate or collect alerts, it is vital to have a process in place that engages the correct support teams if events indicate a security incident has occurred or will occur. Events that generate a security alert should contain the following:

High likelihood that occurrence of the event indicates unauthorized activity
Low number of false positives
Result in an investigative/forensics response

Two types of events should trigger security alerts:

Events in which even a single occurrence indicates unauthorized activity
An accumulation of events above an expected and accepted baseline

An example of the first type of event occurs if a user not authorized for interactive logon on a CA registers a logon event. An example of the second type of event is multiple failed access attempts from a user, which could be a sign of a brute force password guessing attack.

For electronically collected events, develop a plan for continued storage of collected event data and retention of the events. Consider using tools such as Windows Event Forwarding® (WEF) to aggregate events on a separate system for analysis and long term storage. For events recorded through manual processes, establish processes for archiving and reviewing event logs for abnormalities at regular intervals.

Monitoring Active Directory Objects and Attributes

The following are important Active Directory® items to monitor in order to detect compromise of AD CS based PKI:

Changes to critical groups that control access to the CA. This would include any custom groups containing users with elevated rights in the PKI to manage CAs, RAs, or enroll for important certificate types
Changes in membership to the “Cert Publishers” domain local group(s)
Changes to accounts that have privileged access to the PKI. Monitor for changes to attributes on the Account tab (cn, name, sAMAccountName, userPrincipalName, or userAccountControl). When using additional software packages that act as a RA to a CA, include the service accounts used by these systems in this list.
Unauthorized changes to certificate templates (Refer to Monitoring Changes to Certificate Templates)

Monitoring Certification Authority Activity

Because a CA is a high-value system, monitor it closely for abnormal activity. The events to monitor closely can be broken down into two major categories:

Events to watch for on any high value system
Events that are specific to the AD CS CA role

Below are some of the activities that should be monitored to help detect compromise of an AD CS based PKI:

General Events

Successful and failed logons
Addition, removal, or deletion of user accounts
Changes to membership in the local administrators group
Usage of the built-in administrator account
Changes to system time outside a defined threshold (changes greater than ten minutes)
Abnormal startup or shutdown events
Clearing of event logs
Disabling or modification of antivirus and antimalware software
Antivirus or antimalware action taken (quarantine, etc.)
Installation of new services
Unknown processes starting or stopping

CA-specific activity

Unauthorized changes to CA security settings
Revocation of a significant number of certificates during a short time period
Changes to the audit filter settings for the CA
Issuance of certificates that contain restricted usages (Enrollment Agent, Key Recovery Agent)
Changes to the active Policy Module on the CA
Changes to the configured Key Recovery Agents
Changes to role separation settings if role separation is enabled
Addition of certificate templates that are not normally issued by the CA
Addition or deletion of certificates from the CA database
Usage of the CA private key outside of certsrv.exe (certutil.exe, custom executables or scripts)
Suspicious use of accounts belonging to registration authorities. For example, if a smart card management system uses a specific service account to request certificates from the CA and that account makes certificate requests from systems that are not part of the smart card management system.

Recording and Reviewing Additional Events

In addition to monitoring CAs that are online and issuing certificates, it is also important to record and review other events that may impact PKI security. These events may not be captured electronically, but may rely on paper-based logs and require periodic review for anomalies. Below are some recommendations for additional activities to record and review:

Entry and exit to the secure area where PKI hardware is stored or operated. This could include access to the secure CA cage, access to the server room where the CAs are located, review of camera footage, etc.
Access to Hardware Security Modules (HSMs) and any tokens used to activate the HSMs. This includes any transportation of HSMs or tokens when they are physically moved.
Firewall/router activities that may indicate compromise
Access to any secure storage locations containing PKI backups or sensitive data. Examples include access logs for a safe, access records to a document archive facility, etc.

Configuring Microsoft Windows Audit Policy

In order to take full advantage of the auditing capabilities available in AD CS, you should configure an appropriate Microsoft Windows® audit policy for all of the events logged. Beginning with Microsoft Windows Vista® and Microsoft Windows Server 2008®, Microsoft improved the way event log category selections are made by creating subcategories under each main audit category. Subcategories allow auditing to be far more granular than it could be otherwise by using the main categories. By using subcategories, portions of a particular main category can be enabled, and events for which there is no need can be eliminated. Each audit policy subcategory can be enabled for Success, Failure, or Success and Failure events.

For a complete description of Microsoft Windows® audit policies and subcategories, refer to Best Practices for Securing Active Directory. To see the current audit policy for a system, type the following at the Command Prompt:

auditpol /get /category:*

The following screenshot represents an audit policy status.

In order for AD CS to log all configured events, the audit policy must have the “Audit Certification Services” subcategory configured for success and failure. To configure this using auditpol.exe, type the following at the Command Prompt:

auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

While audit policy can be configured per computer using auditpol.exe, a preferable method for domain-joined CAs is to apply a common audit policy as appropriate and configure it using group policy. To set audit policy using group policies, configure the “Certification Services” subcategory under Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy. Set the subcategory to be enabled for Success and Failure. See the screenshot below.

Command Line Process Auditing

Beginning with Windows Server 2012 R2®, additional data containing command line information can be collected when you are auditing for process creation events. This data includes the exact command used to launch a process, including command line parameters. More information on configuring command line process auditing can be found here.

Configuring Certification Authority Auditing

The CA role in Active Directory® Certificate Services includes two main sources of events:

Microsoft-Windows-CertificationAuthority – Contains operational and installation events related to the CA. Object access auditing is not required for these events to be written to the Application log.
Microsoft-Windows-Security-Auditing – Contains numerous events related to the security and configuration of the CA. Object access auditing must be configured for Certification Services and an appropriate CA audit filter must be configured.

The CA audit filter is a bitmask value stored in the registry of the CA. Refer to Securing PKI: Appendix B: Certification Authority Audit Filter for details on each individual value and which flags are required to trigger specific audit events. As shown in the following screenshot taken from the Properties dialog box of the CA, there are seven categories available for auditing:

Back up and restore the CA database – Controls logging of events triggered when the CA database is issued backup or restore commands
Change CA configuration – Controls logging of events related to the changing of properties and configuration of the CA through the CA snap-in. Example events logged are changing CRL validity periods, changing policy or exit module configuration, or updating configured CDP/AIA extensions.
Change CA security settings – Controls logging of events triggered by modification of the CA security settings done through the CA snap-in. Example events include enabling/disabling role separation, changing the audit filter, or changing the access control list for the CA.
Issue and manage certificate requests – Controls logging of events related to the issuance of certificates. This includes logging when a request is received, or set to pending, denied, and issued. In high volume issuance environments this can generate a large number of alerts, but it is a recommendation to enable it where possible because it provides a strong audit trail of all issuance events.
Revoke certificates and publish CRLs – Controls auditing of events related to revocation and publishing of CRLs.
Store and retrieve archived keys – Controls auditing of events related to the CA archiving keys or recovering previously archived keys. This includes when a key is imported into the CA database and archived.
Start and stop Active Directory Certificate Services – Controls creation of audit events whenever AD CS is started and stopped. A similar event is also logged to the application log, although enabling of this event writes an event to the security log. If enabled, a cryptographic hash of the CA database is taken on startup and shutdown of the CA service. When the database becomes large, this may begin to impact service availability, as the RPC interface for the CA is not available while the hash is being computed. The start and stop times of the service may be very long depending on the size of the database.

Advanced CA Monitoring

Although enabling auditing for AD CS provides a solid foundation for capturing events that occur within the scope of the CA service, additional events can occur on the CA that may indicate a compromise or a potential compromise. These additional events are useful to capture in addition to the CA audit events.

Auditing CA Registry Changes

Several of the CA auditing categories capture events triggered when a user changes a configuration setting within the CA snap-in. Several methods exist to change many of the settings on a CA. For example, to change the validity period of CRLs signed by the CA from one week to two weeks, you can utilize the CA snap-in as illustrated in the screenshot below.

Another method to perform the same task involves using certutil.exe with the following commands:

certutil –setreg CA\CRLPeriod Weeks

certutil –setreg CA\CRLPeriodUnits 2

Yet another method involves using regedit.exe:

With an audit filter configured to capture this event, the only method that will trigger an alert is making the change through the snap-in. To capture changes to all AD CS configuration settings stored locally on the CA, configure the registry auditing specifically for the AD CS registry keys. Configuring registry auditing at a broad level is not recommended because it can generate a very large number of alerts.

To enable registry auditing, configure the Microsoft Windows® auditing policy. This can be accomplished with auditpol.exe or through local or group policy.

To enable registry auditing with auditpol.exe, use the following settings:

auditpol /set /subcategory:"Registry" /success:enable /failure:enable

To set audit policy using group policies, configure the “Audit Registry” subcategory under Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy. Set the subcategory to be enabled for success and failure.

After enabling registry auditing, configure auditing for the Certification Services registry keys. To configure auditing for the AD CS CA registry key:

Open regedit, and navigate to HKLM\System\Services\CertSvc\Configuration\
Right-click the Configuration registry key and click Permissions…
Click Advanced.
Click Auditing.
Click Select a principal and select Authenticated Users. From the drop down menus, for Type select All and for Applies To, select This key and subkeys.
Click Show advanced permissions and select the values shown below.

For specific registry values to watch, refer to Securing PKI: Appendix A: Events to Monitor. For more information on configuring registry auditing, refer to How to use Group Policy to audit registry keys in Windows Server 2003.

Monitoring Changes to Certificate Templates

Certificate templates are Active Directory® objects that define key attributes of certificates issued by an Enterprise CA. Standalone CAs do not use certificate templates. Instead they rely on information provided in certificate requests and provided by certificate managers to determine certificate content. An Enterprise CA uses the information in certificate templates to determine who has permissions to enroll and what usages an issued certificate should be valid for. If an attacker has the ability to modify a Certificate Template in Active Directory®, they could potentially add additional usages or change enrollment permissions that could lead to the issuance of certificates that allow additional access.

AD CS includes several audit events that allow monitoring of changes to certificate templates that are actively being used by a CA. The following audit events are available:

Certificate Services loaded a template (Event ID 4898) – This event is triggered whenever a CA loads a template for the first time. For example, if a CA is configured with three templates, at startup this event will trigger for each template as it loads. If a fourth template is added while the CA is running, an event will be triggered on the first attempt to enroll the template on the CA.
A Certificate Services template was updated (Event ID 4899) – This event is triggered when a template loaded by the CA has an attribute updated and an enrollment is attempted for the template. For example, if an additional EKU is added to a template, this event would trigger and provide enough information to determine the change being made.
Certificate Services template security was updated (Event ID 4900) – This event is triggered when security permissions on a Certificate Template loaded on a CA are changed, and an enrollment event for the template occurs.

For the template change events to be recorded, configure the CA for auditing of CA events as described in Configuring Microsoft Windows Audit Policy and Configuring Certification Authority Auditing. In addition, enable the CA audit setting for “Change CA settings”, and enable a specific policy configuration. To set the policy configuration to enable audit of template events, run the following command:

certutil –setreg policy\EditFlags +EDITF_AUDITCERTTEMPLATELOAD

Certificate Template Scenarios to Monitor

When auditing templates, consider the following scenarios for monitoring:

Changes to templates that add new EKUs (Code Signing, Enrollment Agent, Smart Card Logon, etc.)
Addition of unexpected new templates on the CA
Changes to permissions for enrollment
Changes to permissions for write access to a template
Assignment of new templates that allow “supply in request” to build the subject

Conclusion

Implementing monitoring and alerting for PKI systems is a strong detective control, and can help limit the extent of damage caused by an attack or identify an attack before it succeeds. Monitoring will help you identify unauthorized changes to the environment that may allow certificates to be issued to unauthorized users or contain unexpected usages.

For a complete list of the recommendations for monitoring PKI, 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.

Share via