What changed in Tri-Lab Operating System Stack (TOSS) 5 STIG V1R2V1R2 changes

Title

TOSS 5 must display the Standard Mandatory DODDoW or other applicable U.S. Government Notice and Consent Banner before granting local or remote access to the system via a command line user login.

Check text

For nodes of the cluster that are only privately (within the cluster) accessible, this requirement is not applicable. Verify TOSS 5 displays the Standard Mandatory DODDoW or other applicable U.S. Government Notice and Consent Banner before granting access to the operating system via a command line user login. Check that a banner is displayed at the command line login screen using the following command: $ sudo cat /etc/issue If the banner is set correctly, it will return the following text: "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 banner text does not match the Standard Mandatory DODDoW or other applicable U.S. Government Notice and Consent Banner exactly, or the line is commented out, this is a finding.

Fix text

Configure TOSS 5 to display the Standard Mandatory DODDoW or other applicable U.S. Government Notice and Consent Banner before granting access to the system via command line login. Edit the "/etc/issue" file to replace the default text with the Standard Mandatory DODDoW or other applicable U.S. Government 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."

V-282366 in V1R2

Title

TOSS 5 must display the Standard Mandatory DODDoW or other applicable U.S. Government agency Notice and Consent Banner before granting local or remote access to the system via a SSH login.

Check text

Verify any SSH connection to the operating system displays the Standard Mandatory DODDoW or other applicable U.S. Government agency Notice and Consent Banner before granting access to the system. For nodes of the cluster that are only privately (within the cluster) accessible, this requirement is not applicable. Check for the location of the banner file being used using the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '1r' | tr '1n' ' ' | xargs sudo grep -iH '^1s*banner' 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.

Fix text

Configure TOSS 5 to display the Standard Mandatory DODDoW or other applicable U.S. Government agency Notice and Consent Banner before granting access to the system via SSH. Edit the "/etc/ssh/sshd_config" file to uncomment the banner keyword and configure it to point to a file that contains the login 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

V-282367 in V1R2

Title

TOSS 5 must display the Standard Mandatory DODDoW or other applicable U.S. Government agency Notice and Consent Banner before granting local or remote access to the system via a graphical user login.

Fix text

Configure TOSS 5 to display the Standard Mandatory DODDoW or other applicable U.S. Government agency Notice and Consent Banner before granting access to the system via a graphical user login. Create a database to contain the systemwide graphical user login settings (if it does not already exist) using the following command: $ sudo touch /etc/dconf/db/local.d/01-banner-message Add the following lines to the [org/gnome/login-screen] section of the "/etc/dconf/db/local.d/01-banner-message": [org/gnome/login-screen] banner-message-enable=true Run the following command to update the database: $ sudo dconf update

V-282368 in V1R2

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. If auditing is enabled late in the startup process, the actions of some startup processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created. Audit records can be generated from various components within the information system (e.g., module or policy filter). 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 generate audit records. DODDoW has defined the list of events for which TOSS 5 will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful login attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logins from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.

V-282436 in V1R2

Check text

If PKI-based authentication is used, verify TOSS 5 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 using 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-282442 in V1R2

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 5 systems using encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-3 is the current standard for validating that mechanisms used to access cryptographic modules use authentication that meets DODDoW requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.

V-282461 in V1R2

Title

TOSS 5 user account passwords for new users or password changes must have a 6180-day maximum password lifetime restriction in /etc/login.defs.

Check text

Verify TOSS 5 enforces a 60180-day maximum password lifetime for new user accounts using the following command: $ 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 5 to enforce a 6180-day maximum password lifetime. Add or modify the following line in the "/etc/login.defs" file: PASS_MAX_DAYS 6180

V-282465 in V1R2

Title

TOSS 5 user account passwords must have a 6180-day maximum password lifetime restriction.

Check text

Check whether the maximum time period for existing passwords is restricted to 60180 days with the following commands: $ sudo awk -F: '$5 > 60180 {print $1 "" "" $5}' /etc/shadow $ sudo awk -F: '$5 &lt= 0 {print $1 "" "" $5}' /etc/shadow If any results are returned that are not associated with a system account, this is a finding.

Fix text

Configure noncompliant accounts to enforce a 6180-day maximum password lifetime restriction. $ sudo passwd -x 6180 [user]

V-282466 in V1R2

Discussion

The shorter the password, the lower the number of possible combinations that must be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to increase exponentially the time and/or resources required to compromise the password. TOSS 5 uses "pwquality" as a mechanism to enforce password complexity. Configurations are set in the "etc/security/pwquality.conf" file. The "minlen", sometimes noted as minimum length, acts as a "score" of complexity based on the credit components of the "pwquality" module. By setting the credit components to a negative value, not only will those components be required, but they will not count toward the total "score" of "minlen". This will enable "minlen" to require a 15-character minimum. The DODDoW minimum password requirement is 15 characters.

V-282467 in V1R2

Discussion

The shorter the password, the lower the number of possible combinations that must be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to increase exponentially the time and/or resources required to compromise the password. The DODDoW minimum password requirement is 15 characters.

V-282468 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., 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. This requirement prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password.

V-282471 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., 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. This requirement prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password.

V-282472 in V1R2

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, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. TOSS 5 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). Satisfies: SRG-OS-000096-GPOS-00050, SRG-OS-000298-GPOS-00116

V-282485 in V1R2

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, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. TOSS 5 functionality (e.g., RDP) 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). Satisfies: SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115

V-282486 in V1R2

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. A privileged account is defined as an information system account with authorizations of a privileged user. 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-000046-GPOS-00022, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055

V-282492 in V1R2

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. Restricting access to the kernel message buffer limits access to only root. This prevents attackers from gaining additional system information as a nonprivileged user. Satisfies: SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069

V-282505 in V1R2

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. Setting the kernel.perf_event_paranoid kernel parameter to "2" prevents attackers from gaining additional system information as a nonprivileged user. Satisfies: SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069

V-282506 in V1R2

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.

V-282511 in V1R2

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.

V-282522 in V1R2

Title

TOSS 5 must implement DODoW or other applicable U.S. Government agency-approved encryption ciphers to protect the confidentiality of SSH client 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 5 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/opensshserver.config file.

V-282523 in V1R2

Title

TOSS 5 must implement DODoW or other applicable U.S. Government agency-approved encryption ciphers to protect the confidentiality of SSH server 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 5 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/opensshserver.config" file.

V-282524 in V1R2

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 5 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/opensshserver.config" file.

V-282525 in V1R2

Title

TOSS 5 must implement DODoW or other applicable U.S. Government agency-approved TLS encryption in the GnuTLS package.

Check text

Verify if GnuTLS uses defined DODDoW-approved TLS Crypto Policy using the following command: $ update-crypto-policies --show FIPS If the systemwide crypto policy is not set to "FIPS", this is a finding.

V-282526 in V1R2

Title

TOSS 5 must implement DODoW or other applicable U.S. Government agency -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, 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. The employed algorithms can be viewed in the "/etc/crypto-policies/back-ends/openssl.config" file.

V-282527 in V1R2

Title

TOSS 5 must implement DODoW or other applicable U.S. Government agency-approved TLS encryption in the OpenSSL package.

Fix text

Configure the TOSS 5 OpenSSL library to use only DODDoW-approved TLS encryption by editing the following line in the "/etc/crypto-policies/back-ends/opensslcnf.config" file: TLS.MinProtocol = TLSv1.2 DTLS.MinProtocol = DTLSv1.2 Restart the system 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. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssl.config file.

V-282528 in V1R2

Check text

Verify TOSS 5 is securely comparing internal information system clocks at least every 24 hours with an NTP server with the following commands: $ sudo grep maxpoll /etc/chrony.conf server 0.us.pool.ntp.mil iburst maxpoll 16 If the "maxpoll" option is set to a number greater than 16 or the line is commented out, this is a finding. Verify the "chrony.conf" file is configured to an authoritative DODDoW time source using the following command: $ sudo grep -i server /etc/chrony.conf server 0.us.pool.ntp.mil If the parameter "server" is not set or is not set to an authoritative DODDoW time source, this is a finding.

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time 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. Depending on the infrastructure being used the "pool" directive may not be supported. Authoritative time sources include the United States Naval Observatory (USNO) time servers, a time server designated for the appropriate DODDoW network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS). Satisfies: SRG-OS-000298-GPOS-00116, SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144, SRG-OS-000359-GPOS-00146

V-282549 in V1R2

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. Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000376-GPOS-00161, SRG-OS-000377-GPOS-00162

V-282592 in V1R2

Title

TOSS 5 must implement DODoW or other applicable U.S. Government agency-approved encryption in the bind package.

V-282608 in V1R2

Discussion

Failure to restrict network connectivity only to authorized systems permits inbound connections from malicious systems. It also permits outbound connections that may facilitate exfiltration of DODDoW data. TOSS 5 incorporates the "firewalld" daemon, which allows for many different configurations. One of these configurations is zones. Zones can be used to a deny-all, allow-by-exception approach. The default "drop" zone will drop all incoming network packets unless it is explicitly allowed by the configuration file or is related to an outgoing network connection.

V-282675 in V1R2

Check text

Verify that TOSS 5 system accounts mustdo not have an interactive login shell. Run using the following command: $ awkto -F:list 'any system account ($3UID &lt1000lt 1000){print $1that ":"has $3an ":"interactive $7}'shell, /etc/passwd root:0:/bin/bash bin:1:/sbin/nologin daemon:2:/sbin/nologin adm:3:/sbin/nologin lp:4:/sbin/nologin Identifyexcluding theauthorized system utility accounts from(root, thissync, listingshutdown, thathalt): $ do$ notawk have-F: a'(($3 nologin> or0 similar&& noninteractive$3 shell. If&lt any1000) system&& account$1 !~ /^(otherhalt|sync|shutdown)$/ than&& the$7 root!~ account/(nologin|false)$/) has{print a$1 login":" shell$3 and":" it$7}' is/etc/passwd If not documented with the informationcommand systemreturns securityany officer (ISSO)output, this is a finding.

V-282723 in V1R2

Check text

Verify TOSS 5 is securely comparing internal information system clocks at least every 24 hours with an NTP server with the following commands: $ sudo grep maxpoll /etc/chrony.conf server 0.us.pool.ntp.mil iburst maxpoll 16 If the "maxpoll" option is set to a number greater than 16 or the line is commented out, this is a finding. Verify the "chrony.conf" file is configured to an authoritative DODDoW or other U.S. Government time source using the following command: $ sudo grep -i server /etc/chrony.conf server 0.us.pool.ntp.mil If the parameter "server" is not set or is not set to an authoritative DODDoW or other U.S. Government time source, this is a finding.

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time 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. Depending on the infrastructure being used the "pool" directive may not be supported. Authoritative time sources include the United States Naval Observatory (USNO) time servers, a time server designated for the appropriate DODDoW network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS).

V-282772 in V1R2