What changed in F5 NGINX STIG V1R2V1R2 changes

Discussion

Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. This requirement applies to Transport Layer Security (TLS) gateways (also known as Secure Sockets Layer [SSL] gateways), web servers, and web applications and is not applicable to virtual private network (VPN) devices. Application protocols such as HTTPS and DNSSEC use TLS as the underlying security protocol and thus are in scope for this requirement. NIST SP 800-52 provides guidance for client negotiation on either DODDoW-only or on public-facing servers. Satisfies: SRG-APP-000014, SRG-APP-000015, SRG-APP-000560, SRG-APP-000565

V-278381 in V1R2

Discussion

To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DODDoW-approved PKIs, all DODDoW systems (e.g., networks, web servers, and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions.

V-278382 in V1R2

Title

NGINX must display the Standard Mandatory DODoW Notice and Consent Banner before granting access to the application.

Check text

Note: The default NGINX configuration is "/etc/nginx/nginx.conf", though various files may also be included. Check nginx.conf for a section that verifies that user consent has been given. Setting a cookie upon user acceptance after reading the banner and checking for the presence of that cookie is one way to accomplish this. Check for this block in nginx.conf under the http block: # Define whether consent has been given based on the cookie map $http_cookie $consent_given { "~*user_consent=1" 1; default 0; } Check nginx.conf for a section that handles user consent and setting the cookie under the server block: # Serve the consent banner page if consent is not given location /consent { default_type text/html; return 200 "&lthtml>&ltbody> &lth1>Consent Required&lt/h1> &ltp>You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.&lt/p> &lta href='/set-consent'>I Accept&lt/a> &lt/body>&lt/html>"; } # Handle consent acceptance and set the cookie location /set-consent { add_header Set-Cookie "user_consent=1; Path=/; Max-Age=31536000; HttpOnly"; return 302 /; } location / { # Redirect users to the consent page if they haven't given consent if ($consent_given = 0) { return 302 /consent; } If NGINX is not configured to display the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the application, this is a finding.

Discussion

Display of the DODDoW-approved use notification before granting access to the application 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 and are not required when such human interfaces do not exist. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for applications that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't." Satisfies: SRG-APP-000068, SRG-APP-000069, SRG-APP-000070

V-278384 in V1R2

Title

NGINX must provide audit records for DODoW-defined auditable events.

Fix text

Determine the path to NGINX config file(s): nginx -qT | grep "# configuration" # configuration file /etc/nginx/nginx.conf: Note: The default NGINX configuration is "/etc/nginx/nginx.conf", though various files may also be included. Include the $server_name, $server_addr, $remote_addr, $remote_user, $time_local, $status, $request, $request_id, $http_user_agent, $http_x_forwarded_for, or any organization defined variable in any custom log_format directives. For example: log_format custom '$server_name ' ' $server_addr ' '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; Restart NGINX: nginx -s reload

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the application (e.g., process, module). Certain application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system can generating audit records. DODDoW has defined the list of events for which NGINX will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions. Satisfies: SRG-APP-000089, SRG-APP-000080, SRG-APP-000091, SRG-APP-000095, SRG-APP-000096, SRG-APP-000097, SRG-APP-000098, SRG-APP-000099, SRG-APP-000100, SRG-APP-000374, SRG-APP-000375, SRG-APP-000492, SRG-APP-000493, SRG-APP-000494, SRG-APP-000495, SRG-APP-000496, SRG-APP-000497, SRG-APP-000498, SRG-APP-000499, SRG-APP-000500, SRG-APP-000501, SRG-APP-000502, SRG-APP-000507

V-278385 in V1R2

Discussion

A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. Anti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is ensured. Using DODDoW PKI is inherently compliant with this requirement for user and device access. Using Transport Layer Security (TLS), including application protocols such as HTTPS and DNSSEC, is also compliant. Configure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method.

V-278390 in V1R2

Discussion

Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. To meet this requirement, the information system must create trusted channels between itself and remote trusted authorized IT product (e.g., syslog server) entities that protect the confidentiality and integrity of communications. The information system must create trusted paths between itself and remote administrators and users that protect the confidentiality and integrity of communications. A trust anchor is an authoritative entity represented via a public key and associated data. It is most often used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. However, applications that do not use a trusted path are not approved for nonlocal and remote management of DODDoW information systems. Use of SSHv2 to establish a trusted channel is approved. Use of FTP, TELNET, HTTP, and SNMPV1 is not approved since they violate the trusted channel rule set. Use of web management tools that are not validated by common criteria may also violate trusted channel rule set. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement. Satisfies: SRG-APP-000175, SRG-APP-000401

V-278391 in V1R2

Discussion

Decisions regarding the employment of mobile code within applications are based on the potential for the code to cause damage to the system if used maliciously. Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. DODDoW has identified prohibited mobile code in DODI 8552.01 as: all Category 1X mobile code, unsigned Category 1A mobile code, Category 2 mobile code that violates usage requirements, all Emerging Technologies mobile code (all mobile code technologies, systems, platforms, or languages whose capabilities and threat level have not yet undergone a risk assessment and been assigned to a risk category), and all mobile code that downloads via an email body or email attachment that executes automatically when the user opens the email body or attachment. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed, downloaded, or executed on all endpoints (e.g., servers, workstations, and smart phones). This requirement applies to applications that execute, evaluate, or otherwise process mobile code (e.g., web applications, browsers, and antivirus applications). Satisfies: SRG-APP-000206, SRG-APP-000207, SRG-APP-000209, SRG-APP-000210

V-278393 in V1R2

Discussion

Without reauthentication, users may access resources or perform tasks for which they do not have authorization. When applications provide the capability to change security roles or escalate the functional capability of the application, it is critical the user reauthenticate. In addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of individuals and/or devices in other situations, including (but not limited to) the following circumstances. (i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) When the execution of privileged functions occurs; (v) After a fixed period of time; or (vi) Periodically. Within the DODDoW, the minimum circumstances requiring reauthentication are privilege escalation and role changes.

V-278399 in V1R2

Discussion

Using PIV credentials facilitates standardization and reduces the risk of unauthorized access. DODDoW has mandated using the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems. Satisfies: SRG-APP-000391, SRG-APP-000392, SRG-APP-000402, SRG-APP-000403

V-278400 in V1R2

Title

NGINX must only allow using DOD oW-approved certificate authorities for PKI.

Check text

Determine the path to NGINX config file(s): # nginx -qT | grep "# configuration" # configuration file /etc/nginx/nginx.conf: Note: The default NGINX configuration is "/etc/nginx/nginx.conf", though various files may also be included. Find any "ssl_certificate" ssl_client_certificate" directives and verify they are DODDoW approved. If the certificates are not DODDoW approved, this is a finding.

Fix text

Replace any non-DODoW issued certificates with DODoW-issued certificates. After replacing the certificates, reload NGINX: # nginx -s reload

Discussion

Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DODDoW systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DODDoW-approved CA, trust of this CA has not been established. The DODDoW will only accept PKI certificates obtained from a DODDoW-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, using TLS certificates. This requirement focuses on communications protection for the application session rather than for the network packet. This requirement applies to applications that use communications sessions. This includes, but is not limited to, web-based applications and service-oriented architectures (SOAs). Satisfies: SRG-APP-000427, SRG-APP-000177, SRG-APP-000910

V-278403 in V1R2