What changed in HPE Aruba Networking AOS NDM STIG V1R2V1R2 changes

Discussion

Successful identification and authentication must not automatically give an entity full access to a network device or security domain. The lack of authorization-based access control could result in the immediate compromise and unauthorized access to sensitive information. All DODDoW systems must be properly configured to incorporate access control methods that do not rely solely on authentication for authorized access. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset or set of resources. Information systems use access control policies and enforcement mechanisms to implement this requirement. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Some network devices are preconfigured with security groups. Other network devices enable operators to create custom security groups with custom permissions. For example, an information system security manager (ISSM) may require read-only access to audit the network device. Operators may create an audit security group, define permissions and access levels for members of the group, and then assign the ISSM's user persona to the audit security group. This is still considered privileged access, but the ISSM's security group is more restrictive than the network administrator's security group. Network devices that rely on authentication, authorization, and accounting (AAA) brokers for authentication and authorization services may need to identify the available security groups or access levels available on the network devices and convey that information to the AAA operator. Once the AAA broker identifies the user persona on the centralized directory service, the user's security group memberships can be retrieved. The AAA operator may need to create a mapping that links target security groups from the directory service to the appropriate security groups or access levels on the network device. Once these mappings are configured, authorizations can happen dynamically based on each user's directory service group membership.

V-266909 in V1R2

Title

AOS must display the Standard Mandatory DODoW Notice and Consent Banner before granting access to the device.

Check text

Verify the AOS configuration with the following command: show banner If the Standard Mandatory DODoW Notice and Consent Banner is not set, this is a finding.

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-266912 in V1R2

Title

AOS must retain the Standard Mandatory DODDoW Notice and Consent Banner on the screen until the administrator acknowledges the usage conditions and takes explicit actions to log on for further access.

Discussion

The banner must be acknowledged by the administrator prior to the device allowing the administrator access to the network device. This provides assurance that the administrator has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the administrator, DODDoW will not be in compliance with system use notifications required by law. To establish acceptance of the network administration policy, a click-through banner at management session logon is required. The device must prevent further activity until the administrator executes a positive action to manifest agreement. In the case of command line interface (CLI) access using a terminal client, entering the username and password when the banner is presented is considered an explicit action of acknowledgement. Entering the username, viewing the banner, and then entering the password is also acceptable.

V-266913 in V1R2

Title

AOS must be configured to use DODoW public key infrastructure (PKI) as multifactor authentication (MFA) for interactive logins.

Fix text

Configure AOS using the web interface: 1. Navigate to Configuration >> System >> Admin and expand "Admin Authentication Servers". 2. Click on the plus sign (+) under "All Servers" and configure the type of authentication server. Provide the Name, Type, and IP address. Click "Submit". 3. Select the created authentication server and configure the required attributes for LDAP: Admin-dn &ltusername> Admin-passwd &ltpassword> Re-type admin-passwd &ltpassword> Auth port: 636 Base-dn: cn/ou=&ltcontainer>,dc=&ltlevel>,dc=&ltmil> Key-attribute: userPrincipalName 4. Click "Submit." 5. Repeat this process and configure a second authentication server. 6. Click "Pending Changes" and then "Deploy changes". 7. Click on the plus sign (+) under "Server Groups" and add a server group. 8. Click "Submit". 9. Select the created server group and click the plus sign (+) in the Server Group &ltserver group name> box. 10. Add the first configured authentication server. 11. Reselect the created server group and click the plus sign (+) in the Server Group &ltserver group name> box. 12. Click Submit >> Pending Changes >> Deploy Changes. 13. Navigate to Management User. 14. Click on "Show users with certificate authentication". Click on the plus sign (+). 15. Configure each Trusted CA certificate name for any DODDoW Root CA that provides trust for admin users. 16. Select External server for the Authentication server. 17. Click Submit >> Pending Changes >> Deploy Changes. 18. Expand "Admin Authentication Options". Check "Enable" and "Client certificate". Select the Server group created earlier. 19. Click Submit >> Pending Changes >> Deploy Changes.

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 smart card 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 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 PKI is the only prescribed method approved for DODDoW organizations to implement MFA. For authentication purposes, centralized DODDoW certificate authorities (CA) 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 smart cards 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 smart cards, 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 a centralized authentication server (e.g., Authentication, Authorization, and Accounting [AAA], Remote Authentication Dial-In User Service [RADIUS], Lightweight Directory Access Protocol [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-000080-NDM-000220, SRG-APP-000153-NDM-000249, SRG-APP-000177-NDM-000263

V-266929 in V1R2

Title

AOS must be configured to use DODDoW-approved Online Certificate Status Protocol (OCSP) responders or Certificate Revocation Lists (CRLs) to validate certificates used for public key infrastructure (PKI)-based authentication.

Discussion

Once issued by a DODDoW certificate authority (CA), PKI certificates are typically valid for three years or less 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 that 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 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 CRLs. These are lists that 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 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. However, CRLs can be large in storage size, and the use of CRLs can tax some computing resources. Another method of validating certificate status is to use the OCSP. Using OCSP, a requestor (i.e., the network device 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 should 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-266938 in V1R2

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not validated and therefore cannot be relied on to provide confidentiality or integrity, and DODDoW data may be compromised. Network devices using encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2/140-3 is the current standard for validating that mechanisms used to access cryptographic modules use authentication that meets DODDoW requirements. However, authentication algorithms must configure security processes to use only authentication algorithms that are FIPS-approved and recommended by the National Institute of Standards and Technology (NIST). Satisfies: SRG-APP-000179-NDM-000265, SRG-APP-000224-NDM-000270, SRG-APP-000411-NDM-000330, SRG-APP-000412-NDM-000331

V-266940 in V1R2

Discussion

The loss of connectivity to a particular authoritative time source will result in the loss of time synchronization (free-run mode) and increasingly inaccurate time stamps on audit events and other functions. Multiple time sources provide redundancy by including a secondary source. Time synchronization is usually a hierarchy; clients synchronize time to a local source while that source synchronizes its time to a more accurate source. The network device must use an authoritative time server and/or be configured to use redundant authoritative time sources. This requirement is related to the comparison done in CCI-001891. DODDoW-approved solutions consist of a combination of a primary and secondary time source using a combination or multiple instances of the following: a time server designated for the appropriate DODDoW network (NIPRNet/SIPRNet); United States Naval Observatory (USNO) time servers; and/or the Global Positioning System (GPS). The secondary time source must be located in a different geographic region than the primary time source.

V-266953 in V1R2

Discussion

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. This requirement addresses the configuration of network devices to mitigate the impact of DoS attacks that have occurred or are ongoing on device availability. For each network device, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or restricting the number of sessions the device opens at one time). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks. The security safeguards cannot be defined at the DODDoW level because they vary according to the capabilities of the individual network devices and the security controls applied on the adjacent networks (for example, firewalls performing packet filtering to block DoS attacks).

V-266961 in V1R2

Fix text

Configure AOS with the following commands: crypto pki csr rsa key_len 2048 common_name &ltcommon_name> country &ltUS> state_or_province &ltstate> city &ltcity> organization &ltorg> unit &ltunit> email &ltemail> show crypto pki csr 1. Use DODDoW PKI to generate a public certificate based on the CSR. 2. Using the web GUI, navigate to Configuration >> System >> Certificates > Import Certificates. 3. Click the plus sign (+) and enter "Certificate name:", browse to the public certificate file, choose the appropriate format, select Certificate type: "ServerCert", and click "Submit". 4. Click Pending Changes >> Deploy Changes. 5. Navigate to Configuration >> System >> Admin >> Admin Authentication Options and choose the imported certificate under "Server Certificate". 6. Click Submit >> Pending Changes >> Deploy Changes.

V-266973 in V1R2