SC-17 Public Key Infrastructure Certificates (M) (H)

NIST 800-53 (r4) Control:

The organization issues public key certificates under an [Assignment: organization-defined certificate policy] or obtains public key certificates from an approved service provider.

NIST 800-53 (r4) Supplemental Guidance:

For all certificates, organizations manage information system trust stores to ensure only approved trust anchors are in the trust stores. This control addresses both certificates with visibility external to organizational information systems and certificates related to the internal operations of systems, for example, application-specific time services. Related control: SC-12. 

NIST 800-53 (r5) Discussion:

Public key infrastructure (PKI) certificates are certificates with visibility external to organizational systems and certificates related to the internal operations of systems, such as application-specific time services. In cryptographic systems with a hierarchical structure, a trust anchor is an authoritative source (i.e., a certificate authority) for which trust is assumed and not derived. A root certificate for a PKI system is an example of a trust anchor. A trust store or certificate store maintains a list of trusted root certificates. 

38North Guidance:

Meets Minimum Requirement:

• Establish a PKI certificate policy that specifies requirements for TLS implementations, PKI certificate usage and lifecycle management (e.g., request, generation, installation, revocation, private key management, etc.), approved Certificate Authorities, roles and responsibilities, etc.).

• Only request PKI certificates from trusted Certificate Authorities (e.g., VeriSign, DigiCert, Symantec, Entrust, Let's Encrypt, etc.). Verify that the digital signature of each procured certificate is traceable to a trusted root Certificate Authority.

  • FedRAMP has not approved any CAs, so up to CSP to determine which CA is trusted. Suggest reviewing CAs to see which meet security standards, and write in policy to standardize so services are going to the same approved CA.

• Do not use self-signed certificates for public-facing websites and applications.

Best Practice:

• Utilize X.509 Version 3 certificates.

• Certificates must only be used in accordance with key attributes as specified within the certificate.

• Issued certificates must identify allowed key operations.

• A new key pair must be created, and another certificate obtained when a certificate becomes invalid.

• Enforce Separation of Duties (SoD) for each certificate lifecycle management process (e.g., key generation, certificate request, certificate issuance, key storage/distribution/usage, certificate installation, certificate maintenance, etc.). For example, an individual should not possess permissions to generate a certificate key pair, request the certificate, and install the certificate.

Unofficial FedRAMP Guidance:

• FedRAMP does not maintain a list of approved Certificate Authorities. Consequently, selection of a "trusted" or "reputable" Certificate Authority is at the discretion of the CSP.

• CSPs can utilize an internal (i.e., private or managed by the CSP) Certificate Authority that issues self-signed certificates in support of internal system operations. Self-signed certificates are created, issued, and signed by the CSP, and should never be used for public-facing websites and applications.

  • UPDATE: FedRAMP and DISA no longer permit the use of self-signed certificates. NEED TO VALIDATE.

• Wildcard certificates (i.e., a certificate that is applied to a domain and all its subdomains) are acceptable for use in private subnets. Publicly exposed systems require their own certificates.

Assessment Evidence:

• Assessors will want to review system component trust or certificate stores.

• PKI policy documentation.

• Certificate Signing Requests (CSR).

• Evidence of an established certificate lifecycle management process (e.x., key generation, certificate expiration date monitoring, Jira tickets submitted for requesting and installing certificates, private key management (e.g., storage, access, etc.).

• Configuration settings depicting TLS implementations.

CSP Implementation Tips:

• Amazon Web Services (AWS): TBD

• Microsoft Azure: TBD

• Google Cloud Platform: TBD

• DoD:

  1. Useful Links:

     • DoD Cyber Exchange Portal - PKI

     • Working with External PKIs

     • Using Commercial PKI Certificates