What changed in F5 BIG-IP TMOS NDM STIG V1R3V1R3 changes

Title

The F5 BIG-IP appliance must be configured to display the Standard Mandatory DODoW Notice and Consent Banner upon access to the TMOS User Interface.

Discussion

Display of the DODDoW-approved use notification before granting access to the network device ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users.

V-266070 in V1R3

Discussion

Changes to any software components can have significant effects on the overall security of the network device. Verifying software components have been digitally signed using a certificate that is recognized and approved by the organization ensures the software has not been tampered with and has been provided by a trusted vendor. Accordingly, patches, service packs, or application components must be signed with a certificate recognized and approved by the organization. Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The device must not have to verify the software again. This requirement does not mandate DODDoW certificates for this purpose; however, the certificate used to verify the software must be from an approved certificate authority (CA).

V-266078 in V1R3

Fix text

From the BIG-IP GUI: RADIUS: 1. System. 2. Users. 3. Authentication. 4. If "User Directory" is configured for "Remote - RADIUS", click "Change" at the bottom. 5. Configure values for Primary and Secondary servers. Note: To view Primary and Secondary Hosts, the "Server Configuration" must be set to "Primary & Secondary". 6. Click "Finished". TACACS+: 1. System. 2. Users. 3. Authentication. 4. If "User Directory" is configured for "Remote - TACACS+", click "Change" at the bottom. 5. Add multiple IP Addresses to the "Servers" field. 6. Set "Authentication" to "Authenticate to each server until success". 7. Click "Finished". ClientCert LDAP: 1. System. 2. Users. 3. Authentication. 4. If "User Directory" is configured for "Remote - ClientCert LDAP", login to BIG-IP console. 5. Run the following command to add multiple servers: tmsh modify auth cert-ldap system-auth system-auth servers replace-all-with { SERVER1 SERVER2 } 6. Run the following command to save the configuration: tmsh save sys config

V-266079 in V1R3

Check text

From the BIG-IP GUI: 1. System. 2. Users. 3. Authentication. 4. Verify "User Directory" is configured to use one of the following options: Remote - ClientCert LDAP, Remote - RADIUS, or Remote - TACACS+. From the BIG-IP console, typeenter the following command (s): tmsh list auth source VerifyNote: "Userverify Directory"type" is configuredset to useone RADIUSof the following options: cert-ldap, radius, or TACACS+tacacs. If the BIG-IP appliance is not configured to use DODmultifactor PKIauthentication with(MFA) RADIUS or TACACS+ for interactive logins, this is a finding.

Fix text

From the BIG-IP GUI: 1. System. 2. Users. 3. Authentication. 4. Click "Change". 5. Select RADIUS,one orof TACACS+ from the "Remote" options and fill out the configuration depending on thewhich option is chosen. option Note: DoW sites must configure only the options for ClientCert LDAP, RADIUS, or TACACS+. 6. Fill out all other fields as appropriate for the environment. 7. Click "Finished". Note: This method has been verified with the vendor and DISA for use in DOD. Other methods are not recommended/have not been tested to determine if DOD requirements have been met or if additional licenses and AO approval are required.

Discussion

MFA is when two or more factors are used to confirm the identity of an individual who is requesting access to digital information resources. Valid factors include something the individual knows (e.g., username and password), something the individual has (e.g., a smartcard or token), or something the individual is (e.g., a fingerprint or biometric). Legacy information system environments only use a single factor for authentication, typically a username and password combination. Although two pieces of data are used in a username and password combination, this is still considered single factor because an attacker can obtain access simply by learning what the user knows. Common attacks against single-factor authentication are attacks on user passwords. These attacks include brute force password guessing, password spraying, and password credential stuffing. MFA, along with strong user account hygiene, helps mitigate the threat of having account passwords discovered by an attacker. Even in the event of a password compromise, with MFA implemented and required for interactive login, the attacker still needs to acquire something the user has or replicate a piece of the user’s biometric digital presence. Private industry recognizes and uses a wide variety of MFA solutions. However, DODDoW public key infrastructure (PKI) is the only prescribed method approved for DODDoW organizations to implement MFA. For authentication purposes, centralized DODDoW certificate authorities (CACAs) issue PKI certificate key pairs (public and private) to individuals using the prescribed x.509 format. The private certificates that have been generated by the issuing CA are downloaded and saved to smartcards which, within DODDoW, are referred to as common access cards (CAC) or personal identity verification (PIV) cards. This happens at designated DODDoW badge facilities. The CA maintains a record of the corresponding public keys for use with PKI-enabled environments. Privileged user smartcards, or "alternate tokens", function in the same manner, so this requirement applies to all interactive user sessions (authorized and privileged users). Note: This requirement is used in conjunction with the use of a centralized authentication server (e.g., AAA, RADIUS, LDAP), a separate but equally important requirement. The MFA configuration of this requirement provides identification and the first phase of authentication (the challenge and validated response, thereby confirming the PKI certificate that was presented by the user). The centralized authentication server will provide the second phase of authentication (the digital presence of the PKI ID as a valid user in the requested security domain) and authorization. The centralized authentication server will map validated PKI identities to valid user accounts and determine access levels for authenticated users based on security group membership and role. In cases where the centralized authentication server is not used by the network device for user authorization, the network device must map the authenticated identity to the user account for PKI-based authentication. Satisfies: SRG-APP-000149-NDM-000247, SRG-APP-000177-NDM-000263, SRG-APP-000153-NDM-000249

V-266085 in V1R3

Title

The F5 BIG-IP appliance must be configured to use DODoW approved OCSP responders or CRLs to validate certificates used for PKI-based authentication.

Check text

From the BIG-IP GUI: 1. System. 2. Users. 3. Authentication. 4. If "User Directory" is configured for "Remote - ClientCert LDAP", verify the "OCSP Responder" configured is DODDoW approved. Note: The OCSP Override option must be set to "on" to view the OCSP Responder value. If the BIG-IP appliance is not configured to use DODDoW-approved OCSP responders or CRLs to validate certificates used for PKI-based authentication, this is a finding.

Fix text

From the BIG-IP GUI: 1. System. 2. Users. 3. Authentication. 4. If ClientCert LDAP is used as the remote authentication type, click "Change". 6. Set "OCSP Responder" IP address to one that is DODDoW approved. Note: The OCSP Override option must be set to "on" to view the OCSP Responder value. 7. Click "Finish".

Discussion

Once issued by a DODDoW certificate authority (CA), public key infrastructure (PKI) certificates are typically valid for three years or shorter within the DODDoW. 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., DODDoW PKI as multifactor authentication [MFA]) must be checked for validity by network devices. For example, valid PKI certificates are digitally signed by a trusted DODDoW certificate authority (CA). Additionally, valid PKI certificates are not expired, and valid certificates have not been revoked by a DODDoW 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 DODDoW 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 DODDoW CA. OCSP is the preferred method because it is fast, provides the most current status, and is lightweight.

V-266094 in V1R3

Title

The F5 BIG-IP appliance must be configured to display the Standard Mandatory DODoW Notice and Consent Banner when accessing via SSH.

Discussion

Display of the DODDoW-approved use notification before granting access to the network device ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users.

V-266134 in V1R3