What changed in Tri-Lab Operating System Stack (TOSS) 4 STIG V2R7V2R7 changes

Title

TOSS must display the Standard Mandatory DoDDoW Notice and Consent Banner or equivalent USU.S. Government Agency Notice and Consent Banner before granting local or remote access to the system.

Check text

Verify TOSS displays the Standard Mandatory DoDDoW Notice and Consent Banner or equivalent USU.S. Government Agency Notice and Consent Banner before granting access to the system. Check that TOSS displays a banner at the command line login screen with the following command: $ sudo cat /etc/issue "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." If the system has a graphical logon capability and does not display a graphical logon banner, this is a finding. If the text in the file does not match the Standard Mandatory DoDDoW Notice and Consent Banner or equivalent USU.S. Government Agency Notice and Consent Banner, this is a finding.

Fix text

Configure TOSS to display the Standard Mandatory DoDDoW Notice and Consent Banner or equivalent USU.S. Government Agency Notice and Consent Banner before granting access to the system. The banner must be formatted in accordance with applicable DoDDoW or other USU.S. Government Agency policy. Edit the "/etc/issue" file to replace the default text with the Standard Mandatory DoDDoW Notice and Consent Banner or equivalent USU.S. Government Agency Notice and Consent Banner. The DoDDoW-required text is: "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.

Discussion

Display of a standardized and approved use notification before granting access to the operating system 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 applicable DoDDoW or other USU.S. Government Agency policy. Use the following verbiage for operating systems 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."

V-252911 in V2R7

Check text

Verify TOSS for PKI-based authentication has valid certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Check that the system has a valid DOD root CA installed with the following command: Note: If the system does not support PKI authentication, this requirement is Not Applicable. $ sudo openssl x509 -text -in /etc/sssd/pki/sssd_auth_ca_db.pem Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = U.S. Government, OU = DODDoW, OU = PKI, CN = DOD Root CA 3 Validity Not Before: Mar 20 18:46:41 2012 GMT Not After : Dec 30 18:46:41 2029 GMT Subject: C = US, O = U.S. Government, OU = DODDoW, OU = PKI, CN = DOD Root CA 3 Subject Public Key Info: Public Key Algorithm: rsaEncryption If the root ca file is not a DODDoW-issued certificate with a valid date and installed in the /etc/sssd/pki/sssd_auth_ca_db.pem location, this is a finding.

V-252912 in V2R7

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., 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.

V-252914 in V2R7

Title

The TOSS file system automounter must be disabled unless required.

Check text

Note: If the "autofs" service is not installed, this requirement is Not Applicable. Verify the operating system disables the ability to automount devices. Check to see if automounter service is active with the following command: Note: If the autofs service is not installed, this requirement is Not Applicable. $ sudo systemctl status autofs autofs.service - Automounts filesystems on demand Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled) Active: inactive (dead) If the "autofs" status is set to "active" and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix text

Configure the operating system to disable the ability to automount devices. Turn off the automount service with the following commands: $ sudo systemctl stop autofs $ sudo systemctl disable autofs If "autofs" is required for Network File System (NFS), it must be documented with the ISSO.

V-252916 in V2R7

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoDDoW data may be compromised. TOSS systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoDDoW requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.

V-252917 in V2R7

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoDDoW data may be compromised. TOSS systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoDDoW requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.

V-252918 in V2R7

Title

The TOSS operating system must implement DODoW-approved encryption in the OpenSSL package.

Check text

Verify the OpenSSL library is configured to use only DODDoW-approved TLS encryption: $ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config TLS.MinProtocol = TLSv1.2 DTLS.MinProtocol = DTLSv1.2 If the "TLS.MinProtocol" is set to anything older than "TLSv1.2" or the "DTLS.MinProtocol" is set to anything older than DTLSv1.2, this is a finding.

Fix text

Configure the TOSS OpenSSL library to use only DODDoW-approved TLS encryption by editing the following lines in the "/etc/crypto-policies/back-ends/opensslcnf.config" file: MinProtocol = TLSv1.2 DTLS.MinProtocol = DTLSv1.2 A reboot is required for the changes to take effect.

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DODDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. TOSS incorporates systemwide crypto policies by default. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssl.config file. Satisfies: SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093

V-252919 in V2R7

Discussion

Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoDDoW or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components.

V-252921 in V2R7

Title

TOSS must display the Standard Mandatory DoDDoW Notice and Consent Banner or equivalent USU.S. Government Agency Notice and Consent Banner before granting local or remote access to the system via a ssh logon.

Check text

Verify that TOSS displays the Standard Mandatory DoDDoW Notice and Consent Banner or equivalent USU.S. Government Agency Notice and Consent Banner before granting access to the system when connecting from outside of the cluster. Check for the location of the banner file being used with the following command: $ sudo grep -i banner /etc/ssh/sshd_config banner /etc/issue This command will return the banner keyword and the name of the file that contains the ssh banner (in this case "/etc/issue"). If the line is commented out, this is a finding. For nodes of the cluster that are only privately (within the cluster) accessible, this requirement is Not Applicable. View the file specified by the banner keyword to check that it matches the text of the Standard Mandatory DoDDoW Notice and Consent Banner: "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." If the system has a graphical logon capability and does not display a graphical logon banner, this is a finding. If the text in the file does not match the Standard Mandatory DoDDoW Notice and Consent Banner or equivalent USU.S. Government Agency Notice and Consent Banner, this is a finding.

Fix text

Configure TOSS to display the Standard Mandatory DoDDoW Notice and Consent Banner or equivalent USU.S. Government Agency Notice and Consent Banner before granting access to the system. Edit the "/etc/ssh/sshd_config" file to uncomment the banner keyword and configure it to point to a file that will contain the logon banner (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor). An example configuration line is: banner /etc/issue The banner must be formatted in accordance with applicable DoDDoW or other USU.S. Government Agency policy. Edit the "/etc/issue" file to replace the default text with the Standard Mandatory DoDDoW Notice and Consent Banner or equivalent USU.S. Government Agency Notice and Consent Banner. The DoDDoW-required text is: "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.

Discussion

Display of a standardized and approved use notification before granting access to TOSS 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 applicable DoDDoW or other USU.S. Government Agency policy. Use the following verbiage for operating systems 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."

V-252923 in V2R7

Title

The TOSS operating system must implement DODoW-approved encryption to protect the confidentiality of SSH connections.

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DODDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. TOSS incorporates systemwide crypto policies by default. The SSH configuration file has no effect on the ciphers, MACs, or algorithms unless specifically defined in the /etc/sysconfig/sshd file. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssh.config file. By specifying a cipher list with the order of ciphers being in a "strongest to weakest" orientation, the system will automatically attempt to use the strongest cipher for securing SSH connections. Satisfies: SRG-OS-000250-GPOS-00093, SRG-OS-000394-GPOS-00174

V-252924 in V2R7

Title

The TOSS operating system must implement DODoW-approved TLS encryption in the GnuTLS package.

Check text

Verify the GnuTLS library is configured to only allow DODDoW-approved SSL/TLS Versions: $ sudo grep -io +vers.* /etc/crypto-policies/back-ends/gnutls.config +VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0:+COMP-NULL:%PROFILE_MEDIUM If the "gnutls.config" does not list "-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0" to disable unapproved SSL/TLS versions, this is a finding.

Fix text

Configure the TOSS GnuTLS library to use only DODDoW-approved encryption by adding the following line to "/etc/crypto-policies/back-ends/gnutls.config": +VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0 A reboot is required for the changes to take effect.

V-252925 in V2R7

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoDDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. TOSS incorporates system-wide crypto policies by default. The SSH configuration file has no effect on the ciphers, MACs, or algorithms unless specifically defined in the /etc/sysconfig/sshd file. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssh.config file. By specifying a hash algorithm list with the order of hashes being in a "strongest to weakest" orientation, the system will automatically attempt to use the strongest hash for securing SSH connections.

V-252926 in V2R7

Title

TOSS must, for networked systems, compare internal information system clocks at least every 24 hours with a server which is synchronized to one of the redundant United States Naval Observatory (USNO) time servers, or a time server designated for the appropriate DODDoW network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS).

Check text

If the system is not networked, this requirement is Not Applicable. The system clock must be configured to compare the system clock at least every 24 hours to the authoritative time source. Check the value of "maxpoll" in the "/etc/chrony/chrony.conf" file with the following command: $ sudo grep maxpoll /etc/chrony/chrony.conf server tick.usno.navy.mil iburst maxpoll 16 If "maxpoll" is not set to "16" or does not exist, this is a finding. Verify that the "chrony.conf" file is configured to an authoritative DODDoW time source by running the following command: $ grep -i server /etc/chrony.conf server tick.usno.navy.mil iburst maxpoll 16 server tock.usno.navy.mil iburst maxpoll 16 server ntp2.usno.navy.mil iburst maxpoll 16 If the parameter "server" is not set, is not set to an authoritative DODDoW time source, or is commented out, this is a finding.

Fix text

For networked systems, configure TOSS to compare internal information system clocks at least every 24 hours with a server which is synchronized to one of the redundant USNO time servers, or a time server designated for the appropriate DODDoW network (NIPRNet/SIPRNet), and/or the GPS. Add and/or modify the following line in the /etc/chrony.conf file: server [ntp.server.name] iburst maxpoll 16

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time that a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by the operating system include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. TOSS utilizes the "timedatectl" command to view the status of the "systemd-timesyncd.service." The "timedatectl" status will display the local time, UTC, and the offset from UTC. Note that USNO offers authenticated NTP service to DODDoW and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/dodDoW-customers for more information. Satisfies: SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144, SRG-OS-000359-GPOS-00146

V-252928 in V2R7

Discussion

Changes to any software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. Accordingly, patches, service packs, device drivers, or operating system 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 that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The operating system should 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 Certification Authority (CA).

V-252930 in V2R7

Check text

Verify the operating system requires reauthentication when using the "sudo" command to elevate privileges. $ sudo egrep -ir 'timestamp_timeout' /etc/sudoers /etc/sudoers.d /etc/sudoers:Defaults timestamp_timeout=0 If results are returned from more than one file location, this is a finding. If "timestamp_timeout" is set to a value other than "0" (including negative numbernumbers), is commented out, or nois resultsmissing are returned, this is a finding.

Fix text

Configure the "sudo"operating commandsystem to requirereauthenticate reauthenticationevery invocation of the "sudo" command. EditAdd the following line to "/etc/sudoers" file: $ sudo visudo Add or modifya thefile followingin line"/etc/sudoers.d": Defaults timestamp_timeout=0 Remove any duplicate definitions.

V-252931 in V2R7

Discussion

Using an authentication device, such as a DODDoW Common Access Card (CAC) or token that is separate from the information system, ensures that even if the information system is compromised, credentials stored on the authentication device will not be affected. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification (PIV) card and the DODDoW CAC. A privileged account is defined as an information system account with authorizations of a privileged user. Remote access is access to DODDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).

V-252932 in V2R7

Discussion

Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. Factors include: 1) something a user knows (e.g., password/PIN); 2) something a user has (e.g., cryptographic identification device, token); and 3) something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the internet). The DODDoW common access card (CAC) with DODDoW-approved PKI is an example of multifactor authentication. Satisfies: SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055

V-252952 in V2R7

Fix text

Configure TOSS to disable account identifiers after 35 days of inactivity after the password expiration. Run the following command to change the configuration for useradd: $ sudo useradd -D -f 35 DODDoW recommendation is 35 days, but a lower value is acceptable. The value "-1" will disable this feature, and "0" will disable the account immediately after the password expires.

V-252953 in V2R7

Check text

Verify that the files in the directory "/etc/audit/rules.d/" and "/etc/audit/auditd.conf" file have a mode of "0640"0600 or less permissive bywith using the following commandscommand: $ sudo lsfind -l /etc/audit/rules.d / -rwtype f -rname "*.rules" -----exec 1stat root-c root"%a 1280%n" Feb{} 161; 600 17:09/etc/audit/rules.d/audit.rules 600 /etc/audit/rules.d/10-execpriv.rules $Verify sudothe lsfiles -l"/etc/audit/audit.rules" and "/etc/audit/auditd.conf -rw-r-----" 1have roota rootmode 621of Sep"0600" 22or 17:19less auditd.confpermissive with the following command: If$ thesudo filesstat in-c the"%a %n" /etc/audit/audit.rules /etc/audit/auditd.dconf 600 /"etc/audit/audit.rules 600 directory or the "/etc/audit/auditd.conf" If fileany of the audit configuration files have a mode more permissive than "06400600", this is a finding.

Fix text

Configure the rules files in the directory "/etc/audit/rules.d/", the /etc/audit/audit.rules file, and the "/etc/audit/auditd.conf" file to have a mode of "0640"0600 with the following commands: $ sudo chmodfind 0640 /etc/audit/rules.d/audit -type f -name "*.rules" -exec chmod 0600 {} + $ sudo chmod 06400600 /etc/audit/rulesaudit.d/[customrulesfile].rules $ sudo chmod 06400600 /etc/audit/auditd.conf

V-253008 in V2R7

Discussion

Configuring TOSS to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across the DoDDoW that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the system, including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, services, and remote connections.

V-253051 in V2R7

Discussion

Remote access services, such as those providing remote access to network devices and information systems, which lack automated monitoring capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoDDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities, such as Remote Desktop Protocol (RDP), on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

V-253056 in V2R7

Check text

Verify TOSS implements DoDDoW-approved encryption to protect the confidentiality of remote access sessions. Check to see if FIPS mode is enabled with the following command: $ fips-mode-setup --check FIPS mode is enabled If FIPS mode is "enabled", check to see if the kernel boot parameter is configured for FIPS mode with the following command: $ sudo grub2-editenv list | grep fips kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet fips=1 boot=UUID=8d171156-cd61-421c-ba41-1c021ac29e82 If the kernel boot parameter is configured to use FIPS mode, check to see if the system is in FIPS mode with the following command: $ sudo cat /proc/sys/crypto/fips_enabled 1 If FIPS mode is not "on", the kernel boot parameter is not configured for FIPS mode, or the system does not have a value of "1" for "fips_enabled" in "/proc/sys/crypto", this is a finding. If the hardware configuration of the operating system does not allow for enabling FIPS mode, and has been documented with the Information System Security Officer (ISSO), this requirement is Not Applicable.

Fix text

Configure the operating system to implement DoDDoW-approved encryption by following the steps below: To enable strict FIPS compliance, the fips=1 kernel option needs to be added to the kernel boot parameters during system installation so key generation is done with FIPS-approved algorithms and continuous monitoring tests in place. Enable FIPS mode after installation (not strict FIPS compliant) with the following command: $ sudo fips-mode-setup --enable Reboot the system for the changes to take effect.

V-253059 in V2R7

Discussion

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DODDoW data may be compromised. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DODDoW requirements.

V-253064 in V2R7

Title

TOSS must enforce a 6180-day maximum password lifetime restriction.

Check text

Verify that TOSS enforces a 60180-day maximum password lifetime for new user accounts by running the following command: $ sudo grep -i pass_max_days /etc/login.defs PASS_MAX_DAYS 60180 If the "PASS_MAX_DAYS" parameter value is greater than "60180", or commented out, this is a finding.

Fix text

Configure TOSS to enforce a 6180-day maximum password lifetime. Add, or modify the following line in the "/etc/login.defs" file: PASS_MAX_DAYS 6180

CCIs

CCI-004066,CCI-000199CCI-000199

V-253067 in V2R7

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time when a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Not exposing the management interface of the chrony daemon on the network diminishes the attack space. TOSS utilizes the "timedatectl" command to view the status of the "systemd-timesyncd.service." The "timedatectl" status will display the local time, UTC, and the offset from UTC. Note that USNO offers authenticated NTP service to DoDDoW and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/dodDoW-customers for more information.

V-253073 in V2R7

Discussion

"Firewalld" provides an easy and effective way to block/limit remote access to the system via ports, services, and protocols. Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoDDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. TOSS functionality (e.g., SSH) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

V-253088 in V2R7

Discussion

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. The DoDDoW has mandated the use of the Common Access Card (CAC) to support identity management and personal authentication for systems covered under Homeland Security Presidential Directive (HSPD) 12, as well as making the CAC a primary component of layered protection for national security systems.

V-253090 in V2R7

Title

TOSS must implement DoDW-approved encryption in the OpenSSL package.

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoDDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. TOSS incorporates system-wide crypto policies by default. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssl.config file.

V-253091 in V2R7