How can security frameworks and audits improve key and certificate security?
Learn how security frameworks can provide guidance in developing machine identity security programs that secure keys and certificates while audits can be strategically leveraged to continuously improve these programs.
What causes SSL/TLS security risks?
The two biggest risks of poor TLS certificate management are: 1) unauthorized users or machines gain access to sensitive information, networks, systems, or applications and 2) downtime and system outages.
Information security risks to SSL/TLS certificates and private keys are often created because of other factors, including:
Weak cryptographic key lengths enable keys to be derived, or guessed, by attackers. Weak key lengths are like weak passwords that can be guessed.
- Weak cryptographic algorithms enable attackers to counterfeit certificates and impersonate systems or users. Weak algorithms are also like a weak password that can be hacked.
- Long rotation periods, in which keys are not changed regularly, allow former employees computer/system access to secure systems, applications and data that they should not have access to. Long rotation periods for keys are like user passwords that are not changed regularly.
- Certificate authorities (CAs) are entities that issue SSL/TLS certificates. Compromised CAs enable attackers to counterfeit certificates. Counterfeit certificates are comparable to a set of house keys that were copied without oversight or approval. A private key compromise allows attackers to authenticate themselves as the owner of the private key. Private key compromise is similar to allowing access to passwords written on post-It notes.
What causes SSL/TLS operational risks?
Operational risks to SSL/TLS certificates and private keys are often created because of the following like causes:
- Expired certificates cause system outages. Every certificate has an expiration date after which the systems will no longer allow the certificate to authenticate the system or be used.
- Certificate authority (CA) compromises require operations to be stopped until all certificates from that compromised CA are revoked and replaced by an alternate CA. If an organization is not prepared to replace certificates in case of a CA compromise, it can take days or weeks to locate and replace all certificates, with critical services and operations unavailable during that time.
What private key controls can mitigate SSL/TLS risks?
To mitigate the risks identified above, the following controls regarding private keys and SSL certificates must be in place:
- Documented and communicated enterprise key and certificate management (EKCM) policies exist and are updated annually or as frequently as new risks warrant.
- An accurate, system-generated inventory of deployed SSL/TLS certificates and private keys is actively maintained for completeness. Regular verification scans are performed.
- The attributes of each certificate and private key are monitored to ensure it follows policy. This includes, at minimum, adherence to the following:
- Key lengths greater than the minimum size specified by NIST {security}
- Certificate signing algorithms in use are approved by NIST {security}
- Certificate validity periods (rotation periods) are 1 year unless specific exception is granted {security}
- Certificates and keys are replaced no less than 30 days prior to expiration to avoid unplanned downtime {availability}
- Only certificates from approved certificate authorities are in use {security}
- Private key management procedures exist and are updated regularly {security}
- Detailed logs of all certificate and key management operations are maintained, reviewed, and secured as part of audit processes.
- A documented CA compromise recovery plan exists and is updated regularly. The CA compromise recovery plan should be tested/simulated with all appropriate participants.
How to test security and audit compliance methodology?
EKCM policies and procedures are reviewed in detail for completeness and to ensure that audits cover all applicable areas. This includes a review of private key management procedures.
Procedures for maintaining a comprehensive system-generated inventory and attributes for all certificates and private keys in the inventory are reviewed in detail. Beware of inventories manually generated and maintained in a spreadsheet as these inventories can be suspect and incomplete. A statistically significant sample size of audit logs are reviewed based on randomly selected certificates and private keys; however the logs for the operations on those selected certificates and private keys are reviewed in detail. CA compromise preparation and response plans are also reviewed in detail for completeness.
What steps can I take to meet security standards?
1. Review corporate and business unit specific EKCM policies and processes to ensure they cover current best practices and standards. Policies should also define procedures for reviewing and remediating or approving exceptions. Policies should at a minimum include provisions for:
- Minimum key lengths (e.g., 2048-bits); should incorporate latest recommendations by NIST (SP 800-131a, which specifies minimal key lengths).
- Approved cryptographic algorithms; should incorporate latest recommendations by NIST (e.g., FIPS).
- Maximum certificate and private key validity (rotation) periods. Due to average administrative turnover rates, a one-year validity period is recommended.
- Identification of approved certificate authorities (CAs); including guidelines for selecting proper CA. Guidelines include the selection of an internal versus an external CA.
- Approved trusted root certificates which are used by systems to validate certificates.
- Certificate management policies; including:
- Enrollment procedures for new and renewed certificates which should also include required approvals.
- Registration authority procedures (due diligence procedures)
- Minimum renewal periods. Determine the number of days prior to certificate expiration that certificates are replaced to avoid in-service downtime).
- Private key management policies, including:
- Whether administrators can directly access private keys
- Allowed keystore types (software- versus hardware-based keystores)
- Separation of duties (e.g., separation between key custodians and application owners)
- Dual control (approval of operations)
- Logging requirements; to enable audit of all key management operations
- Roles and responsibilities of all stakeholders (application owners, key custodians, CA admins, etc.)
- Revocation checking is enabled and enforced on all systems that act as relying parties
Review communications and training procedures for EKCM policies to ensure that all critical stakeholders have the proper knowledge and tools.
2. Verify that an accurate inventory of all certificates and private keys, as well as trusted root certificates, is being maintained through the following steps:
- Network scans are performed periodically (frequency defined by corporate policy) on all network segments to ensure that all network-facing (server-side) certificates are discovered and accounted for.
- Onboard scans (e.g., checking file systems) are performed periodically (frequency defined by corporate policy) on all mission-critical systems to ensure that all client-side certificates are discovered and accounted for.
- Well-defined procedures are in place for the reliable registration of certificates and private key instances that cannot be discovered by network or onboard scanning.
- All locations for certificates and private keys are identified (the same certificate and private key can be copied to multiple locations, e.g., for load balancing environments).
- All owners or contacts are identified (with provisions for keeping ownership information up to date) so they can be contacted if needed (e.g., in case of a CA compromise).
- All relevant attributes of the certificates are collected as part of the inventory (e.g., key lengths, validity periods, etc.)
3. Review attributes for certificates and private keys in inventory to ensure they comply with corporate EKCM policies. Control values to check for production keys and certificates include:
- Key lengths are 2048-bits or greater
- Signing algorithms for certificates are SHA2 or stronger
- Certificate validity periods (the time between issue and expiration date) are equal to 1 year unless specific exception is granted by information security group for maximum of 3 years
- All certificates are not expiring in less than 30 days to avoid downtime via in-service expiration
- All certificates are issued by approved certificate authorities
- Wildcard certificates (certificate which can be used on a range of systems, such as *.abcd.com) are used only where required by operational constraints and requirements If out of compliance situations are identified, ensure that violating certificates and private keys are replaced as soon as possible and determine what procedural breakdowns occurred so they can be remedied.
4. Review private keys management procedures to ensure that:
- Administrators should not have direct access to private keys unless documented technical constraints require it (i.e., the technologies where the private keys are stored do not provide for private keys security and no alternative automated key management solutions exist to eliminate direct access)
- Private keys that have been directly accessed by administrators are replaced when those administrators are reassigned or leave the organization
- Strong credentials are being used for access to the keystores where private keys are stored
- Separation of duties are enforced (controlled via granular access controls)
- Dual control is enforced (controlled via workflow review and approvals)
- All management operations are logged to a secure audit log
5. For SSL certificates and private keys not subject to established production policies (i.e. test and development), validate that controls are in place to ensure these certificates and private keys are never moved into production domain.
6. Validate Documented policies and procedures are in place to prevent, prepare for, and respond to a CA compromise:
- Security and operations of internal certificate authorities is regularly audited, and appropriate audit documentation is provided from the external certificate authorities that are utilized.
- Backup certificate authorities are in place to enable rapid recovery from a CA compromise.
- For external CAs, it is recommended that active contractual relationships are maintained with more than one vendor. It is plausible to negotiate a contractual relationship with a new vendor while attempting to recover from a CA compromise. It is also a best practice
to use certificates from all vendors to ensure that a cutover from one CA to another is rapid. - For internal CAs, it is recommended that an alternate CA be activated but kept offline, for security purposes, until needed.
- Preparation and recovery plans for a CA compromise have been documented and communicated. These plans should include:
- Reliable procedures for rapidly replacing all certificates issued from each CA currently in use
- Reliable procedures for rapidly removing trusted root certificates from all applicable trust stores in case of a root CA compromise. Note, this must be applicable for CAs that are not directly in use by your organization since your systems and users rely on certificates from other companies.
- Technologies and processes for tracking and monitoring the progress of replacement operations so it is clear when all affected certificates and systems have been remediated
- Roles and responsibilities during a CA compromise response (e.g., situation assessment, communications, help desk, new key pair generation, RA, progress tracking and monitoring, etc.)
7. Evaluate the effectiveness of implemented EKCM controls, by reviewing performing a sanity check of implemented policies and controls against Effectiveness, Efficiency, Confidentiality, Integrity, Availability, Compliance, and Reliability. Also review audit logs of a sampling of certificate and private key management operations, ensuring dual control, separation of duties, no administrator access to private keys, timely replacement of keys, and other security related criteria meet the EKCM policy requirements.
Evidence: Provide appropriate screen shots, test results and graphical reports validating population size, management effectiveness and scan and validation results.
Learn more about machine identity security, and how it can benefit your organization!
