The road for FedRAMP high is a tough one, there are 421 controls that must be met. Without the right technology and procedures meeting these controls might seem overwhelming. To achieve FedRAMP compliance we recommend breaking down the requirements into multiple smaller bite size problems that your organization needs to address. In this blog we will focus on the FedRAMP requirements with regards to PKI and certificate management.
| Control ID | Control Name | Description | TL;DR |
|---|---|---|---|
| CM-03 (06) | Configuration Change Control | Cryptography Management | Ensure that cryptographic mechanisms used to provide the following controls are under configuration management: [Assignment: organization-defined controls]. | You have to have a system for managing certificate lifecycle (creation, renovation, and revocation). This includes having a system to monitor certificate expiration and ensure that certificates are rotated before expiration. |
| CM-14 | Signed Components | Prevent the installation of [Assignment: organization-defined software and firmware components] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization. | Make sure that your systems only run code signed by a trusted certificate. (This might include having to create a process to sign internal tools). |
| IA-5 | Authenticator Management | Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time password devices, and ID badges. Device authenticators include certificates and passwords. Initial authenticator content is the actual content of the authenticator (e.g., the initial password). In contrast, the requirements for authenticator content contain specific criteria or characteristics (e.g., minimum password length). Developers may deliver system components with factory default authentication credentials (i.e., passwords) to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant risk. The requirement to protect individual authenticators may be implemented via control PL-4 or PS-6 for authenticators in the possession of individuals and by controls AC-3, AC-6, and SC-28 for authenticators stored in organizational systems, including passwords stored in hashed or encrypted formats or files containing encrypted or hashed passwords accessible with administrator privileges. | This is the authentication policy, it requires strong authentication, the easiest way to meet the requirement is using certificates for all authentication PIV smartcards for users, and certificates for machines. Having a good system to distribute both human and computer certificates remove a lot of complexities on IA-5. We have more details on a future blog where we dive in to the authentication requirements for FedRAMP high. |
| IA-5 (2) | Authenticator Management | Public Key-based Authentication | For public key-based authentication:
a. Enforce authorized access to the corresponding private key; and b. Map the authenticated identity to the account of the individual or group; and When public key infrastructure (PKI) is used: Validate certificates by constructing and verifying a certification path to an accepted trust anchor, including checking certificate status information; and Implement a local cache of revocation data to support path discovery and validation. |
You must use certificate authentication best practices to authenticate certificates. Our CEO did a great video on certificate authentication best practices. |
| SC-12 | Cryptographic Key Establishment and Management | Establish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction]. | Key management procedures must be employed to meet government requirements. This goes from the key management of the certificates, using NIST approved cryptographic algorithms (At the time of writing RSA 4096 or higher for asymmetric and AES 256 for symmetric); as well as the management of trust stores ensuring that your systems only trust trusted Certificated Authorities. |
| SC-17 | Public Key Infrastructure Certificates | a. Issue public key certificates under an [Assignment: organization-defined certificate policy] or obtain public key certificates from an approved service provider; and
b. Include only approved trust anchors in trust stores or certificate stores managed by the organization. |
You must have a certificate policy and your must issue certificates meeting your CP. Only certificates issued by a CA managed by your organization must be trusted. |
| SI-7 (15) | Software, Firmware, and Information Integrity | Code Authentication | Implement cryptographic mechanisms to authenticate the following software or firmware components prior to installation: [Assignment: organization-defined software or firmware components]. | You must have cryptographic validation of your software. This is related to CM-14. |
While all these controls can be implemented with ADCS and many manual controls with a heavy reliance on Excel spreadsheets and ticketing systems, there are certificate management tools that can help you automate most of this. EZCA was created by a team of ex-Microsoft and ex-Google engineers to help you meet and exceed compliance requirements. While EZCA is a SaaS offering, it can be deployed in your own Azure subscription (In Azure Public, or Azure Gov) allowing you to have full control over your infrastructure and procedures while still being easy to manage (trust us we run hundreds of instances).
While EZCA can connect to HSMs (either local HSMs or cloud HSMs, and even Key vaults) we understand that you might already have an ADCS up and running and prefer keeping it. That is no issue we can connect to an existing ADCS Certificate Authority and modernize the certificate issuance process with all the features EZCA offers.
If you are looking at issuing certificates through Intune, EZCA makes the whole process easier, gone are the days where you need an NDES server with an Intune connector. EZCA Automatically connects to Intune and issues the certificates, and if you decommission a device? Don’t worry Intune contacts EZCA and we automatically revoke the certificate.
Managing your private PKI and private certificates is great, but most strict compliance frameworks such as FedRAMP don’t stop at private certificates, they also require the same level of management for public certificates, this is why our customers asked us to create the same experience for the public certificates.
In this article we have focused on organization wise certificate management but if you are looking at FedRAMP high you are probably also thinking about SmartCard authentication (And probably scared of it because last time you implemented it it was a pain). But we have also thought about that, EZCA can be paired with EZCMS our smartcard management and provisioning service making smartcard assignment and management as simple as possible.
