V-284542

Discussion

Once issued by a DoW certificate authority (CA), PKI certificates are typically valid for three years or fewer within the DoW. However, there are many reasons a certificate may become invalid before the prescribed expiration date. For example, an employee may leave or be terminated and still possess the smartcard on which the PKI certificates were stored. Another example is that a smartcard containing PKI certificates may become lost or stolen. A more serious issue could be that the CA or server which issued the PKI certificates has become compromised, thereby jeopardizing every certificate keypair that was issued by the CA. These examples of revocation use cases and many more can be researched further using internet cybersecurity resources. PKI user certificates presented as part of the identification and authentication criteria (e.g., DoW PKI as MFA) must be checked for validity by network devices. For example, valid PKI certificates are digitally signed by a trusted DoW CA. Additionally, valid PKI certificates are not expired, and valid certificates have not been revoked by a DoW CA. Network devices can verify the validity of PKI certificates by checking with an authoritative CA. One method of checking the status of PKI certificates is to query databases referred to as certificate revocation lists (CRL). These are lists which are published, updated, and maintained by authoritative DoW CAs. For example, once certificates are expired or revoked, issuing CAs place the certificates on a CRL. Organizations can download these lists periodically (i.e., daily or weekly) and store them locally on the devices themselves or even onto another nearby local enclave resource. Storing them locally ensures revocation status can be checked even if internet connectivity is severed at the enclave's point of presence (PoP). However, CRLs can be rather large in storage size and further, the use of CRLs can be rather taxing on some computing resources. Another method of validating certificate status is to use the online certificate status protocol (OCSP). Using OCSP, a requestor (i.e., the network device which the user is trying to authenticate to) sends a request to an authoritative CA challenging the validity of a certificate that has been presented for identification and authentication. The CA receives the request and sends a digitally signed response indicating the status of the user's certificate as valid, revoked, or unknown. Network devices must only allow access for responses that indicate the certificates presented by the user were considered valid by an approved DoW CA. OCSP is the preferred method because it is fast, provides the most current status, and is lightweight. Satisfies: SRG-APP-000149-NDM-000247, SRG-APP-000153-NDM-000249, SRG-APP-000910-NDM-000300

Check Content

Verify the admin realm is configured for certificate authentication.
1. In the Web UI, navigate to Administrators >> Admin Realms.
2. View the configuration for the admin realm used for administrator sign-in (this is called "Admin Users" by default).
3. Authentication: View the certificate authentication server name.
4. Verify the box for "Enable dynamic policy evaluation" is checked.
5. Verify the box for "Refresh roles" and "refresh resource policies" is checked.

Verify the certificate authentication server is configured to use DoW PKI.
1. Navigate to Administrators >> Auth. Servers.
2. Select Certificate from the list, then select the name of the certificate authentication server name that was used for the admin realm.
3. Verify the username template is set to <certAttr.altname.UPN>.

If Ivanti Policy Secure is not configured to use DoW PKI as MFA for admin logins, this is a finding.