Tri-Lab Operating System Stack (TOSS) 4 Security Technical Implementation Guide

  • Version/Release: V1R3
  • Published: 2024-01-02
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
b
TOSS must display the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner before granting local or remote access to the system.
AC-8 - Medium - CCI-000048 - V-252911 - SV-252911r824057_rule
RMF Control
AC-8
Severity
Medium
CCI
CCI-000048
Version
TOSS-04-010000
Vuln IDs
  • V-252911
Rule IDs
  • SV-252911r824057_rule
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 DoD or other US 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."
Checks: C-56364r824055_chk

Verify TOSS displays the Standard Mandatory DoD Notice and Consent Banner or equivalent US 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 DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner, this is a finding.

Fix: F-56314r824056_fix

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

b
TOSS, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
IA-5 - Medium - CCI-000185 - V-252912 - SV-252912r824060_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000185
Version
TOSS-04-010010
Vuln IDs
  • V-252912
Rule IDs
  • SV-252912r824060_rule
Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. 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-OS-000066-GPOS-00034, SRG-OS-000384-GPOS-00167
Checks: C-56365r824058_chk

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 = DoD, 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 = DoD, OU = PKI, CN = DoD Root CA 3 Subject Public Key Info: Public Key Algorithm: rsaEncryption If the root ca file is not a DoD-issued certificate with a valid date and installed in the /etc/sssd/pki/sssd_auth_ca_db.pem location, this is a finding.

Fix: F-56315r824059_fix

If PKI-based authentication is used, configure TOSS to validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Obtain a valid copy of the DoD root CA file from the PKI CA certificate bundle from cyber.mil and copy it into the following file: /etc/sssd/pki/sssd_auth_ca_db.pem

b
TOSS, for PKI-based authentication, must enforce authorized access to the corresponding private key.
IA-5 - Medium - CCI-000186 - V-252913 - SV-252913r824063_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000186
Version
TOSS-04-010020
Vuln IDs
  • V-252913
Rule IDs
  • SV-252913r824063_rule
If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.
Checks: C-56366r824061_chk

Verify the operating system, for PKI-based authentication, enforces authorized access to the corresponding private key. If the system does not allow PKI authentication, this requirement is Not Applicable. Verify the SSH private key files have a passphrase. For each private key stored on the system, use the following command: $ sudo ssh-keygen -y -f /path/to/file If the contents of the key are displayed, and use of un-passphrased SSH keys is not documented with the Information System Security Officer (ISSO), this is a finding.

Fix: F-56316r824062_fix

Create a new private and public key pair that utilizes a passcode with the following command: $ sudo ssh-keygen -n [passphrase]

b
TOSS must require authentication upon booting into emergency or rescue modes.
AC-3 - Medium - CCI-000213 - V-252914 - SV-252914r824066_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-000213
Version
TOSS-04-010030
Vuln IDs
  • V-252914
Rule IDs
  • SV-252914r824066_rule
To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD 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.
Checks: C-56367r824064_chk

Check to see if the system requires authentication for rescue or emergency mode with the following command: $ sudo grep sulogin-shell /usr/lib/systemd/system/rescue.service ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue If the "ExecStart" line is configured for anything other than "/usr/lib/systemd/systemd-sulogin-shell rescue", commented out, or missing, this is a finding.

Fix: F-56317r824065_fix

Configure the system to require authentication upon booting into emergency or rescue mode by adding the following line to the "/usr/lib/systemd/system/rescue.service" file. ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue

b
TOSS must not permit direct logons to the root account using remote access from outside of the system via SSH.
IA-2 - Medium - CCI-000770 - V-252915 - SV-252915r824069_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000770
Version
TOSS-04-010040
Vuln IDs
  • V-252915
Rule IDs
  • SV-252915r824069_rule
Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging on directly as root. In addition, logging on with a user-specific account provides individual accountability of actions performed on the system.
Checks: C-56368r824067_chk

Verify remote access from outside the system using SSH prevents users from logging on directly as "root." Check that SSH prevents users from logging on directly as "root" with the following command: $ sudo grep -i PermitRootLogin /etc/ssh/sshd_config PermitRootLogin no If the "PermitRootLogin" keyword is set to "yes", is missing, or is commented out, and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56318r824068_fix

Configure TOSS to stop users from logging on remotely from outside of the cluster as the "root" user via SSH. Edit the appropriate "/etc/ssh/sshd_config" file to uncomment or add the line for the "PermitRootLogin" keyword and set its value to "no": PermitRootLogin no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b
The TOSS file system automounter must be disabled unless required.
IA-3 - Medium - CCI-000778 - V-252916 - SV-252916r824072_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-000778
Version
TOSS-04-010050
Vuln IDs
  • V-252916
Rule IDs
  • SV-252916r824072_rule
Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity.
Checks: C-56369r824070_chk

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: F-56319r824071_fix

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.

b
The TOSS pam_unix.so module must be configured in the password-auth file to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication.
IA-7 - Medium - CCI-000803 - V-252917 - SV-252917r824075_rule
RMF Control
IA-7
Severity
Medium
CCI
CCI-000803
Version
TOSS-04-010060
Vuln IDs
  • V-252917
Rule IDs
  • SV-252917r824075_rule
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 DoD 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 DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.
Checks: C-56370r824073_chk

Verify that the pam_unix.so module is configured to use sha512. Check that the pam_unix.so module is configured to use sha512 in /etc/pam.d/password-auth with the following command: $ sudo grep password /etc/pam.d/password-auth | grep pam_unix password sufficient pam_unix.so sha512 If "sha512" is missing, or is commented out, this is a finding.

Fix: F-56320r824074_fix

Configure TOSS to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication. Edit and/or modify the following line in the "/etc/pam.d/password-auth" file to include the sha512 option for pam_unix.so: password sufficient pam_unix.so sha512

b
The TOSS pam_unix.so module must be configured in the system-auth file to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication.
IA-7 - Medium - CCI-000803 - V-252918 - SV-252918r824078_rule
RMF Control
IA-7
Severity
Medium
CCI
CCI-000803
Version
TOSS-04-010070
Vuln IDs
  • V-252918
Rule IDs
  • SV-252918r824078_rule
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 DoD 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 DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.
Checks: C-56371r824076_chk

Verify that the pam_unix.so module is configured to use sha512. Check that the pam_unix.so module is configured to use sha512 in /etc/pam.d/system-auth with the following command: $ sudo grep password /etc/pam.d/system-auth | grep pam_unix password sufficient pam_unix.so sha512 If "sha512" is missing, or is commented out, this is a finding.

Fix: F-56321r824077_fix

Configure TOSS to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication. Edit and/or modify the following line in the "/etc/pam.d/system-auth" file to include the sha512 option for pam_unix.so: password sufficient pam_unix.so sha512

b
The TOSS operating system must implement DoD-approved encryption in the OpenSSL package.
MA-4 - Medium - CCI-000877 - V-252919 - SV-252919r877395_rule
RMF Control
MA-4
Severity
Medium
CCI
CCI-000877
Version
TOSS-04-010080
Vuln IDs
  • V-252919
Rule IDs
  • SV-252919r877395_rule
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoD 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. Satisfies: SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093
Checks: C-56372r824079_chk

Verify the OpenSSL library is configured to use only DoD-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: F-56322r824080_fix

Configure the TOSS OpenSSL library to use only DoD-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.

b
TOSS must use a Linux Security Module configured to enforce limits on system services.
SC-3 - Medium - CCI-001084 - V-252920 - SV-252920r824084_rule
RMF Control
SC-3
Severity
Medium
CCI
CCI-001084
Version
TOSS-04-010090
Vuln IDs
  • V-252920
Rule IDs
  • SV-252920r824084_rule
An isolation boundary provides access control and protects the integrity of the hardware, software, and firmware that perform security functions. Security functions are the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Operating systems implement code separation (i.e., separation of security functions from non-security functions) in a number of ways, including through the provision of security kernels via processor rings or processor modes. For non-kernel code, security function isolation is often achieved through file system protections that serve to protect the code on disk and address space protections that protect executing code. Developers and implementers can increase the assurance in security functions by employing well-defined security policy models; structured, disciplined, and rigorous hardware and software development techniques; and sound system/security engineering principles. Implementation may include isolation of memory space and libraries. Operating systems restrict access to security functions through the use of access control mechanisms and by implementing least privilege capabilities.
Checks: C-56373r824082_chk

Verify that TOSS verifies the correct operation of all security functions. Check if "SELinux" is active and in "Enforcing" mode with the following command: $ sudo getenforce Enforcing If "SELinux" is not active or not in "Enforcing" mode, this is a finding.

Fix: F-56323r824083_fix

Configure the operating system to verify correct operation of all security functions. Set the "SELinux" status and the "Enforcing" mode by modifying the "/etc/selinux/config" file to have the following line: SELINUX=enforcing A reboot is required for the changes to take effect.

b
TOSS must prevent unauthorized and unintended information transfer via shared system resources.
SC-4 - Medium - CCI-001090 - V-252921 - SV-252921r824087_rule
RMF Control
SC-4
Severity
Medium
CCI
CCI-001090
Version
TOSS-04-010100
Vuln IDs
  • V-252921
Rule IDs
  • SV-252921r824087_rule
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 DoD 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.
Checks: C-56374r824085_chk

Check to see that all public directories are owned by root or a system account with the following command: $ sudo find / -type d -perm -0002 -exec ls -lLd {} \; drwxrwxrwxt 7 root root 4096 Jul 26 11:19 /tmp If any of the returned directories are not owned by root or a system account, this is a finding.

Fix: F-56324r824086_fix

Configure all public directories to be owned by root or a system account to prevent unauthorized and unintended information transferred via shared system resources. Set the owner of all public directories as root or a system account using the command, replace "[Public Directory]" with any directory path not owned by root or a system account: $ sudo chown root [Public Directory]

b
The TOSS operating system must be configured to use TCP syncookies.
SC-5 - Medium - CCI-001095 - V-252922 - SV-252922r824090_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001095
Version
TOSS-04-010110
Vuln IDs
  • V-252922
Rule IDs
  • SV-252922r824090_rule
Denial of Service (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. Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.
Checks: C-56375r824088_chk

Verify The TOSS operating system is configured to use TCP syncookies. Check the value of TCP syncookies with the following command: $ sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_syncookies = 1 If the value is not "1", this is a finding. Check the saved value of TCP syncookies with the following command: $ sudo grep -i net.ipv4.tcp_syncookies /etc/sysctl.conf /etc/sysctl.d/* | grep -v '#' If no output is returned, this is a finding.

Fix: F-56325r824089_fix

Configure The TOSS operating system to use TCP syncookies by running the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1 If "1" is not the system's default value, add or update the following line in "/etc/sysctl.conf": net.ipv4.tcp_syncookies = 1

a
TOSS must display the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner before granting local or remote access to the system via a ssh logon.
AC-8 - Low - CCI-001384 - V-252923 - SV-252923r824093_rule
RMF Control
AC-8
Severity
Low
CCI
CCI-001384
Version
TOSS-04-010120
Vuln IDs
  • V-252923
Rule IDs
  • SV-252923r824093_rule
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 DoD or other US 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."
Checks: C-56376r824091_chk

Verify that TOSS displays the Standard Mandatory DoD Notice and Consent Banner or equivalent US 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 DoD 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 DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner, this is a finding.

Fix: F-56326r824092_fix

Configure TOSS to display the Standard Mandatory DoD Notice and Consent Banner or equivalent US 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 DoD or other US Government Agency policy. Edit the "/etc/issue" file to replace the default text with the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner. The DoD-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.

b
The TOSS operating system must implement DoD-approved encryption to protect the confidentiality of SSH connections.
AC-17 - Medium - CCI-001453 - V-252924 - SV-252924r877394_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-001453
Version
TOSS-04-010140
Vuln IDs
  • V-252924
Rule IDs
  • SV-252924r877394_rule
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoD 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 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
Checks: C-56377r824094_chk

Verify the SSH daemon is configured to use only ciphers employing FIPS 140-2-approved algorithms: Verify that system-wide crypto policies are in effect: $ sudo grep CRYPTO_POLICY /etc/sysconfig/sshd # CRYPTO_POLICY= If the "CRYPTO_POLICY" is uncommented, this is a finding. Verify which system-wide crypto policy is in use: $ sudo update-crypto-policies --show FIPS Check that the ciphers in the back-end configurations are FIPS 140-2-approved algorithms with the following command: $ sudo grep -i ciphers /etc/crypto-policies/back-ends/openssh.config /etc/crypto-policies/back-ends/opensshserver.config /etc/crypto-policies/back-ends/openssh.config:Ciphers aes256-ctr,aes192-ctr,aes128-ctr /etc/crypto-policies/back-ends/opensshserver.config:CRYPTO_POLICY='-oCiphers=aes256-ctr,aes192-ctr,aes128-ctr' /etc/crypto-policies/back-ends/opensshserver.config:CRYPTO_POLICY='-oCiphers=aes256-ctr,aes192-ctr,aes128-ctr' If the cipher entries in the "openssh.config" and "opensshserver.config" files have any ciphers other than "aes256-ctr,aes192-ctr,aes128-ctr", the order differs from the example above, if they are missing, or commented out, this is a finding.

Fix: F-56327r824095_fix

Configure the TOSS SSH daemon to use only ciphers employing FIPS 140-2-approved algorithms with the following command: $ sudo fips-mode-setup --enable Next, update the "/etc/crypto-policies/back-ends/openssh.config" and "/etc/crypto-policies/back-ends/opensshserver.config" files to include these ciphers employing FIPS 140-2-approved algorithms: /etc/crypto-policies/back-ends/openssh.config:Ciphers aes256-ctr,aes192-ctr,aes128-ctr /etc/crypto-policies/back-ends/opensshserver.config:CRYPTO_POLICY='-oCiphers=aes256-ctr,aes192-ctr,aes128-ctr' /etc/crypto-policies/back-ends/opensshserver.config:CRYPTO_POLICY='-oCiphers=aes256-ctr,aes192-ctr,aes128-ctr' A reboot is required for the changes to take effect.

b
The TOSS operating system must implement DoD-approved TLS encryption in the GnuTLS package.
AC-17 - Medium - CCI-001453 - V-252925 - SV-252925r877394_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-001453
Version
TOSS-04-010150
Vuln IDs
  • V-252925
Rule IDs
  • SV-252925r877394_rule
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Transport Layer Security (TLS) encryption is a required security setting as a number of known vulnerabilities have been reported against Secure Sockets Layer (SSL) and earlier versions of TLS. Encryption of private information is essential to ensuring data confidentiality. If private information is not encrypted, it can be intercepted and easily read by an unauthorized party. SQL Server must use a minimum of FIPS 140-2-approved TLS version 1.2, and all non-FIPS-approved SSL and TLS versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems. 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 GnuTLS library offers an API to access secure communications protocols. SSLv2 is not available in the GnuTLS library. The TOSS system-wide crypto policy defines employed algorithms in the /etc/crypto-policies/back-ends/gnutls.config file.5
Checks: C-56378r824097_chk

Verify the GnuTLS library is configured to only allow DoD-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: F-56328r824098_fix

Configure the TOSS GnuTLS library to use only DoD-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.

b
The TOSS SSH daemon must be configured to use only Message Authentication Codes (MACs) employing FIPS 140-2 validated cryptographic hash algorithms.
AC-17 - Medium - CCI-001453 - V-252926 - SV-252926r877394_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-001453
Version
TOSS-04-010160
Vuln IDs
  • V-252926
Rule IDs
  • SV-252926r877394_rule
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoD 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.
Checks: C-56379r824100_chk

Verify the SSH daemon is configured to use only MACs employing FIPS 140-2-approved algorithms: Check that the MACs in the back-end configurations are FIPS 140-2-approved algorithms with the following command: $ sudo grep -i macs /etc/crypto-policies/back-ends/openssh.config /etc/crypto-policies/back-ends/opensshserver.config /etc/crypto-policies/back-ends/openssh.config:MACs hmac-sha2-512,hmac-sha2-256 /etc/crypto-policies/back-ends/opensshserver.config:-oMACs=hmac-sha2-512,hmac-sha2-256' /etc/crypto-policies/back-ends/opensshserver.config:-oMACs=hmac-sha2-512,hmac-sha2-256' If the MAC entries in the "openssh.config" and "opensshserver.config" files have any hashes other than "hmac-sha2-512" and "hmac-sha2-256", the order differs from the example above, if they are missing, or commented out, this is a finding.

Fix: F-56329r824101_fix

Configure the TOSS SSH daemon to use only MACs employing FIPS 140-2-approved algorithms. Update the "/etc/crypto-policies/back-ends/openssh.config" and "/etc/crypto-policies/back-ends/opensshserver.config" files to include these MACs employing FIPS 140-2-approved algorithms: /etc/crypto-policies/back-ends/openssh.config:MACs hmac-sha2-512,hmac-sha2-256 /etc/crypto-policies/back-ends/opensshserver.config:-oMACs=hmac-sha2-512,hmac-sha2-256' /etc/crypto-policies/back-ends/opensshserver.config:-oMACs=hmac-sha2-512,hmac-sha2-256' A reboot is required for the changes to take effect.

b
The TOSS operating system must be configured to preserve log records from failure events.
SC-24 - Medium - CCI-001665 - V-252927 - SV-252927r824105_rule
RMF Control
SC-24
Severity
Medium
CCI
CCI-001665
Version
TOSS-04-010170
Vuln IDs
  • V-252927
Rule IDs
  • SV-252927r824105_rule
Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving operating system state information helps to facilitate operating system restart and return to the operational mode of the organization with least disruption to mission/business processes.
Checks: C-56380r824103_chk

Verify the rsyslog service is enabled and active with the following commands: $ sudo systemctl is-enabled rsyslog enabled $ sudo systemctl is-active rsyslog active If the service is not "enabled" and "active", this is a finding. If "rsyslog" is not enabled, ask the System Administrator how system error logging is performed on the system. If there is no evidence of system logging being performed on the system, this is a finding.

Fix: F-56330r824104_fix

Start and enable the rsyslog service with the following commands: $ sudo systemctl start rsyslog.service $ sudo systemctl enable rsyslog.service

b
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 DoD network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS).
AU-8 - Medium - CCI-001890 - V-252928 - SV-252928r877038_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001890
Version
TOSS-04-010180
Vuln IDs
  • V-252928
Rule IDs
  • SV-252928r877038_rule
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 DoD and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/dod-customers for more information. Satisfies: SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144, SRG-OS-000359-GPOS-00146
Checks: C-56381r824106_chk

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 DoD 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 DoD time source, or is commented out, this is a finding.

Fix: F-56331r824107_fix

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 United States Naval Observatory (USNO) time servers, or a time server designated for the appropriate DoD network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS). Add and/or modify the following line in the /etc/chrony.conf file: server [ntp.server.name] iburst maxpoll 16

b
The TOSS file integrity tool must notify the system administrator when changes to the baseline configuration or anomalies in the operation of any security functions are discovered within an organizationally defined frequency.
CM-3 - Medium - CCI-001744 - V-252929 - SV-252929r824111_rule
RMF Control
CM-3
Severity
Medium
CCI
CCI-001744
Version
TOSS-04-010210
Vuln IDs
  • V-252929
Rule IDs
  • SV-252929r824111_rule
Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the operating system. Changes to operating system configurations can have unintended side effects, some of which may be relevant to security. Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the operating system. The operating system's Information Management Officer (IMO)/Information System Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. This capability must take into account operational requirements for availability for selecting an appropriate response. The organization may choose to shut down or restart the information system upon security function anomaly detection. TOSS 4 comes with many optional software packages. A file integrity tool called Advanced Intrusion Detection Environment (AIDE) is one of those optional packages. This requirement assumes the use of AIDE; however, a different tool may be used if the requirements are met. Note that AIDE does not have a configuration that will send a notification, so a cron job is recommended that uses the mail application on the system to email the results of the file integrity check. Satisfies: SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201
Checks: C-56382r824109_chk

Verify the operating system routinely checks the baseline configuration for unauthorized changes and notifies the system administrator when anomalies in the operation of any security functions are discovered. Check to see if AIDE is installed on the system with the following command: $ sudo yum list installed aide If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system. Check that TOSS routinely executes a file integrity scan for changes to the system baseline. The command used in the example will use a daily occurrence. Check the cron directories for scripts controlling the execution and notification of results of the file integrity application. For example, if AIDE is installed on the system, use the following commands: $ sudo ls -al /etc/cron.* | grep aide -rwxr-xr-x 1 root root 29 Nov 22 2015 aide $ sudo grep aide /etc/crontab /var/spool/cron/root /etc/crontab: 30 04 * * * root usr/sbin/aide /var/spool/cron/root: 30 04 * * * root usr/sbin/aide $ sudo more /etc/cron.daily/aide #!/bin/bash /usr/sbin/aide --check | /bin/mail -s "$HOSTNAME - Daily aide integrity check run" root@sysname.mil Here the use of /bin/mail is one example of how to notify designated personnel. There may be other methods available to a system, such as notifications from an external log aggregation service (e.g., SIEM). If the file integrity application does not exist, or a script file controlling the execution of the file integrity application does not exist, or the file integrity application does not notify designated personnel of changes, this is a finding.

Fix: F-56332r824110_fix

Configure the file integrity tool to run automatically on the system at least weekly and to notify designated personnel if baseline configurations are changed in an unauthorized manner. The AIDE tool can be configured to email designated personnel with the use of the cron system. The following example output is generic. It will set cron to run AIDE daily and to send email at the completion of the analysis. $ sudo more /etc/cron.daily/aide #!/bin/bash /usr/sbin/aide --check | /bin/mail -s "$HOSTNAME - Daily aide integrity check run" root@sysname.mil

c
TOSS must prevent the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization.
CM-5 - High - CCI-001749 - V-252930 - SV-252930r877463_rule
RMF Control
CM-5
Severity
High
CCI
CCI-001749
Version
TOSS-04-010220
Vuln IDs
  • V-252930
Rule IDs
  • SV-252930r877463_rule
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 DoD certificates for this purpose; however, the certificate used to verify the software must be from an approved CA.
Checks: C-56383r824112_chk

Verify TOSS prevents the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization. Check that YUM verifies the signature of packages from a repository prior to install with the following command: $ sudo egrep '^\[.*\]|gpgcheck' /etc/yum.repos.d/*.repo /etc/yum.repos.d/appstream.repo:[appstream] /etc/yum.repos.d/appstream.repo:gpgcheck=1 /etc/yum.repos.d/baseos.repo:[baseos] /etc/yum.repos.d/baseos.repo:gpgcheck=1 If "gpgcheck" is not set to "1", or if options are missing or commented out, ask the System Administrator how the certificates for patches and other operating system components are verified. If there is no process to validate certificates that is approved by the organization, this is a finding.

Fix: F-56333r824113_fix

Configure TOSS to prevent the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization by setting the following option in the "/etc/yum.repos.d/[your_repo_name].repo" file(s): gpgcheck=1

b
TOSS must require re-authentication when using the "sudo" command.
IA-11 - Medium - CCI-002038 - V-252931 - SV-252931r824117_rule
RMF Control
IA-11
Severity
Medium
CCI
CCI-002038
Version
TOSS-04-010230
Vuln IDs
  • V-252931
Rule IDs
  • SV-252931r824117_rule
Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical the organization requires the user to re-authenticate when using the "sudo" command. If the value is set to an integer less than 0, the user's time stamp will not expire and the user will not have to re-authenticate for privileged actions until the user's session is terminated.
Checks: C-56384r824115_chk

Verify the operating system requires re-authentication 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 "timestamp_timeout" is set to a negative number, is commented out, or no results are returned, this is a finding.

Fix: F-56334r824116_fix

Configure the "sudo" command to require re-authentication. Edit the /etc/sudoers file: $ sudo visudo Add or modify the following line: Defaults timestamp_timeout=0

b
TOSS must have the packages required for multifactor authentication installed.
IA-2 - Medium - CCI-001948 - V-252932 - SV-252932r824120_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-001948
Version
TOSS-04-010240
Vuln IDs
  • V-252932
Rule IDs
  • SV-252932r824120_rule
Using an authentication device, such as a DoD 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 DoD CAC. A privileged account is defined as an information system account with authorizations of a privileged user. Remote access is access to DoD 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).
Checks: C-56385r824118_chk

Verify TOSS has the packages required for multifactor authentication installed with the following commands: $ sudo yum list installed openssl-pkcs11 openssl-pkcs11.x86_64 0.4.10-2.el8 @anaconda If the "openssl-pkcs11" package is not installed, ask the administrator to indicate what type of multifactor authentication is being utilized and what packages are installed to support it. If there is no evidence of multifactor authentication being used, this is a finding.

Fix: F-56335r824119_fix

Configure TOSS to implement multifactor authentication by installing the required package with the following command: $ sudo yum install openssl-pkcs11

b
TOSS must prohibit the use of cached authentications after one day.
IA-5 - Medium - CCI-002007 - V-252933 - SV-252933r824123_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-002007
Version
TOSS-04-010250
Vuln IDs
  • V-252933
Rule IDs
  • SV-252933r824123_rule
If cached authentication information is out of date, the validity of the authentication information may be questionable. TOSS includes multiple options for configuring authentication, but this requirement will be focus on the System Security Services Daemon (SSSD). By default, sssd does not cache credentials.
Checks: C-56386r824121_chk

Verify that SSSD prohibits the use of cached authentications after one day. Note: If smart card authentication is not being used on the system, this item is Not Applicable. Check that SSSD allows cached authentications with the following command: $ sudo grep cache_credentials /etc/sssd/sssd.conf cache_credentials = true If "cache_credentials" is set to "false" or missing from the configuration file, this is not a finding and no further checks are required. If "cache_credentials" is set to "true", check that SSSD prohibits the use of cached authentications after one day with the following command: $ sudo grep offline_credentials_expiration /etc/sssd/sssd.conf offline_credentials_expiration = 1 If "offline_credentials_expiration" is not set to a value of "1", this is a finding.

Fix: F-56336r824122_fix

Configure the SSSD to prohibit the use of cached authentications after one day. Add or change the following line in "/etc/sssd/sssd.conf" just below the line "[pam]." offline_credentials_expiration = 1

b
All TOSS networked systems must have and implement SSH to protect the confidentiality and integrity of transmitted and received information, as well as information during preparation for transmission.
SC-8 - Medium - CCI-002418 - V-252934 - SV-252934r916422_rule
RMF Control
SC-8
Severity
Medium
CCI
CCI-002418
Version
TOSS-04-010280
Vuln IDs
  • V-252934
Rule IDs
  • SV-252934r916422_rule
Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190
Checks: C-56387r824124_chk

Verify that the SSH package is installed: $ rpm -q openssh-server openssh-server-8.0p1-10.el8_4.2.x86_64 If the "SSH server" package is not installed, this is a finding. Verify SSH is loaded and active with the following commands: $ sudo systemctl is-active sshd active $ sudo systemctl is-enabled sshd enabled If "sshd" does not show a status of "active" and "enabled", this is a finding.

Fix: F-56337r824125_fix

Install the SSH server package onto the host with the following command: $ sudo yum install openssh-server Configure the SSH service to automatically start now and after each reboot with the following command: $ sudo systemctl enable --now sshd.service

b
For TOSS systems using Domain Name Servers (DNS) resolution, at least two name servers must be configured.
CM-6 - Medium - CCI-000366 - V-252935 - SV-252935r824129_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-010330
Vuln IDs
  • V-252935
Rule IDs
  • SV-252935r824129_rule
To provide availability for name resolution services, multiple redundant name servers are mandated. A failure in name resolution could lead to the failure of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging.
Checks: C-56388r824127_chk

Determine whether the system is using local or DNS name resolution with the following command: $ sudo grep hosts /etc/nsswitch.conf hosts: files dns If the DNS entry is missing from the host's line in the "/etc/nsswitch.conf" file, the "/etc/resolv.conf" file must be empty. Verify the "/etc/resolv.conf" file is empty with the following command: $ sudo ls -al /etc/resolv.conf -rw-r--r-- 1 root root 0 Aug 19 08:31 resolv.conf If local host authentication is being used and the "/etc/resolv.conf" file is not empty, this is a finding. If the DNS entry is found on the host's line of the "/etc/nsswitch.conf" file, verify the operating system is configured to use two or more name servers for DNS resolution. Determine the name servers used by the system with the following command: $ sudo grep nameserver /etc/resolv.conf nameserver 192.168.1.2 nameserver 192.168.1.3 If less than two lines are returned that are not commented out, this is a finding.

Fix: F-56338r824128_fix

Configure the operating system to use two or more name servers for DNS resolution. By default, "NetworkManager" on TOSS dynamically updates the /etc/resolv.conf file with the DNS settings from active "NetworkManager" connection profiles. However, this feature can be disabled to allow manual configurations. If manually configuring DNS, edit the "/etc/resolv.conf" file to uncomment or add the two or more "nameserver" option lines with the IP address of local authoritative name servers. If local host resolution is being performed, the "/etc/resolv.conf" file must be empty. An empty "/etc/resolv.conf" file can be created as follows: $ sudo echo -n > /etc/resolv.conf

b
The debug-shell systemd service must be disabled on TOSS.
CM-6 - Medium - CCI-000366 - V-252936 - SV-252936r824132_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-010340
Vuln IDs
  • V-252936
Rule IDs
  • SV-252936r824132_rule
The debug-shell requires no authentication and provides root privileges to anyone who has physical access to the machine. While this feature is disabled by default, masking it adds an additional layer of assurance that it will not be enabled via a dependency in systemd. This also prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted.
Checks: C-56389r824130_chk

Verify TOSS is configured to mask the debug-shell systemd service with the following command: $ sudo systemctl status debug-shell.service debug-shell.service Loaded: masked (Reason: Unit debug-shell.service is masked.) Active: inactive (dead) If the "debug-shell.service" is loaded and not masked, this is a finding.

Fix: F-56339r824131_fix

Configure the system to mask the debug-shell systemd service with the following command: $ sudo systemctl mask debug-shell.service Created symlink /etc/systemd/system/debug-shell.service -> /dev/null Reload the daemon to take effect. $ sudo systemctl daemon-reload

c
The root account must be the only account having unrestricted access to the TOSS system.
CM-6 - High - CCI-000366 - V-252937 - SV-252937r824135_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
TOSS-04-010350
Vuln IDs
  • V-252937
Rule IDs
  • SV-252937r824135_rule
If an account other than root also has a User Identifier (UID) of "0", it has root authority, giving that account unrestricted access to the entire operating system. Multiple accounts with a UID of "0" afford an opportunity for potential intruders to guess a password for a privileged account.
Checks: C-56390r824133_chk

Check the system for duplicate UID "0" assignments with the following command: $ sudo awk -F: '$3 == 0 {print $1}' /etc/passwd If any accounts other than root have a UID of "0", this is a finding.

Fix: F-56340r824134_fix

Change the UID of any account on the system, other than root, that has a UID of "0." If the account is associated with system commands or applications, the UID should be changed to one greater than "0" but less than "1000." Otherwise, assign a UID of greater than "1000" that has not already been assigned.

c
The systemd Ctrl-Alt-Delete burst key sequence in TOSS must be disabled.
CM-6 - High - CCI-000366 - V-252938 - SV-252938r824138_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
TOSS-04-010360
Vuln IDs
  • V-252938
Rule IDs
  • SV-252938r824138_rule
A locally logged-on user who presses Ctrl-Alt-Delete when at the console can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In a graphical user environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.
Checks: C-56391r824136_chk

Verify TOSS is not configured to reboot the system when Ctrl-Alt-Delete is pressed seven times within two seconds with the following command: $ sudo grep -i ctrl /etc/systemd/system.conf CtrlAltDelBurstAction=none If the "CtrlAltDelBurstAction" is not set to "none", commented out, or is missing, this is a finding.

Fix: F-56341r824137_fix

Configure the system to disable the CtrlAltDelBurstAction by added or modifying the following line in the "/etc/systemd/system.conf" configuration file: CtrlAltDelBurstAction=none Reload the daemon for this change to take effect. $ sudo systemctl daemon-reload

b
There must be no ".shosts" files on The TOSS operating system.
CM-6 - Medium - CCI-000366 - V-252939 - SV-252939r824141_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-010370
Vuln IDs
  • V-252939
Rule IDs
  • SV-252939r824141_rule
The ."shosts" files are used to configure host-based authentication for individual users or the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication.
Checks: C-56392r824139_chk

Verify there are no ."shosts" files on TOSS with the following command: $ sudo find / -name '*.shosts' If any ."shosts" files are found, this is a finding.

Fix: F-56342r824140_fix

Remove any found ."shosts" files from the system. $ sudo rm /[path]/[to]/[file]/.shosts

c
TOSS must not allow blank or null passwords in the system-auth file.
CM-6 - High - CCI-000366 - V-252940 - SV-252940r824144_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
TOSS-04-010380
Vuln IDs
  • V-252940
Rule IDs
  • SV-252940r824144_rule
If an account has an empty password, anyone could log on and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.
Checks: C-56393r824142_chk

To verify that null passwords cannot be used, run the following command: $ sudo grep -i nullok /etc/pam.d/system-auth If output is produced, this is a finding.

Fix: F-56343r824143_fix

Remove any instances of the "nullok" option in the "/etc/pam.d/system-auth" file to prevent logons with empty passwords. Note: Manual changes to the listed file may be overwritten by the "authselect" program.

b
TOSS must not be performing packet forwarding unless the system is a router.
CM-6 - Medium - CCI-000366 - V-252941 - SV-252941r824147_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-010390
Vuln IDs
  • V-252941
Rule IDs
  • SV-252941r824147_rule
Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network.
Checks: C-56394r824145_chk

Verify TOSS is not performing packet forwarding unless the system is a router. If the system is a router (sometimes called a gateway) this requirement is Not Applicable. Note: If either IPv4 or IPv6 is disabled on the system, this requirement only applies to the active internet protocol version. Check to see if IP forwarding is enabled using the following commands: $ sudo sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 0 $ sudo sysctl net.ipv6.conf.all.forwarding net.ipv6.conf.all.forwarding = 0 If IP forwarding value is not "0" and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56344r824146_fix

Configure TOSS to not allow packet forwarding, unless the system is a router with the following commands: $ sudo sysctl -w net.ipv4.ip_forward=0 $ sudo sysctl -w net.ipv6.conf.all.forwarding=0 If "0" is not the system's default value then add or update the following lines in the appropriate file under "/etc/sysctl.d": net.ipv4.ip_forward=0 net.ipv6.conf.all.forwarding=0

b
The TOSS SSH daemon must not allow authentication using known host's authentication.
CM-6 - Medium - CCI-000366 - V-252942 - SV-252942r824150_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-010400
Vuln IDs
  • V-252942
Rule IDs
  • SV-252942r824150_rule
Configuring this setting for the SSH daemon provides additional assurance that remote logon via SSH will require a password, even in the event of misconfiguration elsewhere.
Checks: C-56395r824148_chk

Verify the SSH daemon does not allow authentication using known host's authentication with the following command: $ sudo grep -i IgnoreUserKnownHosts /etc/ssh/sshd_config IgnoreUserKnownHosts yes If the value is returned as "no", the returned line is commented out, or no output is returned, this is a finding.

Fix: F-56345r824149_fix

Configure the SSH daemon to not allow authentication using known host's authentication. Add the following line in "/etc/ssh/sshd_config" or uncomment the line and set the value to "yes": IgnoreUserKnownHosts yes The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b
The TOSS SSH daemon must not allow compression or must only allow compression after successful authentication.
CM-6 - Medium - CCI-000366 - V-252943 - SV-252943r824153_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-010410
Vuln IDs
  • V-252943
Rule IDs
  • SV-252943r824153_rule
If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.
Checks: C-56396r824151_chk

Verify the SSH daemon performs compression after a user successfully authenticates with the following command: $ sudo grep -i compression /etc/ssh/sshd_config Compression delayed If the "Compression" keyword is set to "yes", is missing, or the returned line is commented out, this is a finding.

Fix: F-56346r824152_fix

Uncomment the "Compression" keyword in "/etc/ssh/sshd_config" (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) on the system and set the value to "delayed" or "no": Compression no The SSH service must be restarted for changes to take effect.

b
The TOSS SSH daemon must not allow Kerberos authentication, except to fulfill documented and validated mission requirements.
CM-6 - Medium - CCI-000366 - V-252944 - SV-252944r824156_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-010420
Vuln IDs
  • V-252944
Rule IDs
  • SV-252944r824156_rule
Configuring these settings for the SSH daemon provides additional assurance that remote logon via SSH will not use unused methods of authentication, even in the event of misconfiguration elsewhere.
Checks: C-56397r824154_chk

Verify the SSH daemon does not allow Kerberos authentication with the following command: $ sudo grep -i KerberosAuthentication /etc/ssh/sshd_config KerberosAuthentication no If the value is returned as "yes", the returned line is commented out, no output is returned, or has not been documented with the ISSO, this is a finding.

Fix: F-56347r824155_fix

Configure the SSH daemon to not allow Kerberos authentication. Add the following line in "/etc/ssh/sshd_config" or uncomment the line and set the value to "no": KerberosAuthentication no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

c
TOSS must not allow an unattended or automatic logon to the system.
CM-6 - High - CCI-000366 - V-252945 - SV-252945r877377_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
TOSS-04-010430
Vuln IDs
  • V-252945
Rule IDs
  • SV-252945r877377_rule
Failure to restrict system access to authenticated users negatively impacts operating system security.
Checks: C-56398r824157_chk

Verify TOSS does not allow an unattended or automatic logon to the system via a graphical user interface. Note: This requirement assumes the use of the TOSS default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Check for the value of the "AutomaticLoginEnable" in the "/etc/gdm/custom.conf" file with the following command: $ sudo grep -i automaticloginenable /etc/gdm/custom.conf AutomaticLoginEnable=false If the value of "AutomaticLoginEnable" is missing or is not set to "false", this is a finding. If it does, this is a finding. Automatic logon as an authorized user allows access to any user with physical access to the operating system.

Fix: F-56348r824158_fix

Configure TOSS to not allow an unattended or automatic logon to the system via a graphical user interface. Add or edit the line for the "AutomaticLoginEnable" parameter in the [daemon] section of the "/etc/gdm/custom.conf" file to "false": [daemon] AutomaticLoginEnable=false

b
TOSS must enforce the limit of five consecutive invalid logon attempts by a user during a 15-minute time period.
AC-7 - Medium - CCI-000044 - V-252946 - SV-252946r824162_rule
RMF Control
AC-7
Severity
Medium
CCI
CCI-000044
Version
TOSS-04-020000
Vuln IDs
  • V-252946
Rule IDs
  • SV-252946r824162_rule
By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-force attacks, is reduced. Limits are imposed by locking the account.
Checks: C-56399r824160_chk

Verify the "/etc/security/faillock.conf" file is configured to lock an account after three unsuccessful logon attempts within 15 minutes: $ sudo grep -e "deny =" -e "fail_interval =" /etc/security/faillock.conf deny = 3 fail_interval = 900 If the "deny" option is set to "0", more than "3", is missing, or is commented out, this is a finding. If the "fail_interval" option is set to less than "900", is missing, or is commented out, this is a finding. Note: If the System Administrator demonstrates the use of an approved centralized account management method that locks an account after three unsuccessful logon attempts within a period of 15 minutes, this requirement is Not Applicable.

Fix: F-56349r824161_fix

Configure the operating system to lock an account when three unsuccessful logon attempts occur in 15 minutes. Add/Modify the "/etc/security/faillock.conf" file to match the following lines: deny = 3 fail_interval = 900

a
TOSS must limit the number of concurrent sessions to 256 for all accounts and/or account types.
AC-10 - Low - CCI-000054 - V-252947 - SV-252947r877399_rule
RMF Control
AC-10
Severity
Low
CCI
CCI-000054
Version
TOSS-04-020010
Vuln IDs
  • V-252947
Rule IDs
  • SV-252947r877399_rule
Operating system management includes the ability to control the number of users and user sessions that utilize an operating system. Limiting the number of allowed users and sessions per user is helpful in reducing the risks related to Denial of Service (DoS) attacks. TOSS as an HPC operating system, is capable of supporting a large number of sessions, as well as tools which presume a larger number of concurrent sessions will be allowed. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system.
Checks: C-56400r824163_chk

Verify TOSS limits the number of concurrent sessions to less than or equal to 256 for all accounts and/or account types by issuing the following command: $ sudo grep -r -s '^[^#].*maxlogins' /etc/security/limits.conf /etc/security/limits.d/*.conf * hard maxlogins 256 This can be set as a global domain (with the * wildcard) but may be set differently for multiple domains. If the "maxlogins" item is missing, commented out, or the value is set greater than "256" and is not documented with the Information System Security Officer (ISSO) as an operational requirement for all domains that have the "maxlogins" item assigned, this is a finding.

Fix: F-56350r824164_fix

Configure TOSS to limit the number of concurrent sessions to at most 256 for all accounts and/or account types. Add the following line to the top of the /etc/security/limits.conf or in a ."conf" file defined in /etc/security/limits.d/: * hard maxlogins 256

b
TOSS must retain a user's session lock until that user reestablishes access using established identification and authentication procedures.
AC-11 - Medium - CCI-000056 - V-252948 - SV-252948r824168_rule
RMF Control
AC-11
Severity
Medium
CCI
CCI-000056
Version
TOSS-04-020020
Vuln IDs
  • V-252948
Rule IDs
  • SV-252948r824168_rule
A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. Regardless of where the session lock is determined and implemented, once invoked, the session lock shall remain in place until the user re-authenticates. No other activity aside from re-authentication shall unlock the system. Satisfies: SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011, SRG-OS-000031-GPOS-00012
Checks: C-56401r824166_chk

Verify TOSS retains a user's session lock until that user reestablishes access using established identification and authentication procedures with the following command: Note: This requirement assumes the use of the TOSS default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. $ sudo gsettings get org.gnome.desktop.screensaver lock-enabled true If the setting is "false", this is a finding.

Fix: F-56351r824167_fix

Configure TOSS to retain a user's session lock until that user reestablishes access using established identification and authentication procedures. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following example: $ sudo vi /etc/dconf/db/local.d/00-screensaver Edit the "[org/gnome/desktop/screensaver]" section of the database file and add or update the following lines: # Set this to true to lock the screen when the screensaver activates lock-enabled=true Update the system databases: $ sudo dconf update

b
TOSS must automatically lock graphical user sessions after 15 minutes of inactivity.
AC-11 - Medium - CCI-000057 - V-252949 - SV-252949r824171_rule
RMF Control
AC-11
Severity
Medium
CCI
CCI-000057
Version
TOSS-04-020030
Vuln IDs
  • V-252949
Rule IDs
  • SV-252949r824171_rule
A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock. The session lock is implemented at the point where session activity can be determined and/or controlled.
Checks: C-56402r824169_chk

Verify TOSS initiates a session lock after at most a 15-minute period of inactivity for graphical user interfaces with the following commands: Note: This requirement assumes the use of the TOSS default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. $ sudo gsettings get org.gnome.desktop.session idle-delay uint32 900 If "idle-delay" is set to "0" or a value greater than "900", this is a finding.

Fix: F-56352r824170_fix

Configure the operating system to initiate a screensaver after a 15-minute period of inactivity for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: $ sudo touch /etc/dconf/db/local.d/00-screensaver Edit /etc/dconf/db/local.d/00-screensaver and add or update the following lines: [org/gnome/desktop/session] # Set the lock time out to 900 seconds before the session is considered idle idle-delay=uint32 900 Update the system databases: $ sudo dconf update

b
TOSS must map the authenticated identity to the user or group account for PKI-based authentication.
IA-5 - Medium - CCI-000187 - V-252950 - SV-252950r824174_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000187
Version
TOSS-04-020050
Vuln IDs
  • V-252950
Rule IDs
  • SV-252950r824174_rule
Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. There are various methods of mapping certificates to user/group accounts for TOSS. For the purposes of this requirement, the check and fix will account for Active Directory mapping. Some of the other possible methods include joining the system to a domain and utilizing a TOSS idM server, or a local system mapping, where the system is not part of a domain.
Checks: C-56403r824172_chk

Verify the certificate of the user or group is mapped to the corresponding user or group in the "sssd.conf" file with the following command: Note: If the system does not support PKI authentication, this requirement is Not Applicable. $ sudo cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = pam, sudo, ssh domains = testing.test [pam] pam_cert_auth = True [domain/testing.test] id_provider = ldap [certmap/testing.test/rule_name] matchrule =<SAN>.*EDIPI@mil maprule = (userCertificate;binary={cert!bin}) domains = testing.test If the certmap section does not exist, ask the System Administrator to indicate how certificates are mapped to accounts. If there is no evidence of certificate mapping, this is a finding.

Fix: F-56353r824173_fix

Configure TOSS to map the authenticated identity to the user or group account by adding or modifying the certmap section of the "/etc/sssd/sssd.conf" file based on the following example: [certmap/testing.test/rule_name] matchrule =<SAN>.*EDIPI@mil maprule = (userCertificate;binary={cert!bin}) dmains = testing.test The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service

b
TOSS duplicate User IDs (UIDs) must not exist for interactive users.
IA-2 - Medium - CCI-000764 - V-252951 - SV-252951r824177_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000764
Version
TOSS-04-020060
Vuln IDs
  • V-252951
Rule IDs
  • SV-252951r824177_rule
To ensure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. Interactive users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Interactive users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following: 1) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and 2) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Satisfies: SRG-OS-000104-GPOS-00051, SRG-OS-000121-GPOS-00062
Checks: C-56404r824175_chk

Verify that TOSS contains no duplicate User IDs (UIDs) for interactive users. Check that the operating system contains no duplicate UIDs for interactive users with the following command: $ sudo awk -F ":" 'list[$3]++{print $1, $3}' /etc/passwd If output is produced, and the accounts listed are interactive user accounts, this is a finding.

Fix: F-56354r824176_fix

Edit the file "/etc/passwd" and provide each interactive user account that has a duplicate User ID (UID) with a unique UID.

b
TOSS must use multifactor authentication for network and local access to privileged and non-privileged accounts.
IA-2 - Medium - CCI-000765 - V-252952 - SV-252952r824180_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000765
Version
TOSS-04-020070
Vuln IDs
  • V-252952
Rule IDs
  • SV-252952r824180_rule
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 DoD CAC with DoD-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
Checks: C-56405r824178_chk

Verify the operating system uses multifactor authentication for network access to privileged accounts. If it does not, this is a finding. Note: This requirement is applicable to any externally accessible nodes of the TOSS system. For compute or other intra-cluster only accessible nodes, this requirement is Not Applicable. One possible method for meeting this requirement is to require smart card logon for access to interactive accounts. Check that the "pam_cert_auth" setting is set to "true" in the "/etc/sssd/sssd.conf" file. Check that the "try_cert_auth" or "require_cert_auth" options are configured in both "/etc/pam.d/system-auth" and "/etc/pam.d/smartcard-auth" files with the following command: $ sudo grep cert_auth /etc/sssd/sssd.conf /etc/pam.d/* /etc/sssd/sssd.conf:pam_cert_auth = True /etc/pam.d/smartcard-auth:auth sufficient pam_sss.so try_cert_auth /etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth If "pam_cert_auth" is not set to "true" in "/etc/sssd/sssd.conf", this is a finding. If "pam_sss.so" is not set to "try_cert_auth" or "require_cert_auth" in both the "/etc/pam.d/smartcard-auth" and "/etc/pam.d/system-auth" files, this is a finding.

Fix: F-56355r824179_fix

Configure the operating system to use multifactor authentication for network access to privileged accounts. One possible method for meeting this requirement is to require smart card logon for access to interactive accounts; in which case, configure TOSS to use multifactor authentication for local access to accounts. Add or update the "pam_cert_auth" setting in the "/etc/sssd/sssd.conf" file to match the following line: [pam] pam_cert_auth = True Add or update "pam_sss.so" with "try_cert_auth" or "require_cert_auth" in the "/etc/pam.d/system-auth" and "/etc/pam.d/smartcard-auth" files based on the following examples: /etc/pam.d/smartcard-auth:auth sufficient pam_sss.so try_cert_auth /etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service

b
TOSS must disable account identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.
IA-4 - Medium - CCI-000795 - V-252953 - SV-252953r824183_rule
RMF Control
IA-4
Severity
Medium
CCI
CCI-000795
Version
TOSS-04-020120
Vuln IDs
  • V-252953
Rule IDs
  • SV-252953r824183_rule
Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Operating systems need to track periods of inactivity and disable application identifiers after 35 days of inactivity.
Checks: C-56406r824181_chk

Verify the account identifiers (individuals, groups, roles, and devices) are disabled after 35 days of inactivity with the following command: Check the account inactivity value by performing the following command: $ sudo grep -i inactive /etc/default/useradd INACTIVE=35 If "INACTIVE" is set to "-1", a value greater than "35", or is commented out, this is a finding.

Fix: F-56356r824182_fix

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

b
TOSS must automatically remove or disable emergency accounts after the crisis is resolved or 72 hours.
AC-2 - Medium - CCI-001682 - V-252954 - SV-252954r824186_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001682
Version
TOSS-04-020140
Vuln IDs
  • V-252954
Rule IDs
  • SV-252954r824186_rule
Emergency accounts are privileged accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability. Emergency accounts are different from infrequently used accounts (i.e., local logon accounts used by the organization's system administrators when network or normal logon/access is not available). Infrequently used accounts are not subject to automatic termination dates. Emergency accounts are accounts created in response to crisis situations, usually for use by maintenance personnel. The automatic expiration or disabling time period may be extended as needed until the crisis is resolved; however, it must not be extended indefinitely. A permanent account should be established for privileged users who need long-term maintenance accounts. To address access requirements, TOSS can be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.
Checks: C-56407r824184_chk

Verify emergency accounts have been provisioned with an expiration date of 72 hours. For every existing emergency account, run the following command to obtain its account expiration information. $ sudo chage -l system_account_name Verify each of these accounts has an expiration date set within 72 hours. If any emergency accounts have no expiration date set or do not expire within 72 hours, this is a finding. If there are no emergency accounts configured, this requirement is Not Applicable.

Fix: F-56357r824185_fix

If an emergency account must be created, configure the system to terminate the account after 72 hours with the following command to set an expiration date for the account. Substitute "system_account_name" with the account to be created. $ sudo chage -E `date -d "+3 days" +%Y-%m-%d` system_account_name The automatic expiration or disabling time period may be extended as needed until the crisis is resolved.

b
TOSS must reveal error messages only to authorized users.
SI-11 - Medium - CCI-001314 - V-252955 - SV-252955r824189_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
TOSS-04-020150
Vuln IDs
  • V-252955
Rule IDs
  • SV-252955r824189_rule
Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.
Checks: C-56408r824187_chk

Verify the "/var/log/messages" file has a mode of "0640" or less permissive and is owned by the root user with the following command: $ sudo ls -l /var/log/messages -rw-r----- 1 root root 59782947 Jul 20 01:36 /var/log/messages If the "/var/log/messages" file has a mode more permissive than "0640", this is a finding. If the "/var/log/messages" file is not owned by "root", this is a finding. Verify the "/var/log" directory has a mode of "0755" or less permissive and is owned by the root user with the following command: $ sudo ls -ld /var/log/ drwxr-xr-x 1 root root 1200 Jul 19 03:39 /var/log If the "/var/log/" directory has a mode more permissive than "0755", this is a finding. If the "/var/log/" directory is not owned by "root", this is a finding.

Fix: F-56358r824188_fix

Change the permissions of the file "/var/log/messages" to "0640" and the ownership of the file to "root" by running the following commands: $ sudo chmod 0640 /var/log/messages $ sudo chown root /var/log/messages Change the permissions of the directory "/var/log/" to "0755" and the ownership of the directory to "root" by running the following commands: $ sudo chmod 0755 /var/log/ $ sudo chown root /var/log/

b
TOSS must protect wireless access to the system using authentication of users and/or devices.
AC-18 - Medium - CCI-001443 - V-252956 - SV-252956r824192_rule
RMF Control
AC-18
Severity
Medium
CCI
CCI-001443
Version
TOSS-04-020160
Vuln IDs
  • V-252956
Rule IDs
  • SV-252956r824192_rule
Allowing devices and users to connect to the system without first authenticating them allows untrusted access and can lead to a compromise or attack. Wireless technologies include, for example, microwave, packet radio (UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication. This requirement applies to those operating systems that control wireless devices. Satisfies: SRG-OS-000299-GPOS-00117, SRG-OS-000300-GPOS-00118, SRG-OS-000481-GPOS-00481
Checks: C-56409r824190_chk

Verify there are no wireless interfaces configured on the system with the following command: Note: This requirement is Not Applicable for systems that do not have physical wireless network radios. $ sudo nmcli device status DEVICE TYPE STATE CONNECTION virbr0 bridge connected virbr0 wlp7s0 wifi connected wifiSSID enp6s0 ethernet disconnected -- p2p-dev-wlp7s0 wifi-p2p disconnected -- lo loopback unmanaged -- virbr0-nic tun unmanaged -- If a wireless interface is configured and has not been documented and approved by the Information System Security Officer (ISSO), this is a finding.

Fix: F-56359r824191_fix

Configure the system to disable all wireless network interfaces with the following command: $ sudo nmcli radio all off

b
TOSS must automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes occur.
AC-7 - Medium - CCI-002238 - V-252957 - SV-252957r824195_rule
RMF Control
AC-7
Severity
Medium
CCI
CCI-002238
Version
TOSS-04-020170
Vuln IDs
  • V-252957
Rule IDs
  • SV-252957r824195_rule
By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account. Due to the scale of HPC systems and the number of users in question, it is impractical to require an administrator to unlock the user's account manually. Strong controls around automatic lock out, and typical (though not universal) use of strong MFA to enter an HPC system mitigate the concerns of a brute force attack being successful.
Checks: C-56410r824193_chk

Check that the system locks an account after three unsuccessful logon attempts within a period of 15 minutes until released by an administrator with the following commands. Note: If a centralized authentication platform (AD, IdM, LDAP, etc) is utilized for authentication, then this requirement is not applicable, to allow the centralized platform to solely manage user lockout. Verify the pam_faillock.so module is present in the "/etc/pam.d/system-auth" and " /etc/pam.d/password-auth" files: $ sudo grep pam_faillock.so /etc/pam.d/system-auth /etc/pam.d/password-auth /etc/pam.d/system-auth:auth required pam_faillock.so preauth /etc/pam.d/system-auth:auth required pam_faillock.so authfail /etc/pam.d/system-auth:account required pam_faillock.so /etc/pam.d/password-auth:auth required pam_faillock.so preauth /etc/pam.d/password-auth:auth required pam_faillock.so authfail /etc/pam.d/password-auth:account required pam_faillock.so preauth If the pam_failllock.so module is not present in the "/etc/pam.d/system-auth" and " /etc/pam.d/password-auth" files, this is a finding. Verify the "/etc/security/faillock.conf" file is configured to lock an account until released by an administrator after three unsuccessful logon attempts: $ sudo grep 'unlock_time =' /etc/security/faillock.conf unlock_time = 0 If the "unlock_time" option is not set to "0", is missing or commented out, this is a finding.

Fix: F-56360r824194_fix

Configure the operating system to lock an account until released by an administrator when three unsuccessful logon attempts occur in 15 minutes. Add and/or modify the appropriate sections of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth auth required pam_faillock.so authfail account required pam_faillock.so Add and/or modify the "/etc/security/faillock.conf" file to match the following line: unlock_time = 0

b
TOSS must require users to reauthenticate for privilege escalation.
IA-11 - Medium - CCI-002038 - V-252958 - SV-252958r824198_rule
RMF Control
IA-11
Severity
Medium
CCI
CCI-002038
Version
TOSS-04-020180
Vuln IDs
  • V-252958
Rule IDs
  • SV-252958r824198_rule
Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical the user re-authenticate.
Checks: C-56411r824196_chk

Verify that "/etc/sudoers" has no occurrences of "!authenticate." Check that the "/etc/sudoers" file has no occurrences of "!authenticate" by running the following command: $ sudo grep -i authenticate /etc/sudoers /etc/sudoers.d/* If any occurrences of "!authenticate" return from the command, this is a finding.

Fix: F-56361r824197_fix

Remove any occurrence of "!authenticate" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.

b
TOSS must require users to provide a password for privilege escalation.
IA-11 - Medium - CCI-002038 - V-252959 - SV-252959r824201_rule
RMF Control
IA-11
Severity
Medium
CCI
CCI-002038
Version
TOSS-04-020190
Vuln IDs
  • V-252959
Rule IDs
  • SV-252959r824201_rule
Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical the user reauthenticate.
Checks: C-56412r824199_chk

Verify that "/etc/sudoers" has no occurrences of "NOPASSWD." Check that the "/etc/sudoers" file has no occurrences of "NOPASSWD" by running the following command: $ sudo grep -i nopasswd /etc/sudoers /etc/sudoers.d/* %admin ALL=(ALL) NOPASSWD: ALL If any occurrences of "NOPASSWD" are returned from the command and have not been documented with the ISSO as an organizationally defined administrative group utilizing MFA, this is a finding.

Fix: F-56362r824200_fix

Remove any occurrence of "NOPASSWD" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.

b
All TOSS local interactive user accounts must be assigned a home directory upon creation.
CM-6 - Medium - CCI-000366 - V-252960 - SV-252960r824204_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-020200
Vuln IDs
  • V-252960
Rule IDs
  • SV-252960r824204_rule
If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.
Checks: C-56413r824202_chk

Verify all local interactive users on TOSS are assigned a home directory upon creation with the following command: $ sudo grep -i create_home /etc/login.defs CREATE_HOME yes If the value for "CREATE_HOME" parameter is not set to "yes", the line is missing, or the line is commented out, this is a finding.

Fix: F-56363r824203_fix

Configure TOSS to assign home directories to all new local interactive users by setting the "CREATE_HOME" parameter in "/etc/login.defs" to "yes" as follows. CREATE_HOME yes

b
All TOSS local interactive user home directories must be group-owned by the home directory owner's primary group.
CM-6 - Medium - CCI-000366 - V-252961 - SV-252961r824207_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-020210
Vuln IDs
  • V-252961
Rule IDs
  • SV-252961r824207_rule
If the Group Identifier (GID) of a local interactive user's home directory is not the same as the primary GID of the user, this would allow unauthorized access to the user's files, and users that share the same group may not be able to access files that they legitimately should.
Checks: C-56414r824205_chk

Verify the assigned home directory of all local interactive users is group-owned by that user's primary GID with the following command: Note: This may miss local interactive users that have been assigned a privileged UID. Evidence of interactive use may be obtained from a number of log files containing system logon information. The returned directory "/home/smithj" is used as an example. $ sudo ls -ld $(awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){print $6}' /etc/passwd) drwxr-x--- 2 smithj admin 4096 Jun 5 12:41 smithj Check the user's primary group with the following command: $ sudo grep $(grep smithj /etc/passwd | awk -F: '{print $4}') /etc/group admin:x:250:smithj,jonesj,jacksons If the user home directory referenced in "/etc/passwd" is not group-owned by that user's primary GID, this is a finding.

Fix: F-56364r824206_fix

Change the group owner of a local interactive user's home directory to the group found in "/etc/passwd." To change the group owner of a local interactive user's home directory, use the following command: Note: The example will be for the user "smithj", who has a home directory of "/home/smithj", and has a primary group of users. $ sudo chgrp users /home/smithj

b
All TOSS local interactive users must have a home directory assigned in the /etc/passwd file.
CM-6 - Medium - CCI-000366 - V-252962 - SV-252962r824210_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-020230
Vuln IDs
  • V-252962
Rule IDs
  • SV-252962r824210_rule
If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.
Checks: C-56415r824208_chk

Verify local interactive users on TOSS have a home directory assigned with the following command: $ sudo pwck -r user 'lp': directory '/var/spool/lpd' does not exist user 'news': directory '/var/spool/news' does not exist user 'uucp': directory '/var/spool/uucp' does not exist user 'www-data': directory '/var/www' does not exist Ask the System Administrator (SA) if any users found without home directories are local interactive users. If the SA is unable to provide a response, check for users with a User Identifier (UID) of 1000 or greater with the following command: $ sudo awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){print $1, $3, $6}' /etc/passwd If any interactive users do not have a home directory assigned, this is a finding.

Fix: F-56365r824209_fix

Assign home directories to all local interactive users on TOSS that currently do not have a home directory assigned.

c
The x86 Ctrl-Alt-Delete key sequence in TOSS must be disabled if a graphical user interface is installed.
CM-6 - High - CCI-000366 - V-252963 - SV-252963r824213_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
TOSS-04-020240
Vuln IDs
  • V-252963
Rule IDs
  • SV-252963r824213_rule
A locally logged-on user, who presses Ctrl-Alt-Delete when at the console, can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In a graphical user environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.
Checks: C-56416r824211_chk

Verify TOSS is not configured to reboot the system when Ctrl-Alt-Delete is pressed when using a graphical user interface with the following command: Note: This requirement assumes the use of the TOSS default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. $ sudo grep logout /etc/dconf/db/local.d/* logout='' If the "logout" key is bound to an action, is commented out, or is missing, this is a finding.

Fix: F-56366r824212_fix

Configure the system to disable the Ctrl-Alt-Delete sequence when using a graphical user interface by creating or editing the /etc/dconf/db/local.d/00-disable-CAD file. Add the setting to disable the Ctrl-Alt-Delete sequence for a graphical user interface: [org/gnome/settings-daemon/plugins/media-keys] logout='' Note: The value above is set to two single quotations. Then update the dconf settings: $ sudo dconf update

b
TOSS must disable the user list at logon for graphical user interfaces.
CM-6 - Medium - CCI-000366 - V-252964 - SV-252964r824216_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-020250
Vuln IDs
  • V-252964
Rule IDs
  • SV-252964r824216_rule
Leaving the user list enabled is a security risk since it allows anyone with physical access to the system to enumerate known user accounts without authenticated access to the system.
Checks: C-56417r824214_chk

Verify the operating system disables the user logon list for graphical user interfaces with the following command: Note: This requirement assumes the use of the TOSS default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. $ sudo gsettings get org.gnome.login-screen disable-user-list true If the setting is "false", this is a finding.

Fix: F-56367r824215_fix

Configure the operating system to disable the user list at logon for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: Note: The example below is using the database "local" for the system, so if the system is using another database in "/etc/dconf/profile/user", the file should be created under the appropriate subdirectory. $ sudo touch /etc/dconf/db/local.d/02-login-screen [org/gnome/login-screen] disable-user-list=true Update the system databases: $ sudo dconf update

b
TOSS must display the date and time of the last successful account logon upon an SSH logon.
CM-6 - Medium - CCI-000366 - V-252965 - SV-252965r824219_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-020260
Vuln IDs
  • V-252965
Rule IDs
  • SV-252965r824219_rule
Providing users with feedback on when account accesses via SSH last occurred facilitates user recognition and reporting of unauthorized account use.
Checks: C-56418r824217_chk

Verify SSH provides users with feedback on when account accesses last occurred with the following command: $ sudo grep -i printlastlog /etc/ssh/sshd_config PrintLastLog yes If the "PrintLastLog" keyword is set to "no", is missing, or is commented out, this is a finding.

Fix: F-56368r824218_fix

Configure SSH to provide users with feedback on when account accesses last occurred by setting the required configuration options in "/etc/pam.d/sshd" or in the "sshd_config" file used by the system ("/etc/ssh/sshd_config" will be used in the example) (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). Modify the "PrintLastLog" line in "/etc/ssh/sshd_config" to match the following: PrintLastLog yes The SSH service must be restarted for changes to "sshd_config" to take effect.

c
TOSS must not allow accounts configured with blank or null passwords.
CM-6 - High - CCI-000366 - V-252966 - SV-252966r824222_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
TOSS-04-020270
Vuln IDs
  • V-252966
Rule IDs
  • SV-252966r824222_rule
If an account has an empty password, anyone could log on and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.
Checks: C-56419r824220_chk

To verify that null passwords cannot be used, run the following command: $ sudo grep -i permitemptypasswords /etc/ssh/sshd_config PermitEmptyPasswords no If "PermitEmptyPasswords" is set to "yes", this is a finding.

Fix: F-56369r824221_fix

Edit the following line in "etc/ssh/sshd_config" to prevent logons with empty passwords. PermitEmptyPasswords no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b
TOSS must not have unnecessary accounts.
CM-6 - Medium - CCI-000366 - V-252967 - SV-252967r824225_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-020280
Vuln IDs
  • V-252967
Rule IDs
  • SV-252967r824225_rule
Accounts providing no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.
Checks: C-56420r824223_chk

Verify all accounts on the system are assigned to an active system, application, or user account. Obtain the list of authorized system accounts from the Information System Security Officer (ISSO). Check the system accounts on the system with the following command: $ sudo more /etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt games:x:12:100:games:/usr/games:/sbin/nologin gopher:x:13:30:gopher:/var/gopher:/sbin/nologin Accounts such as "games" and "gopher" are not authorized accounts as they do not support authorized system functions. If the accounts on the system do not match the provided documentation, or accounts that do not support an authorized system function are present, this is a finding.

Fix: F-56370r824224_fix

Configure the system so all accounts on the system are assigned to an active system, application, or user account. Remove accounts that do not support approved system activities or that allow for a normal user to perform administrative-level actions. Document all authorized accounts on the system.

b
TOSS must define default permissions for all authenticated users in such a way that the user can only read and modify their own files.
CM-6 - Medium - CCI-000366 - V-252968 - SV-252968r824228_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-020290
Vuln IDs
  • V-252968
Rule IDs
  • SV-252968r824228_rule
Setting the most restrictive default permissions ensures that when new accounts are created, they do not have unnecessary access.
Checks: C-56421r824226_chk

Verify TOSS defines default permissions for all authenticated users in such a way that the user can only read and modify their own files. Check for the value of the "UMASK" parameter in "/etc/login.defs" file with the following command: Note: If the value of the "UMASK" parameter is set to "000" in "/etc/login.defs" file, the Severity is raised to a CAT I. $ grep -i umask /etc/login.defs UMASK 077 If the value for the "UMASK" parameter is not "077", or the "UMASK" parameter is missing or is commented out, this is a finding.

Fix: F-56371r824227_fix

Configure TOSS to define default permissions for all authenticated users in such a way that the user can only read and modify their own files. Add or edit the line for the "UMASK" parameter in "/etc/login.defs" file to "077": UMASK 077

b
All TOSS local interactive user home directories must have mode 0770 or less permissive.
CM-6 - Medium - CCI-000366 - V-252969 - SV-252969r824231_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-020300
Vuln IDs
  • V-252969
Rule IDs
  • SV-252969r824231_rule
Users' home directories/folders may contain information of a sensitive nature. Non-privileged users should coordinate any sharing of information with an SA through shared resources.
Checks: C-56422r824229_chk

Verify the operating system limits the ability of non-privileged users to grant other users direct access to the contents of their home directories/folders. Ensure that the user permissions on all user home directories is set to 770 permissions with the following command: $ find $(awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){print $6}' /etc/passwd) -maxdepth 0 -not -perm 770 -ls If there is any output, this is a finding.

Fix: F-56372r824230_fix

Change the mode of interactive user's home directories to "0770." To change the mode of a local interactive user's home directory, use the following command: Note: The example will be for the user "smithj." $ sudo chmod 0770 /home/smithj

b
All TOSS local interactive user home directories must be owned by root.
CM-6 - Medium - CCI-000366 - V-252970 - SV-252970r824234_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-020310
Vuln IDs
  • V-252970
Rule IDs
  • SV-252970r824234_rule
Users' home directories/folders may contain information of a sensitive nature. Non-privileged users should coordinate any sharing of information with an SA through shared resources.
Checks: C-56423r824232_chk

Check that all user home directories are owned by the root user with the following command: $ find $(awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){print $6}' /etc/passwd) -maxdepth 0 -not -user root -ls If there is any output, this is a finding.

Fix: F-56373r824233_fix

Change the owner of interactive user's home directories to root. To change the owner of a local interactive user's home directory, use the following command: Note: The example will be for the user "smithj." $ sudo chown root /home/smithj

b
All TOSS local interactive user home directories must be owned by the user's primary group.
CM-6 - Medium - CCI-000366 - V-252971 - SV-252971r824237_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-020320
Vuln IDs
  • V-252971
Rule IDs
  • SV-252971r824237_rule
Users' home directories/folders may contain information of a sensitive nature. Non-privileged users should coordinate any sharing of information with an SA through shared resources.
Checks: C-56424r824235_chk

Check that all user home directories are owned by the user's primary group with the following command: $ awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/)&amp;&amp;("stat -c '%g' " $6 | getline dir_group)&amp;&amp;(dir_group!=$4){print $1,$6}' /etc/passwd admin /home/admin Check each user's primary group with the following command (example command is for the "admin" user): $ sudo grep "^admin" /etc/group admin:x:250:smithj,jonesj,jacksons If the user home directory referenced in "/etc/passwd" is not group-owned by that user's primary GID, this is a finding.

Fix: F-56374r824236_fix

Change the group owner of interactive user's home directories to that users primary group. To change the group owner of a local interactive user's home directory, use the following command: Note: The example will be for the user "smithj." $ sudo chgrp smithj /home/smithj

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow.
AC-2 - Medium - CCI-000018 - V-252972 - SV-252972r824240_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000018
Version
TOSS-04-030000
Vuln IDs
  • V-252972
Rule IDs
  • SV-252972r824240_rule
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to modify an existing account. Auditing account modification actions provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221
Checks: C-56425r824238_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow." Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/shadow /etc/audit/audit.rules -w /etc/shadow -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier. The string following "-k" does not need to match the example output above.

Fix: F-56375r824239_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow." Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/shadow -p wa -k identity The audit daemon must be restarted for the changes to take effect. Note: The "-k" allows for specifying an arbitrary identifier. The string following "-k" does not need to match the example output above.

b
TOSS audit records must contain information to establish what type of events occurred, when the events occurred, the source of events, where events occurred, and the outcome of events.
AU-3 - Medium - CCI-000130 - V-252973 - SV-252973r824243_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030010
Vuln IDs
  • V-252973
Rule IDs
  • SV-252973r824243_rule
Without establishing what type of events occurred, when events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in TOSS audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured TOSS system. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000047-GPOS-00023, SRG-OS-000051-GPOS-00024, SRG-OS-000064-GPOS-00033, SRG-OS-000241-GPOS-00091, SRG-OS-000254-GPOS-00095, SRG-OS-000327-GPOS-00127, SRG-OS-000342-GPOS-00133, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000365-GPOS-00152, SRG-OS-000474-GPOS-00219, SRG-OS-000479-GPOS-00224
Checks: C-56426r824241_chk

Verify the audit service is configured to produce audit records. Check that the audit service is installed properly with the following command: $ sudo yum list installed audit If the "audit" package is not installed, this is a finding. Check that the audit service is properly running and active on the system with the following command: $ sudo systemctl is-active auditd.service active If the command above returns "inactive", this is a finding.

Fix: F-56376r824242_fix

Configure the audit service to produce audit records containing the information needed to establish when (date and time) an event occurred. Install the audit service (if the audit service is not already installed) with the following command: $ sudo yum install audit Enable the audit service with the following command: $ sudo systemctl enable auditd.service Start the audit service with the following command: $ sudo systemctl start auditd.service

b
TOSS must generate audit records containing the full-text recording of privileged commands.
AU-3 - Medium - CCI-000135 - V-252974 - SV-252974r824246_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000135
Version
TOSS-04-030060
Vuln IDs
  • V-252974
Rule IDs
  • SV-252974r824246_rule
Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information. At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Checks: C-56427r824244_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "sudo" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w sudo /etc/audit/audit.rules -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid&gt;=1000 -F auid!=unset -k priv_cmd If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56377r824245_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "sudo" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect.

b
TOSS must alert the ISSO and SA (at a minimum) in the event of an audit processing failure.
AU-5 - Medium - CCI-000139 - V-252975 - SV-252975r824249_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000139
Version
TOSS-04-030080
Vuln IDs
  • V-252975
Rule IDs
  • SV-252975r824249_rule
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.
Checks: C-56428r824247_chk

Verify that the SA and ISSO (at a minimum) are notified in the event of an audit processing failure. Check that TOSS notifies the SA and ISSO (at a minimum) in the event of an audit processing failure with the following command: $ sudo grep action_mail_acct /etc/audit/auditd.conf action_mail_acct = root If the value of the "action_mail_acct" keyword is not set to "root" and/or other accounts for security personnel, the "action_mail_acct" keyword is missing, or the retuned line is commented out, ask the system administrator to indicate how they and the ISSO are notified of an audit process failure. If there is no evidence of the proper personnel being notified of an audit processing failure, this is a finding.

Fix: F-56378r824248_fix

Configure "auditd" service to notify the SA and ISSO in the event of an audit processing failure. Edit the following line in "/etc/audit/auditd.conf" to ensure that administrators are notified via email for those situations: action_mail_acct = root

b
TOSS must take appropriate action when an audit processing failure occurs.
AU-5 - Medium - CCI-000140 - V-252976 - SV-252976r824252_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000140
Version
TOSS-04-030090
Vuln IDs
  • V-252976
Rule IDs
  • SV-252976r824252_rule
It is critical that when the operating system is at risk of failing to process audit logs as required, it takes action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. When availability is an overriding concern, other approved actions in response to an audit failure are as follows: 1) If the failure was caused by the lack of audit record storage capacity, the operating system must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner. 2) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the operating system must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.
Checks: C-56429r824250_chk

Verify TOSS takes the appropriate action when an audit processing failure occurs. Check that TOSS takes the appropriate action when an audit processing failure occurs with the following command: $ sudo grep disk_error_action /etc/audit/auditd.conf disk_error_action = HALT If the value of the "disk_error_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, ask the system administrator to indicate how the system takes appropriate action when an audit process failure occurs. If there is no evidence of appropriate action, this is a finding.

Fix: F-56379r824251_fix

Configure TOSS to shut down by default upon audit failure (unless availability is an overriding concern). Add or update the following line (depending on configuration "disk_error_action" can be set to "SYSLOG" or "SINGLE" depending on configuration) in "/etc/audit/auditd.conf" file: disk_error_action = HALT If availability has been determined to be more important, and this decision is documented with the ISSO, configure the operating system to notify system administration staff and ISSO staff in the event of an audit processing failure by setting the "disk_error_action" to "SYSLOG."

b
TOSS audit logs must have a mode of 0600 or less permissive to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252977 - SV-252977r824255_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
TOSS-04-030120
Vuln IDs
  • V-252977
Rule IDs
  • SV-252977r824255_rule
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56430r824253_chk

Verify the audit logs have a mode of "0600" or less permissive. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the location of the audit log file, check if the audit log has a mode of "0600" or less permissive with the following command: $ sudo ls -l /var/log/audit/audit.log -rw------- 1 root root 908084 Jul 19 23:10 /var/log/audit/audit.log If the audit log has a mode more permissive than "0600", this is a finding.

Fix: F-56380r824254_fix

Configure the audit log to be protected from unauthorized read access by setting the correct permissive mode with the following command: $ sudo chmod 0600 [audit_log_file] Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log."

b
TOSS audit log directory must have a mode of 0700 or less permissive to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252978 - SV-252978r824258_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
TOSS-04-030130
Vuln IDs
  • V-252978
Rule IDs
  • SV-252978r824258_rule
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56431r824256_chk

Verify the audit log directory has a mode of "0700" or less permissive. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the directory where the audit log file is located, check if the audit log directory has a mode of "0700" or less permissive with the following command: $ sudo ls -ld /var/log/audit/ drwx------. 2 root root 99 Jul 19 07:32 /var/log/audit/ If the audit log directory has a mode more permissive than "0700", this is a finding.

Fix: F-56381r824257_fix

Configure the audit log directory to be protected from unauthorized read access by setting the correct permissive mode with the following command: $ sudo chmod 0700 [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit."

b
TOSS audit logs must be owned by user root to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252979 - SV-252979r824261_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
TOSS-04-030140
Vuln IDs
  • V-252979
Rule IDs
  • SV-252979r824261_rule
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56432r824259_chk

Verify the audit logs are owned by user root. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the location of the audit log file, check if the audit log is owned by user "root" with the following command: $ sudo ls -l /var/log/audit/audit.log -rw------- 1 root root 908084 Jul 19 23:10 /var/log/audit/audit.log If the audit log is not owned by user "root", this is a finding.

Fix: F-56382r824260_fix

Configure the audit log and audit log directory to be protected from unauthorized read access, by setting the correct owner as "root" with the following command: $ sudo chown root [audit_log_file] Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log." Configure the audit log to be owned by root by configuring the log group in the /etc/audit/auditd.conf file: log_group = root

b
TOSS audit logs must be owned by group root to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252980 - SV-252980r824264_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
TOSS-04-030150
Vuln IDs
  • V-252980
Rule IDs
  • SV-252980r824264_rule
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56433r824262_chk

Verify the audit logs are owned by group root. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the location of the audit log file, check if the audit log is owned by group "root" with the following command: $ sudo ls -l /var/log/audit/audit.log -rw------- 1 root root 908084 Jul 19 23:10 /var/log/audit/audit.log If the audit log is not owned by group "root", this is a finding.

Fix: F-56383r824263_fix

Configure the audit log and audit log directory to be protected from unauthorized read access, by setting the correct owner as "root" with the following command: $ sudo chgrp root [audit_log_file] Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log." Configure the audit log to be owned by root by configuring the log group in the /etc/audit/auditd.conf file: log_group = root

b
TOSS audit log directory must be owned by user root to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252981 - SV-252981r824267_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
TOSS-04-030160
Vuln IDs
  • V-252981
Rule IDs
  • SV-252981r824267_rule
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56434r824265_chk

Verify the audit log directory is owned by user root. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the directory where the audit log file is located, check if the directory is owned by user "root" with the following command: $ sudo ls -ld /var/log/audit/ drwx------. 2 root root 99 Jul 19 07:32 /var/log/audit/ If the audit log directory is not owned by user "root", this is a finding.

Fix: F-56384r824266_fix

Configure the audit log directory to be protected from unauthorized read access, by setting the correct owner as "root" with the following command: $ sudo chown root [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit/."

b
TOSS audit log directory must be owned by group root to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252982 - SV-252982r824270_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
TOSS-04-030170
Vuln IDs
  • V-252982
Rule IDs
  • SV-252982r824270_rule
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56435r824268_chk

Verify the audit log directory is owned by group root. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the directory where the audit log file is located, check if the directory is owned by group "root" with the following command: $ sudo ls -ld /var/log/audit/ drwx------. 2 root root 99 Jul 19 07:32 /var/log/audit/ If the audit log directory is not owned by group "root", this is a finding.

Fix: F-56385r824269_fix

Configure the audit log directory to be protected from unauthorized read access, by setting the correct group as "root" with the following command: $ sudo chgrp root [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit/."

b
The TOSS audit system must protect auditing rules from unauthorized change.
AU-9 - Medium - CCI-000162 - V-252983 - SV-252983r824273_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
TOSS-04-030180
Vuln IDs
  • V-252983
Rule IDs
  • SV-252983r824273_rule
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit TOSS system activity. In immutable mode, unauthorized users cannot execute changes to the audit system to potentially hide malicious activity and then put the audit rules back. A system reboot would be noticeable and a system administrator could then investigate the unauthorized changes. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56436r824271_chk

Verify the audit system prevents unauthorized changes with the following command: $ sudo grep "^\s*[^#]" /etc/audit/audit.rules | tail -1 -e 2 If the audit system is not set to be immutable by adding the "-e 2" option to the "/etc/audit/audit.rules", this is a finding.

Fix: F-56386r824272_fix

Configure the audit system to set the audit rules to be immutable by adding the following line to the end of "/etc/audit/rules.d/audit.rules": -e 2 Note: Once set, the system must be rebooted for auditing to be changed. It is recommended to add this option as the last step in securing the system.

b
The TOSS audit system must protect logon UIDs from unauthorized change.
AU-9 - Medium - CCI-000162 - V-252984 - SV-252984r824276_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
TOSS-04-030190
Vuln IDs
  • V-252984
Rule IDs
  • SV-252984r824276_rule
Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit TOSS system activity. In immutable mode, unauthorized users cannot execute changes to the audit system to potentially hide malicious activity and then put the audit rules back. A system reboot would be noticeable and a system administrator could then investigate the unauthorized changes. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56437r824274_chk

Verify the audit system prevents unauthorized changes to logon UIDs with the following command: $ sudo grep -i immutable /etc/audit/audit.rules --loginuid-immutable If the login UIDs are not set to be immutable by adding the "--loginuid-immutable" option to the "/etc/audit/audit.rules", this is a finding.

Fix: F-56387r824275_fix

Configure the audit system to set the logon UIDs to be immutable by adding the following line to "/etc/audit/rules.d/audit.rules": --loginuid-immutable

b
Successful/unsuccessful uses of the "chage" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252985 - SV-252985r824279_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030310
Vuln IDs
  • V-252985
Rule IDs
  • SV-252985r824279_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "chage" command is used to change or view user password expiry information. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56438r824277_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chage" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chage /etc/audit/audit.rules -a always,exit -F path=/usr/bin/chage -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-chage If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56388r824278_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chage" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chage The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "chcon" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252986 - SV-252986r824282_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030320
Vuln IDs
  • V-252986
Rule IDs
  • SV-252986r824282_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "chcon" command is used to change file SELinux security context. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56439r824280_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chcon" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chcon /etc/audit/audit.rules -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56389r824281_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chcon" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the ssh-agent in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252987 - SV-252987r824285_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030330
Vuln IDs
  • V-252987
Rule IDs
  • SV-252987r824285_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "ssh-agent" is a program to hold private keys used for public key authentication. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56440r824283_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "ssh-agent" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep ssh-agent /etc/audit/audit.rules -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-ssh If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56390r824284_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-agent" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "passwd" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252988 - SV-252988r824288_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030340
Vuln IDs
  • V-252988
Rule IDs
  • SV-252988r824288_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "passwd" command is used to change passwords for user accounts. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56441r824286_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "passwd" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w passwd /etc/audit/audit.rules -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-passwd If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56391r824287_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "passwd" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-passwd The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of postdrop in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252989 - SV-252989r824291_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030350
Vuln IDs
  • V-252989
Rule IDs
  • SV-252989r824291_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "postdrop" command creates a file in the maildrop directory and copies its standard input to the file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56442r824289_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "postdrop" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "postdrop" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56392r824290_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "postdrop" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of postqueue in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252990 - SV-252990r824294_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030360
Vuln IDs
  • V-252990
Rule IDs
  • SV-252990r824294_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "postqueue" command implements the Postfix user interface for queue management. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56443r824292_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "postqueue" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "postqueue" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56393r824293_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "postqueue" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of setsebool in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252991 - SV-252991r824297_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030370
Vuln IDs
  • V-252991
Rule IDs
  • SV-252991r824297_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "setsebool" command sets the current state of a particular SELinux boolean or a list of booleans to a given value. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56444r824295_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "setsebool" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "setsebool" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56394r824296_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setsebool" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the ssh-keysign in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252992 - SV-252992r824300_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030380
Vuln IDs
  • V-252992
Rule IDs
  • SV-252992r824300_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "ssh-keysign" program is an SSH helper program for host-based authentication. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56445r824298_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "ssh-keysign" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep ssh-keysign /etc/audit/audit.rules -a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-ssh If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56395r824299_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-keysign" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "setfacl" command in RTOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252993 - SV-252993r824303_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030390
Vuln IDs
  • V-252993
Rule IDs
  • SV-252993r824303_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "setfacl" command is used to set file access control lists. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56446r824301_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "setfacl" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w setfacl /etc/audit/audit.rules -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56396r824302_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setfacl" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "pam_timestamp_check" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252994 - SV-252994r824306_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030400
Vuln IDs
  • V-252994
Rule IDs
  • SV-252994r824306_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "pam_timestamp_check" command is used to check if the default timestamp is valid. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56447r824304_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "pam_timestamp_check" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w pam_timestamp_check /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-pam_timestamp_check If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56397r824305_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "pam_timestamp_check" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -k privileged-pam_timestamp_check The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "newgrp" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252995 - SV-252995r824309_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030410
Vuln IDs
  • V-252995
Rule IDs
  • SV-252995r824309_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "newgrp" command is used to change the current group ID during a login session. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56448r824307_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "newgrp" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w newgrp /etc/audit/audit.rules -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid&gt;=1000 -F auid!=unset -k priv_cmd If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56398r824308_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "newgrp" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "init_module" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252996 - SV-252996r824312_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030420
Vuln IDs
  • V-252996
Rule IDs
  • SV-252996r824312_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "init_module" command is used to load a kernel module. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56449r824310_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "init_module" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "init_module" /etc/audit/audit.rules -a always,exit -F arch=b32 -S init_module -F auid&gt;=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S init_module -F auid&gt;=1000 -F auid!=unset -k module_chng If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56399r824311_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "init_module" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S init_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S init_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "rename" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252997 - SV-252997r824315_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030430
Vuln IDs
  • V-252997
Rule IDs
  • SV-252997r824315_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "rename" command will rename the specified files by replacing the first occurrence of expression in their name by replacement. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56450r824313_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "rename" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "rename" /etc/audit/audit.rules -a always,exit -F arch=b32 -S rename -F auid&gt;=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rename -F auid&gt;=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56400r824314_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "rename" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S rename -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rename -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "renameat" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252998 - SV-252998r824318_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030440
Vuln IDs
  • V-252998
Rule IDs
  • SV-252998r824318_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "renameat" command renames a file, moving it between directories if required. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56451r824316_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "renameat" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "renameat" /etc/audit/audit.rules -a always,exit -F arch=b32 -S renameat -F auid&gt;=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S renameat -F auid&gt;=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56401r824317_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "renameat" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S renameat -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S renameat -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "rmdir" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252999 - SV-252999r824321_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030450
Vuln IDs
  • V-252999
Rule IDs
  • SV-252999r824321_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "rmdir" command removes empty directories. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56452r824319_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "rmdir" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "rmdir" /etc/audit/audit.rules -a always,exit -F arch=b32 -S rmdir -F auid&gt;=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rmdir -F auid&gt;=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56402r824320_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "rmdir" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S rmdir -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rmdir -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "unlink" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253000 - SV-253000r824324_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030460
Vuln IDs
  • V-253000
Rule IDs
  • SV-253000r824324_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "unlink" command deletes a name from the filesystem. If that name was the last link to a file and no processes have the file open, the file is deleted and the space it was using is made available for reuse. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56453r824322_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "unlink" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "unlink" /etc/audit/audit.rules -a always,exit -F arch=b32 -S unlink -F auid&gt;=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlink -F auid&gt;=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56403r824323_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "unlink" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S unlink -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlink -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "unlinkat" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253001 - SV-253001r824327_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030470
Vuln IDs
  • V-253001
Rule IDs
  • SV-253001r824327_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "unlinkat" system call operates in exactly the same way as either "unlink" or "rmdir" except for the differences described in the manual page. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56454r824325_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "unlinkat" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "unlinkat" /etc/audit/audit.rules -a always,exit -F arch=b32 -S unlinkat -F auid&gt;=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlinkat -F auid&gt;=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56404r824326_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "unlinkat" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S unlinkat -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlinkat -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "finit_module" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253002 - SV-253002r824330_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030480
Vuln IDs
  • V-253002
Rule IDs
  • SV-253002r824330_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "finit_module" command is used to load a kernel module. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56455r824328_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "finit_module" syscall by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "finit_module" /etc/audit/audit.rules -a always,exit -F arch=b32 -S finit_module -F auid&gt;=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S finit_module -F auid&gt;=1000 -F auid!=unset -k module_chng If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56405r824329_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "finit_module" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S finit_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S finit_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "delete_module" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253003 - SV-253003r824333_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030490
Vuln IDs
  • V-253003
Rule IDs
  • SV-253003r824333_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "delete_module" command is used to unload a kernel module. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56456r824331_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "delete_module" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "delete_module" /etc/audit/audit.rules -a always,exit -F arch=b32 -S delete_module -F auid&gt;=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid&gt;=1000 -F auid!=unset -k module_chng If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56406r824332_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "delete_module" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "crontab" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253004 - SV-253004r824336_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030500
Vuln IDs
  • V-253004
Rule IDs
  • SV-253004r824336_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "crontab" command is used to maintain crontab files for individual users. Crontab is the program used to install, remove, or list the tables used to drive the cron daemon. This is similar to the task scheduler used in other operating systems. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56457r824334_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "crontab" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w crontab /etc/audit/audit.rules -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-crontab If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56407r824335_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "crontab" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -k privileged-crontab The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "chsh" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253005 - SV-253005r824339_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030510
Vuln IDs
  • V-253005
Rule IDs
  • SV-253005r824339_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "chsh" command is used to change the login shell. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56458r824337_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chsh" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chsh /etc/audit/audit.rules -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid&gt;=1000 -F auid!=unset -k priv_cmd If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56408r824338_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chsh" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of setfiles in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253006 - SV-253006r824342_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030520
Vuln IDs
  • V-253006
Rule IDs
  • SV-253006r824342_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "setfiles" command is primarily used to initialize the security context fields (extended attributes) on one or more filesystems (or parts of them). Usually, it is initially run as part of the SELinux installation process (a step commonly known as labeling). When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56459r824340_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "setfiles" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "setfiles" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56409r824341_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setfiles" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "chacl" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253007 - SV-253007r824345_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TOSS-04-030540
Vuln IDs
  • V-253007
Rule IDs
  • SV-253007r824345_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "chacl" command is used to change the access control list of a file or directory. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56460r824343_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chacl" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chacl /etc/audit/audit.rules -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56410r824344_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chacl" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
TOSS must allow only the Information System Security Manager (ISSM) (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.
AU-12 - Medium - CCI-000171 - V-253008 - SV-253008r824348_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000171
Version
TOSS-04-030550
Vuln IDs
  • V-253008
Rule IDs
  • SV-253008r824348_rule
Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Checks: C-56461r824346_chk

Verify that the files in directory "/etc/audit/rules.d/" and "/etc/audit/auditd.conf" file have a mode of "0640" or less permissive by using the following commands: $ sudo ls -l /etc/audit/rules.d -rw-r----- 1 root root 1280 Feb 16 17:09 audit.rules $ sudo ls -l /etc/audit/auditd.conf -rw-r----- 1 root root 621 Sep 22 17:19 auditd.conf If the files in the "/etc/audit/rules.d/" directory or the "/etc/audit/auditd.conf" file have a mode more permissive than "0640", this is a finding.

Fix: F-56411r824347_fix

Configure the files in directory "/etc/audit/rules.d/" and the "/etc/audit/auditd.conf" file to have a mode of "0640" with the following commands: $ sudo chmod 0640 /etc/audit/rules.d/audit.rules $ sudo chmod 0640 /etc/audit/rules.d/[customrulesfile].rules $ sudo chmod 0640 /etc/audit/auditd.conf

b
Successful/unsuccessful uses of the chmod system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253009 - SV-253009r824351_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030560
Vuln IDs
  • V-253009
Rule IDs
  • SV-253009r824351_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "chmod" system calls are used to change file permissions. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56462r824349_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "chmod" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chmod /etc/audit/audit.rules -a always,exit -F arch=b32 -S chmod -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chmod -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56412r824350_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chmod" command by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the chown system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253010 - SV-253010r824354_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030570
Vuln IDs
  • V-253010
Rule IDs
  • SV-253010r824354_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "chown" system call is used to change file owner and group. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56463r824352_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "chown" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chown /etc/audit/audit.rules -a always,exit -F arch=b32 -S chown -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chown -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56413r824353_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chown" command by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the creat system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253011 - SV-253011r824357_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030580
Vuln IDs
  • V-253011
Rule IDs
  • SV-253011r824357_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "creat" system call is used to open and possibly create a file or device. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56464r824355_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "creat" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw creat /etc/audit/audit.rules -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56414r824356_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "creat" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the fchmod system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253012 - SV-253012r824360_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030590
Vuln IDs
  • V-253012
Rule IDs
  • SV-253012r824360_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "fchmod" system call is used to change permissions of a file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56465r824358_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "fchmod" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w fchmod /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchmod -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56415r824359_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmod" system call by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the fchmodat system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253013 - SV-253013r824363_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030600
Vuln IDs
  • V-253013
Rule IDs
  • SV-253013r824363_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "fchmodat" system call is used to change permissions of a file relative to a directory file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56466r824361_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "fchmodat" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w fchmodat /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchmodat -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56416r824362_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmodat" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the fchown system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253014 - SV-253014r824366_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030610
Vuln IDs
  • V-253014
Rule IDs
  • SV-253014r824366_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "fchown" system call is used to change the ownership of a file referred to by the open file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56467r824364_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "fchown" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w fchown /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchown -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56417r824365_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchown" system call by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the fchownat system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253015 - SV-253015r824369_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030620
Vuln IDs
  • V-253015
Rule IDs
  • SV-253015r824369_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "fchownat" system call is used to change ownership of a file relative to a directory file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56468r824367_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "fchownat" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w fchownat /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchownat -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56418r824368_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchownat" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the ftruncate system call system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253016 - SV-253016r824372_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030630
Vuln IDs
  • V-253016
Rule IDs
  • SV-253016r824372_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "truncate" and "ftruncate" system calls are used to truncate a file to a specified length. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56469r824370_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "ftruncate" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw ftruncate /etc/audit/audit.rules -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56419r824371_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ftruncate" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the lchown system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253017 - SV-253017r824375_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030640
Vuln IDs
  • V-253017
Rule IDs
  • SV-253017r824375_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "lchown" system call is used to change the ownership of the file specified by a path, which does not dereference symbolic links. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56470r824373_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "lchown" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w lchown /etc/audit/audit.rules -a always,exit -F arch=b32 -S lchown -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56420r824374_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "lchown" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the open system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253018 - SV-253018r824378_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030650
Vuln IDs
  • V-253018
Rule IDs
  • SV-253018r824378_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "open system" call opens a file specified by a pathname. If the specified file does not exist, it may optionally be created by "open." When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56471r824376_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "open" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw open /etc/audit/audit.rules -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56421r824377_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "open" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the open_by_handle_at system call system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253019 - SV-253019r824381_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030660
Vuln IDs
  • V-253019
Rule IDs
  • SV-253019r824381_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "name_to_handle_at" and "open_by_handle_at" system calls split the functionality of openat into two parts: "name_to_handle_at" returns an opaque handle that corresponds to a specified file; "open_by_handle_at" opens the file corresponding to a handle returned by a previous call to "name_to_handle_at" and returns an open file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56472r824379_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "open_by_handle_at" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw open_by_handle_at /etc/audit/audit.rules -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56422r824380_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "open_by_handle_at" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the openat system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253020 - SV-253020r824384_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030670
Vuln IDs
  • V-253020
Rule IDs
  • SV-253020r824384_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "openat" system call opens a file specified by a relative pathname. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56473r824382_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "openat" system calls by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw openat /etc/audit/audit.rules -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56423r824383_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "openat" command by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the truncate system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253021 - SV-253021r824387_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030680
Vuln IDs
  • V-253021
Rule IDs
  • SV-253021r824387_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "truncate" system calls are used to truncate a file to a specified length. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56474r824385_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "truncate" system calls by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw truncate /etc/audit/audit.rules -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56424r824386_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "truncate" system calls by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
TOSS audit tools must be owned by "root".
AU-9 - Medium - CCI-001493 - V-253022 - SV-253022r825980_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001493
Version
TOSS-04-030750
Vuln IDs
  • V-253022
Rule IDs
  • SV-253022r825980_rule
Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099
Checks: C-56475r824736_chk

Verify the audit tools are owned by "root" to prevent any unauthorized access, deletion, or modification. Check the owner of each audit tool by running the following command: $ sudo stat -c "%U %n" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/rsyslogd /sbin/augenrules root /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/rsyslogd root /sbin/augenrules If any of the audit tools are not owned by "root", this is a finding.

Fix: F-56425r825979_fix

Configure the audit tools to be owned by "root", by running the following command: $ sudo chown root [audit_tool] Replace "[audit_tool]" with each audit tool not owned by "root".

b
TOSS must use cryptographic mechanisms to protect the integrity of audit tools.
AU-9 - Medium - CCI-001496 - V-253023 - SV-253023r877393_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001496
Version
TOSS-04-030780
Vuln IDs
  • V-253023
Rule IDs
  • SV-253023r877393_rule
Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit tools include, but are not limited to, vendor-provided and open-source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.
Checks: C-56476r824739_chk

Verify that Advanced Intrusion Detection Environment (AIDE) is properly configured to use cryptographic mechanisms to protect the integrity of audit tools. If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system. Check the selection lines to ensure AIDE is configured to add/check with the following command: $ sudo egrep '(\/usr\/sbin\/(audit|au|rsys))' /etc/aide.conf /usr/sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/rsyslogd p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512 If any of the audit tools listed above do not have an appropriate selection line, ask the system administrator to indicate what cryptographic mechanisms are being used to protect the integrity of the audit tools. If there is no evidence of integrity protection, this is a finding. If any of the audit tools are not installed on the system, the corresponding AIDE rule is not applicable.

Fix: F-56426r824740_fix

Add or update the following lines to "/etc/aide.conf", to protect the integrity of the audit tools. # Audit Tools /usr/sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/rsyslogd p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group".
AC-2 - Medium - CCI-002130 - V-253024 - SV-253024r825983_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002130
Version
TOSS-04-030790
Vuln IDs
  • V-253024
Rule IDs
  • SV-253024r825983_rule
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.
Checks: C-56477r825981_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/group /etc/audit/audit.rules -w /etc/group -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56427r825982_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/group -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow".
AC-2 - Medium - CCI-002130 - V-253025 - SV-253025r825986_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002130
Version
TOSS-04-030800
Vuln IDs
  • V-253025
Rule IDs
  • SV-253025r825986_rule
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.
Checks: C-56478r825984_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/gshadow /etc/audit/audit.rules -w /etc/gshadow -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56428r825985_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/gshadow -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd".
AC-2 - Medium - CCI-002130 - V-253026 - SV-253026r825989_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002130
Version
TOSS-04-030810
Vuln IDs
  • V-253026
Rule IDs
  • SV-253026r825989_rule
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.
Checks: C-56479r825987_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/passwd /etc/audit/audit.rules -w /etc/passwd -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56429r825988_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/passwd -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd".
AC-2 - Medium - CCI-002130 - V-253027 - SV-253027r825992_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002130
Version
TOSS-04-030820
Vuln IDs
  • V-253027
Rule IDs
  • SV-253027r825992_rule
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.
Checks: C-56480r825990_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/security/opasswd /etc/audit/audit.rules -w /etc/security/opasswd -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56430r825991_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/security/opasswd -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers".
AC-2 - Medium - CCI-002130 - V-253028 - SV-253028r825995_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002130
Version
TOSS-04-030840
Vuln IDs
  • V-253028
Rule IDs
  • SV-253028r825995_rule
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.
Checks: C-56481r825993_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/sudoers /etc/audit/audit.rules -w /etc/sudoers -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56431r825994_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/sudoers -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/".
AC-2 - Medium - CCI-002130 - V-253029 - SV-253029r825998_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002130
Version
TOSS-04-030850
Vuln IDs
  • V-253029
Rule IDs
  • SV-253029r825998_rule
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.
Checks: C-56482r825996_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/sudoers.d/ /etc/audit/audit.rules -w /etc/sudoers.d/ -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56432r825997_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/sudoers.d/ -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
The TOSS audit system must prevent all software from executing at higher privilege levels than users executing the software and the audit system must be configured to audit the execution of privileged functions.
AC-6 - Medium - CCI-002233 - V-253030 - SV-253030r824762_rule
RMF Control
AC-6
Severity
Medium
CCI
CCI-002233
Version
TOSS-04-030860
Vuln IDs
  • V-253030
Rule IDs
  • SV-253030r824762_rule
In certain situations, software applications/programs need to execute with elevated privileges to perform required functions. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking such applications/programs, those users are indirectly provided with greater privileges than assigned by the organizations. Some programs and processes are required to operate at a higher privilege level and therefore should be excluded from the organization-defined software list after review. Satisfies: SRG-OS-000326-GPOS-00126, SRG-OS-000327-GPOS-00127
Checks: C-56483r824760_chk

Verify TOSS audits the execution of privileged functions. Check if TOSS is configured to audit the execution of the "execve" system call, by running the following command: $ sudo grep execve /etc/audit/audit.rules -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k execpriv If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56433r824761_fix

Configure TOSS to audit the execution of the "execve" system call. Add or update the following file system rules to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k execpriv The audit daemon must be restarted for the changes to take effect.

b
TOSS must allocate audit record storage capacity to store at least one week's worth of audit records, when audit records are not immediately sent to a central audit record storage facility.
AU-4 - Medium - CCI-001849 - V-253031 - SV-253031r877391_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001849
Version
TOSS-04-030890
Vuln IDs
  • V-253031
Rule IDs
  • SV-253031r877391_rule
In order to ensure TOSS systems have a sufficient storage capacity in which to write the audit logs, TOSS needs to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of TOSS. If an external logging system is used to aggregate and store logs for at least one week, this requirement is Not Applicable.
Checks: C-56484r824763_chk

Verify TOSS allocates audit record storage capacity to store at least one week of audit records when audit records are not immediately sent to a central audit record storage facility. If logs are immediately sent to a central audit record storage facility, this requirement is Not Applicable. Determine to which partition the audit records are being written with the following command: $ sudo grep log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Check the size of the partition to which audit records are written (with the example being /var/log/audit/) with the following command: $ sudo df -h /var/log/audit/audit.log /dev/sda2 24G 10.4G 13.6G 43% /var/log/audit If the audit records are not written to a partition made specifically for audit records (/var/log/audit is a separate partition), determine the amount of space being used by other files in the partition with the following command: $ sudo du -sh [audit_partition] 1.8G /var/log/audit If the audit record partition is not allocated for sufficient storage capacity, this is a finding. Note: The partition size needed to capture a week of audit records is based on the activity level of the system and the total storage capacity available. Typically, 10.0 GB of storage space for audit records should be sufficient.

Fix: F-56434r824764_fix

Allocate enough storage capacity for at least one week of audit records when audit records are not immediately sent to a central audit record storage facility. If audit records are stored on a partition made specifically for audit records, resize the partition with sufficient space to contain one week of audit records. If audit records are not stored on a partition made specifically for audit records, a new partition with sufficient space will need be to be created.

b
The TOSS audit records must be offloaded onto a different system or storage media from the system being audited.
AU-4 - Medium - CCI-001851 - V-253032 - SV-253032r944959_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
TOSS-04-030900
Vuln IDs
  • V-253032
Rule IDs
  • SV-253032r944959_rule
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. TOSS installation media provides "rsyslogd." "rsyslogd" is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "gnutls" (which is a secure communications library implementing the SSL, TLS, and DTLS protocols), and now there is a method to securely encrypt and offload auditing. Rsyslog provides three ways to forward message: the traditional UDP transport, which is extremely lossy but standard; the plain TCP based transport, which loses messages only during certain situations but is widely available; and the RELP transport, which does not lose messages but is currently available only as part of the rsyslogd 3.15.0 and above. Examples of each configuration: UDP *.* @remotesystemname TCP *.* @@remotesystemname RELP *.* :omrelp:remotesystemname:2514 Note that a port number was given as there is no standard port for RELP. Satisfies: SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224
Checks: C-56485r944958_chk

Verify the audit system offloads audit records onto a different system or media from the system being audited with the following command: $ sudo grep @@ /etc/rsyslog.conf /etc/rsyslog.d/*.conf /etc/rsyslog.conf:*.* @@[remoteloggingserver]:[port] If a remote server is not configured, or the line is commented out, ask the System Administrator to indicate how the audit logs are offloaded to a different system or media. If there is no evidence that the audit logs are being offloaded to another system or media, this is a finding.

Fix: F-56435r944959_fix

Multiple software applications other than rsyslog may be used by the system to accomplish this requirement. This Fix assumes rsyslog is used for offloading logs from the system. Configure the operating system to offload audit records onto a different system or media from the system being audited by specifying the remote logging server in "/etc/rsyslog.conf" or "/etc/rsyslog.d/[customfile].conf" with the name or IP address of the log aggregation server. *.* @@[remoteloggingserver]:[port]

b
TOSS must label all off-loaded audit logs before sending them to the central log server.
AU-4 - Medium - CCI-001851 - V-253033 - SV-253033r877390_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
TOSS-04-030910
Vuln IDs
  • V-253033
Rule IDs
  • SV-253033r877390_rule
Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Enriched logging is needed to determine who, what, and when events occur on a system. Without this, determining root cause of an event will be much more difficult. When audit logs are not labeled before they are sent to a central log server, the audit data will not be able to be analyzed and tied back to the correct system. Satisfies: SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224
Checks: C-56486r824769_chk

Verify the TOSS audit Daemon is configured to label all off-loaded audit logs, with the following command: $ sudo grep "name_format" /etc/audit/auditd.conf name_format = hostname If the "name_format" option is not "hostname", "fqd", or "numeric", or the line is commented out, this is a finding.

Fix: F-56436r824770_fix

Edit the /etc/audit/auditd.conf file and add or update the "name_format" option to one of "hostname", "fqd", or "numeric": name_format = hostname The audit daemon must be restarted for changes to take effect.

b
The TOSS audit system must be configured to audit any usage of the "fsetxattr" system call.
AU-12 - Medium - CCI-000172 - V-253034 - SV-253034r824774_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-030990
Vuln IDs
  • V-253034
Rule IDs
  • SV-253034r824774_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). "Fsetxattr" is a system call used to set an extended attribute value. This is used to set extended attributes on a file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The auid representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000463-GPOS-00207
Checks: C-56487r824772_chk

Verify if TOSS is configured to audit the execution of the "fsetxattr" system call, by running the following command: $ sudo grep -w fsetxattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S fsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56437r824773_fix

Configure TOSS to audit the execution of the "fsetxattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
The TOSS audit system must be configured to audit any usage of the "lsetxattr" system call.
AU-12 - Medium - CCI-000172 - V-253035 - SV-253035r824777_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031000
Vuln IDs
  • V-253035
Rule IDs
  • SV-253035r824777_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). "Lsetxattr" is a system call used to set an extended attribute value. This is used to set extended attributes on a symbolic link. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000463-GPOS-00207
Checks: C-56488r824775_chk

Verify if TOSS is configured to audit the execution of the "lsetxattr" system call, by running the following command: $ sudo grep -w lsetxattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S lsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56438r824776_fix

Configure TOSS to audit the execution of the "lsetxattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the fremovexattr system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253036 - SV-253036r824780_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031100
Vuln IDs
  • V-253036
Rule IDs
  • SV-253036r824780_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). "Fremovexattr" is a system call that removes extended attributes. This is used for removal of extended attributes from a file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way.
Checks: C-56489r824778_chk

Verify if TOSS is configured to audit the execution of the "fremovexattr" system call, by running the following command: $ sudo grep -w fremovexattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S fremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56439r824779_fix

Configure TOSS to audit the execution of the "fremovexattr" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "lremovexattr" system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253037 - SV-253037r824783_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031110
Vuln IDs
  • V-253037
Rule IDs
  • SV-253037r824783_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). "Lremovexattr" is a system call that removes extended attributes. This is used for removal of extended attributes from symbolic links. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way.
Checks: C-56490r824781_chk

Verify if TOSS is configured to audit the execution of the "lremovexattr" system call, by running the following command: $ sudo grep -w lremovexattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S lremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56440r824782_fix

Configure TOSS to audit the execution of the "lremovexattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "removexattr" system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253038 - SV-253038r824786_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031120
Vuln IDs
  • V-253038
Rule IDs
  • SV-253038r824786_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). "Removexattr" is a system call that removes extended attributes. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way.
Checks: C-56491r824784_chk

Verify if TOSS is configured to audit the execution of the "removexattr" system call, by running the following command: $ sudo grep -w removexattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S removexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56441r824785_fix

Configure TOSS to audit the execution of the "removexattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful modifications to the "lastlog" file in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253039 - SV-253039r824789_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031130
Vuln IDs
  • V-253039
Rule IDs
  • SV-253039r824789_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). Satisfies: SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218
Checks: C-56492r824787_chk

Verify TOSS generates an audit record when successful/unsuccessful modifications to the "lastlog" file by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w lastlog /etc/audit/audit.rules -w /var/log/lastlog -p wa -k logins If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56442r824788_fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "lastlog" file by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -w /var/log/lastlog -p wa -k logins The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of "semanage" in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253040 - SV-253040r824792_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031140
Vuln IDs
  • V-253040
Rule IDs
  • SV-253040r824792_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "semanage" command is used to configure certain elements of SELinux policy without requiring modification to or recompilation from policy sources.
Checks: C-56493r824790_chk

Verify that an audit event is generated for any successful/unsuccessful use of "semanage" by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "semanage" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56443r824791_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "semanage" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "gpasswd" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253041 - SV-253041r824795_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031150
Vuln IDs
  • V-253041
Rule IDs
  • SV-253041r824795_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "gpasswd" command is used to administer /etc/group and /etc/gshadow. Every group can have administrators, members and a password.
Checks: C-56494r824793_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "gpasswd" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w gpasswd /etc/audit/audit.rules -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56444r824794_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "gpasswd" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "mount" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253042 - SV-253042r824798_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031160
Vuln IDs
  • V-253042
Rule IDs
  • SV-253042r824798_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "mount" command is used to mount a filesystem.
Checks: C-56495r824796_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "mount" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w /usr/bin/mount /etc/audit/audit.rules -a always,exit -F path=/usr/bin/mount -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56445r824797_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "mount" command by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "mount" syscall in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253043 - SV-253043r824801_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031170
Vuln IDs
  • V-253043
Rule IDs
  • SV-253043r824801_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "mount" syscall is used to mount a filesystem.
Checks: C-56496r824799_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "mount" syscall by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "\-S mount" /etc/audit/audit.rules -a always,exit -F arch=b32 -S mount -F auid&gt;=1000 -F auid!=unset -k privileged -a always,exit -F arch=b64 -S mount -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56446r824800_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "mount" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=unset -k privileged -a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "su" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253044 - SV-253044r824804_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031180
Vuln IDs
  • V-253044
Rule IDs
  • SV-253044r824804_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "su" command allows a user to run commands with a substitute user and group ID.
Checks: C-56497r824802_chk

Verify TOSS generates audit records when successful/unsuccessful attempts to use the "su" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w /usr/bin/su /etc/audit/audit.rules -a always,exit -F path=/usr/bin/su -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56447r824803_fix

Configure TOSS to generate audit records when successful/unsuccessful attempts to use the "su" command occur by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "umount" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253045 - SV-253045r824807_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031190
Vuln IDs
  • V-253045
Rule IDs
  • SV-253045r824807_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "umount" command is used to unmount a filesystem.
Checks: C-56498r824805_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "umount" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w /usr/bin/umount /etc/audit/audit.rules -a always,exit -F path=/usr/bin/umount -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56448r824806_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "umount" command by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "unix_update" in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253046 - SV-253046r824810_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031200
Vuln IDs
  • V-253046
Rule IDs
  • SV-253046r824810_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). "unix_update" is a helper program for the "pam_unix" module that updates the password for a given user. It is not intended to be run directly from the command line and logs a security violation if done so.
Checks: C-56499r824808_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "unix_update" by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "unix_update" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56449r824809_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "unix_update" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "usermod" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253047 - SV-253047r824813_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031210
Vuln IDs
  • V-253047
Rule IDs
  • SV-253047r824813_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "usermod" command modifies the system account files to reflect the changes that are specified on the command line.
Checks: C-56500r824811_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "usermod" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w usermod /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56450r824812_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "usermod" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of "unix_chkpwd" in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253048 - SV-253048r824816_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031220
Vuln IDs
  • V-253048
Rule IDs
  • SV-253048r824816_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "unix_chkpwd" command is a helper program for the pam_unix module that verifies the password of the current user. It also checks password and account expiration dates in shadow. It is not intended to be run directly from the command line and logs a security violation if done so.
Checks: C-56501r824814_chk

Verify that an audit event is generated for any successful/unsuccessful use of "unix_chkpwd" by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "unix_chkpwd" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56451r824815_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "unix_chkpwd" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of "userhelper" in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253049 - SV-253049r824819_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031230
Vuln IDs
  • V-253049
Rule IDs
  • SV-253049r824819_rule
Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "userhelper" command is not intended to be run interactively. "Userhelper" provides a basic interface to change a user's password, gecos information, and shell. The main difference between this program and its traditional equivalents (passwd, chfn, chsh) is that prompts are written to standard out to make it easy for a graphical user interface wrapper to interface to it as a child process.
Checks: C-56502r824817_chk

Verify that an audit event is generated for any successful/unsuccessful use of "userhelper" by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "userhelper" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56452r824818_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "userhelper" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "kmod" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253050 - SV-253050r824822_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
TOSS-04-031240
Vuln IDs
  • V-253050
Rule IDs
  • SV-253050r824822_rule
"Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter). The "kmod" command is used to control Linux Kernel modules. Satisfies: SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222
Checks: C-56503r824820_chk

Verify that TOSS is configured to audit the execution of the module management program "kmod", by running the following command: $ sudo grep "/usr/bin/kmod" /etc/audit/audit.rules -a always,exit -F path=/usr/bin/kmod -F perm=x -F auid&gt;=1000 -F auid!=unset -k modules If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56453r824821_fix

Configure TOSS to audit the execution of the module management program "kmod" by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -k modules The audit daemon must be restarted for the changes to take effect.

b
The auditd service must be running in TOSS.
CM-6 - Medium - CCI-000366 - V-253051 - SV-253051r824825_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-031340
Vuln IDs
  • V-253051
Rule IDs
  • SV-253051r824825_rule
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 DoD 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.
Checks: C-56504r824823_chk

Verify the audit service is enabled and active with the following commands: $ sudo systemctl is-enabled auditd enabled $ sudo systemctl is-active auditd active If the service is not "enabled" and "active" this is a finding.

Fix: F-56454r824824_fix

Start the auditd service and enable the auditd service with the following commands: $ sudo systemctl start auditd.service $ sudo systemctl enable auditd.service

b
The TOSS audit system must audit local events.
CM-6 - Medium - CCI-000366 - V-253052 - SV-253052r824828_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-031350
Vuln IDs
  • V-253052
Rule IDs
  • SV-253052r824828_rule
Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.
Checks: C-56505r824826_chk

Verify the TOSS audit Daemon is configured to include local events, with the following command: $ sudo grep local_events /etc/audit/auditd.conf local_events = yes If the value of the "local_events" option is not set to "yes", or the line is commented out, this is a finding.

Fix: F-56455r824827_fix

Configure TOSS to audit local events on the system. Add or update the following line in "/etc/audit/auditd.conf" file: local_events = yes

a
TOSS must resolve audit information before writing to disk.
CM-6 - Low - CCI-000366 - V-253053 - SV-253053r824831_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
TOSS-04-031360
Vuln IDs
  • V-253053
Rule IDs
  • SV-253053r824831_rule
Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Enriched logging aids in making sense of who, what, and when events occur on a system. Without this, determining root cause of an event will be much more difficult.
Checks: C-56506r824829_chk

Verify the TOSS audit daemon is configured to resolve audit information before writing to disk, with the following command: $ sudo grep "log_format" /etc/audit/auditd.conf log_format = ENRICHED If the "log_format" option is not "ENRICHED", or the line is commented out, this is a finding.

Fix: F-56456r824830_fix

Edit the /etc/audit/auditd.conf file and add or update the "log_format" option: log_format = ENRICHED The audit daemon must be restarted for changes to take effect.

b
TOSS must have the packages required for offloading audit logs installed.
CM-6 - Medium - CCI-000366 - V-253054 - SV-253054r826062_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-031370
Vuln IDs
  • V-253054
Rule IDs
  • SV-253054r826062_rule
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. TOSS installation media provides "rsyslogd." "rsyslogd" is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "gnutls" (which is a secure communications library implementing the SSL, TLS, and DTLS protocols), and now there is a method to securely encrypt and offload auditing. Rsyslog provides three ways to forward message: the traditional UDP transport, which is extremely lossy but standard; the plain TCP based transport, which loses messages only during certain situations but is widely available; and the RELP transport, which does not lose messages but is currently available only as part of the rsyslogd 3.15.0 and above. Examples of each configuration: UDP *.* @remotesystemname TCP *.* @@remotesystemname RELP *.* :omrelp:remotesystemname:2514 Note that a port number was given as there is no standard port for RELP.
Checks: C-56507r824832_chk

Verify the operating system has the packages required for offloading audit logs installed with the following commands: $ sudo yum list installed rsyslog rsyslog.x86_64 8.2102.0-5.el8 @AppStream If the "rsyslog" package is not installed, ask the administrator to indicate how audit logs are being offloaded and what packages are installed to support it. If there is no evidence of audit logs being offloaded, this is a finding.

Fix: F-56457r824833_fix

Configure the operating system to offload audit logs by installing the required packages with the following command: $ sudo yum install rsyslog

b
TOSS must have the packages required for encrypting offloaded audit logs installed.
CM-6 - Medium - CCI-000366 - V-253055 - SV-253055r826063_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
TOSS-04-031380
Vuln IDs
  • V-253055
Rule IDs
  • SV-253055r826063_rule
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. TOSS installation media provides "rsyslogd." "rsyslogd" is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "rsyslog-gnutls" (which is a secure communications library implementing the SSL, TLS, and DTLS protocols), and now there is a method to securely encrypt and offload auditing. Rsyslog provides three ways to forward message: the traditional UDP transport, which is extremely lossy but standard; the plain TCP based transport, which loses messages only during certain situations but is widely available; and the RELP transport, which does not lose messages but is currently available only as part of the rsyslogd 3.15.0 and above. Examples of each configuration: UDP *.* @remotesystemname TCP *.* @@remotesystemname RELP *.* :omrelp:remotesystemname:2514 Note that a port number was given as there is no standard port for RELP.
Checks: C-56508r824835_chk

Verify the operating system has the packages required for encrypting offloaded audit logs installed with the following commands: $ sudo yum list installed rsyslog-gnutls rsyslog-gnutls.x86_64 8.2102.0-5.el8 @AppStream If the "rsyslog-gnutls" package is not installed, ask the administrator to indicate how audit logs are being encrypted during offloading and what packages are installed to support it. If there is no evidence of audit logs being encrypted during offloading, this is a finding.

Fix: F-56458r824836_fix

Configure the operating system to encrypt offloaded audit logs by installing the required packages with the following command: $ sudo yum install rsyslog-gnutls

b
TOSS must monitor remote access methods.
AC-17 - Medium - CCI-000067 - V-253056 - SV-253056r824840_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000067
Version
TOSS-04-040010
Vuln IDs
  • V-253056
Rule IDs
  • SV-253056r824840_rule
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 DoD 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).
Checks: C-56509r824838_chk

Verify that TOSS monitors all remote access methods. Check that remote access methods are being logged by running the following command: $ sudo grep -E '(auth.*|authpriv.*|daemon.*)' /etc/rsyslog.conf auth.*;authpriv.*;daemon.* /var/log/secure If any of "auth.*", "authpriv.*" or "daemon.*" are not configured to be logged, this is a finding.

Fix: F-56459r824839_fix

Configure TOSS to monitor all remote access methods by adding or updating the following lines to the "/etc/rsyslog.conf" file: auth.*;authpriv.*;daemon.* /var/log/secure The "rsyslog" service must be restarted for the changes to take effect. To restart the "rsyslog" service, run the following command: $ sudo systemctl restart rsyslog.service

b
TOSS must force a frequent session key renegotiation for SSH connections by the client.
AC-17 - Medium - CCI-000068 - V-253057 - SV-253057r877398_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
TOSS-04-040020
Vuln IDs
  • V-253057
Rule IDs
  • SV-253057r877398_rule
Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. Session key regeneration limits the chances of a session key becoming compromised.
Checks: C-56510r824841_chk

Verify the SSH client is configured to force frequent session key renegotiation with the following command: $ sudo grep -i RekeyLimit /etc/ssh/ssh_config RekeyLimit 1G 1h If "RekeyLimit" does not have a maximum data amount and maximum time defined, is missing or commented out, this is a finding.

Fix: F-56460r824842_fix

Configure the system to force a frequent session key renegotiation for SSH connections by the client by add or modifying the following line in the "/etc/ssh/ssh_config" file: RekeyLimit 1G 1h Restart the SSH daemon for the settings to take effect. $ sudo systemctl restart sshd.service

b
TOSS must force a frequent session key renegotiation for SSH connections to the server.
AC-17 - Medium - CCI-000068 - V-253058 - SV-253058r877398_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
TOSS-04-040030
Vuln IDs
  • V-253058
Rule IDs
  • SV-253058r877398_rule
Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. Session key regeneration limits the chances of a session key becoming compromised.
Checks: C-56511r824844_chk

Verify the SSH server is configured to force frequent session key renegotiation with the following command: $ sudo grep -i RekeyLimit /etc/ssh/sshd_config RekeyLimit 1G 1h If "RekeyLimit" does not have a maximum data amount and maximum time defined, is missing or commented out, this is a finding.

Fix: F-56461r824845_fix

Configure the system to force a frequent session key renegotiation for SSH connections to the server by add or modifying the following line in the "/etc/ssh/sshd_config" file: RekeyLimit 1G 1h Restart the SSH daemon for the settings to take effect. $ sudo systemctl restart sshd.service

c
TOSS must implement NIST FIPS-validated cryptography for the following: to provision digital signatures; to generate cryptographic hashes; and to protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
AC-17 - High - CCI-000068 - V-253059 - SV-253059r877398_rule
RMF Control
AC-17
Severity
High
CCI
CCI-000068
Version
TOSS-04-040040
Vuln IDs
  • V-253059
Rule IDs
  • SV-253059r877398_rule
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. TOSS utilizes GRUB 2 as the default bootloader. Note that GRUB 2 command-line parameters are defined in the "kernelopts" variable of the /boot/grub2/grubenv file for all kernel boot entries. The command "fips-mode-setup" modifies the "kernelopts" variable, which in turn updates all kernel boot entries. The fips=1 kernel option needs to be added to the kernel command line during system installation so that key generation is done with FIPS-approved algorithms and continuous monitoring tests in place. Users must also ensure the system has plenty of entropy during the installation process by moving the mouse around, or if no mouse is available, ensuring that many keystrokes are typed. The recommended amount of keystrokes is 256 and more. Less than 256 keystrokes may generate a non-unique key. Satisfies: SRG-OS-000033-GPOS-00014, SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223
Checks: C-56512r824847_chk

Verify TOSS implements DoD-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: F-56462r824848_fix

Configure the operating system to implement DoD-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.

b
TOSS must enforce password complexity by requiring that at least one upper-case character be used.
IA-5 - Medium - CCI-000192 - V-253060 - SV-253060r824852_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000192
Version
TOSS-04-040050
Vuln IDs
  • V-253060
Rule IDs
  • SV-253060r824852_rule
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that in order to require uppercase characters, without degrading the "minlen" value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."
Checks: C-56513r824850_chk

Verify the value for "ucredit" in "/etc/security/pwquality.conf" with the following command: $ sudo grep ucredit /etc/security/pwquality.conf ucredit = -1 If the value of "ucredit" is a positive number or is commented out, this is a finding.

Fix: F-56463r824851_fix

Configure the operating system to enforce password complexity by requiring that at least one uppercase character be used by setting the "ucredit" option. Add the following line to /etc/security/pwquality.conf (or modify the line to have the required value): ucredit = -1

b
TOSS must enforce password complexity by requiring that at least one lower-case character be used.
IA-5 - Medium - CCI-000193 - V-253061 - SV-253061r824855_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000193
Version
TOSS-04-040060
Vuln IDs
  • V-253061
Rule IDs
  • SV-253061r824855_rule
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that in order to require lower-case characters, without degrading the "minlen" value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."
Checks: C-56514r824853_chk

Verify the value for "lcredit" in "/etc/security/pwquality.conf" with the following command: $ sudo grep lcredit /etc/security/pwquality.conf lcredit = -1 If the value of "lcredit" is a positive number or is commented out, this is a finding.

Fix: F-56464r824854_fix

Configure the operating system to enforce password complexity by requiring that at least one lower-case character be used by setting the "lcredit" option. Add the following line to /etc/security/pwquality.conf (or modify the line to have the required value): lcredit = -1

b
TOSS must enforce password complexity by requiring that at least one numeric character be used.
IA-5 - Medium - CCI-000194 - V-253062 - SV-253062r824858_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000194
Version
TOSS-04-040070
Vuln IDs
  • V-253062
Rule IDs
  • SV-253062r824858_rule
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that in order to require numeric characters, without degrading the minlen value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."
Checks: C-56515r824856_chk

Verify the value for "dcredit" in "/etc/security/pwquality.conf" with the following command: $ sudo grep dcredit /etc/security/pwquality.conf dcredit = -1 If the value of "dcredit" is a positive number or is commented out, this is a finding.

Fix: F-56465r824857_fix

Configure the operating system to enforce password complexity by requiring that at least one numeric character be used by setting the "dcredit" option. Add the following line to /etc/security/pwquality.conf (or modify the line to have the required value): dcredit = -1

b
TOSS must require the change of at least eight characters when passwords are changed.
IA-5 - Medium - CCI-000195 - V-253063 - SV-253063r824861_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000195
Version
TOSS-04-040080
Vuln IDs
  • V-253063
Rule IDs
  • SV-253063r824861_rule
If the operating system allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different. If the password length is an odd number then number of changed characters must be rounded up. For example, a password length of 15 characters must require the change of at least 8 characters. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. The "difok" option sets the number of characters in a password that must not be present in the old password.
Checks: C-56516r824859_chk

Verify the value of the "difok" option in "/etc/security/pwquality.conf" with the following command: $ sudo grep difok /etc/security/pwquality.conf difok = 8 If the value of "difok" is set to less than "8" or is commented out, this is a finding.

Fix: F-56466r824860_fix

Configure the operating system to require the change of at least eight of the total number of characters when passwords are changed by setting the "difok" option. Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): difok = 8

b
TOSS must store only encrypted representations of passwords.
IA-5 - Medium - CCI-000196 - V-253064 - SV-253064r877397_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000196
Version
TOSS-04-040090
Vuln IDs
  • V-253064
Rule IDs
  • SV-253064r877397_rule
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 DoD data may be compromised. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements.
Checks: C-56517r824862_chk

Verify that the TOSS shadow password suite configuration is set to encrypt password with a FIPS 140-2-approved cryptographic hashing algorithm. Check the hashing algorithm that is being used to hash passwords with the following command: $ sudo grep -i crypt /etc/login.defs ENCRYPT_METHOD SHA512 If "ENCRYPT_METHOD" does not equal SHA512 or greater, this is a finding.

Fix: F-56467r824863_fix

Configure TOSS to encrypt all stored passwords. Edit/Modify the following line in the "/etc/login.defs" file and set "ENCRYPT_METHOD" to SHA512. ENCRYPT_METHOD SHA512

b
TOSS must not have the rsh-server package installed.
IA-5 - Medium - CCI-000197 - V-253065 - SV-253065r877396_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000197
Version
TOSS-04-040100
Vuln IDs
  • V-253065
Rule IDs
  • SV-253065r877396_rule
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. The rsh-server service provides an unencrypted remote access service that does not provide for the confidentiality and integrity of user passwords or the remote session and has very weak authentication. Satisfies: SRG-OS-000074-GPOS-00042, SRG-OS-000095-GPOS-00049
Checks: C-56518r824865_chk

Check to see if the rsh-server package is installed with the following command: $ sudo yum list installed rsh-server If the rsh-server package is installed, this is a finding.

Fix: F-56468r824866_fix

Configure the operating system to disable nonessential capabilities by removing the rsh-server package from the system with the following command: $ sudo yum remove rsh-server

b
TOSS must enforce 24 hours/1 day as the minimum password lifetime.
IA-5 - Medium - CCI-000198 - V-253066 - SV-253066r824870_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000198
Version
TOSS-04-040110
Vuln IDs
  • V-253066
Rule IDs
  • SV-253066r824870_rule
Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.
Checks: C-56519r824868_chk

Verify that TOSS enforces 24 hours/1 day as the minimum password lifetime for new user accounts. Check for the value of "PASS_MIN_DAYS" in "/etc/login.defs" with the following command: $ sudo grep -i pass_min_days /etc/login.defs PASS_MIN_DAYS 1 If the "PASS_MIN_DAYS" parameter value is not "1" or greater, or is commented out, this is a finding.

Fix: F-56469r824869_fix

Configure the operating system to enforce 24 hours/1 day as the minimum password lifetime. Add the following line in "/etc/login.defs" (or modify the line to have the required value): PASS_MIN_DAYS 1

b
TOSS must enforce a 60-day maximum password lifetime restriction.
IA-5 - Medium - CCI-000199 - V-253067 - SV-253067r824873_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000199
Version
TOSS-04-040120
Vuln IDs
  • V-253067
Rule IDs
  • SV-253067r824873_rule
Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised.
Checks: C-56520r824871_chk

Verify that TOSS enforces a 60-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 60 If the "PASS_MAX_DAYS" parameter value is greater than "60", or commented out, this is a finding.

Fix: F-56470r824872_fix

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

b
TOSS must prohibit password reuse for a minimum of five generations.
IA-5 - Medium - CCI-000200 - V-253068 - SV-253068r824876_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000200
Version
TOSS-04-040130
Vuln IDs
  • V-253068
Rule IDs
  • SV-253068r824876_rule
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements.
Checks: C-56521r824874_chk

Verify TOSS prohibits password reuse for a minimum of five generations. Check for the value of the "remember" argument in "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" with the following command: $ sudo grep -i remember /etc/pam.d/system-auth /etc/pam.d/password-auth /etc/pam.d/system-auth:password required pam_pwhistory.so use_authtok remember=5 retry=3 /etc/pam.d/password-auth:password required pam_pwhistory.so use_authtok remember=5 retry=3 If either file is missing "pam_pwhistory.so" and does not have the "remember" module argument set, is commented out, or the value of the "remember" module argument is set to less than "5", this is a finding.

Fix: F-56471r824875_fix

Configure TOSS to prohibit password reuse for a minimum of five generations. Add the following line in "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" (or modify the line to have the required value): password required pam_pwhistory.so use_authtok remember=5 retry=3

b
TOSS must enforce a minimum 15-character password length.
IA-5 - Medium - CCI-000205 - V-253069 - SV-253069r824879_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000205
Version
TOSS-04-040140
Vuln IDs
  • V-253069
Rule IDs
  • SV-253069r824879_rule
The shorter the password, the lower the number of possible combinations that need to 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 exponentially increase the time and/or resources required to compromise the password.
Checks: C-56522r824877_chk

Verify TOSS enforces a minimum 15-character password length. The "minlen" option sets the minimum number of characters in a new password. Check for the value of the "minlen" option in "/etc/security/pwquality.conf" with the following command: $ sudo grep minlen /etc/security/pwquality.conf minlen = 15 If the command does not return a "minlen" value of 15 or greater, this is a finding.

Fix: F-56472r824878_fix

Configure TOSS to enforce a minimum 15-character password length. Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): minlen = 15

b
TOSS must cover or disable the built-in or attached camera when not in use.
CM-7 - Medium - CCI-000381 - V-253070 - SV-253070r824882_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040150
Vuln IDs
  • V-253070
Rule IDs
  • SV-253070r824882_rule
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Failing to disconnect from collaborative computing devices (i.e., cameras) can result in subsequent compromises of organizational information. Providing easy methods to physically disconnect from such devices after a collaborative computing session helps to ensure participants actually carry out the disconnect activity without having to go through complex and tedious procedures.
Checks: C-56523r824880_chk

If the device or operating system does not have a camera installed, this requirement is Not Applicable. This requirement is not applicable to mobile devices (smartphones and tablets), where the use of the camera is a local AO decision. This requirement is not applicable to dedicated VTC suites located in approved VTC locations that are centrally managed. For an external camera, if there is not a method for the operator to manually disconnect the camera at the end of collaborative computing sessions, this is a finding. For a built-in camera, the camera must be protected by a camera cover (e.g., laptop camera cover slide) when not in use. If the built-in camera is not protected with a camera cover, or is not physically disabled, this is a finding. If the camera is not disconnected, covered, or physically disabled, determine if it is being disabled via software with the following commands: Determine if the camera is disabled via blacklist with the following command: $ sudo grep blacklist /etc/modprobe.d/* /etc/modprobe.d/blacklist.conf:blacklist uvcvideo Determine if a camera driver is in use with the following command: $ sudo dmesg | grep -i video [ 44.630131] ACPI: Video Device [VGA] [ 46.655714] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/LNXVIDEO:00/input/input7 [ 46.670133] videodev: Linux video capture interface: v2.00 [ 47.226424] uvcvideo: Found UVC 1.00 device WebCam (0402:7675) [ 47.235752] usbcore: registered new interface driver uvcvideo [ 47.235756] USB Video Class driver (1.1.1) If the camera driver blacklist is missing, a camera driver is determined to be in use, and the collaborative computing device has not been authorized for use, this is a finding.

Fix: F-56473r824881_fix

Configure the operating system to disable the built-in or attached camera when not in use. First determine the driver being used by the camera with the following command: $ sudo dmesg | grep -i video [ 44.630131] ACPI: Video Device [VGA] [ 46.655714] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/LNXVIDEO:00/input/input7 [ 46.670133] videodev: Linux video capture interface: v2.00 [ 47.226424] uvcvideo: Found UVC 1.00 device WebCam (0402:7675) [ 47.235752] usbcore: registered new interface driver uvcvideo [ 47.235756] USB Video Class driver (1.1.1) Next, build or modify the "/etc/modprobe.d/blacklist.conf" file by using the following example: ##Disable WebCam blacklist uvcvideo Reboot the system for the settings to take effect.

b
TOSS must disable IEEE 1394 (FireWire) Support.
CM-7 - Medium - CCI-000381 - V-253071 - SV-253071r824885_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040160
Vuln IDs
  • V-253071
Rule IDs
  • SV-253071r824885_rule
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. The IEEE 1394 (FireWire) is a serial bus standard for high-speed real-time communication. Disabling FireWire protects the system against exploitation of any flaws in its implementation.
Checks: C-56524r824883_chk

Verify the operating system disables the ability to load the firewire-core kernel module. $ sudo grep -r firewire-core /etc/modprobe.d/* | grep install install firewire-core /bin/false If the command does not return any output, or the line is commented out, and use of the firewire-core protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the firewire-core kernel module. Check to see if the firewire-core kernel module is disabled with the following command: $ sudo grep -r firewire-core /etc/modprobe.d/* | grep "blacklist" blacklist firewire-core If the command does not return any output or the output is not "blacklist firewire-core", and use of the firewire-core kernel module is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56474r824884_fix

Configure the operating system to disable the ability to use the firewire-core kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install firewire-core /bin/false blacklist firewire-core Reboot the system for the settings to take effect.

b
TOSS must disable mounting of cramfs.
CM-7 - Medium - CCI-000381 - V-253072 - SV-253072r824888_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040170
Vuln IDs
  • V-253072
Rule IDs
  • SV-253072r824888_rule
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Removing support for unneeded filesystem types reduces the local attack surface of the server. Compressed ROM/RAM file system (or cramfs) is a read-only file system designed for simplicity and space efficiency. It is mainly used in embedded and small footprint systems.
Checks: C-56525r824886_chk

Verify the operating system disables the ability to load the cramfs kernel module. $ sudo grep -r cramfs /etc/modprobe.d/* | grep install install cramfs /bin/false If the command does not return any output, or the line is commented out, and use of the cramfs protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the cramfs kernel module. Check to see if the cramfs kernel module is disabled with the following command: $ sudo grep -r cramfs /etc/modprobe.d/* | grep "blacklist" blacklist cramfs If the command does not return any output or the output is not "blacklist cramfs", and use of the cramfs kernel module is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56475r824887_fix

Configure the operating system to disable the ability to use the cramfs kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install cramfs /bin/false blacklist cramfs Reboot the system for the settings to take effect.

b
TOSS must disable network management of the chrony daemon.
CM-7 - Medium - CCI-000381 - V-253073 - SV-253073r824891_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040180
Vuln IDs
  • V-253073
Rule IDs
  • SV-253073r824891_rule
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 DoD and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/dod-customers for more information.
Checks: C-56526r824889_chk

Verify TOSS disables network management of the chrony daemon with the following command: $ sudo grep -w 'cmdport' /etc/chrony.conf cmdport 0 If the "cmdport" option is not set to "0", is commented out or missing, this is a finding.

Fix: F-56476r824890_fix

Configure the operating system disable network management of the chrony daemon by adding/modifying the following line in the /etc/chrony.conf file. cmdport 0

b
TOSS must disable the asynchronous transfer mode (ATM) protocol.
CM-7 - Medium - CCI-000381 - V-253074 - SV-253074r824894_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040190
Vuln IDs
  • V-253074
Rule IDs
  • SV-253074r824894_rule
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Failing to disconnect unused protocols can result in a system compromise. The Asynchronous Transfer Mode (ATM) is a protocol operating on network, data link, and physical layers, based on virtual circuits and virtual paths. Disabling ATM protects the system against exploitation of any flaws in its implementation.
Checks: C-56527r824892_chk

Verify the operating system disables the ability to load the ATM protocol kernel module. $ sudo grep -r atm /etc/modprobe.d/* | grep install install atm /bin/false If the command does not return any output, or the line is commented out, and use of the ATM protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the ATM protocol. Check to see if the ATM protocol is disabled with the following command: $ sudo grep -r atm /etc/modprobe.d/* | grep "blacklist" blacklist atm If the command does not return any output or the output is not "blacklist atm", and use of the ATM protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56477r824893_fix

Configure the operating system to disable the ability to use the ATM protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install atm /bin/false blacklist atm Reboot the system for the settings to take effect.

b
TOSS must disable the controller area network (CAN) protocol.
CM-7 - Medium - CCI-000381 - V-253075 - SV-253075r824897_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040200
Vuln IDs
  • V-253075
Rule IDs
  • SV-253075r824897_rule
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Failing to disconnect unused protocols can result in a system compromise. The Controller Area Network (CAN) is a serial communications protocol, which was initially developed for automotive and is now also used in marine, industrial, and medical applications. Disabling CAN protects the system against exploitation of any flaws in its implementation.
Checks: C-56528r824895_chk

Verify the operating system disables the ability to load the CAN protocol kernel module. $ sudo grep -r can /etc/modprobe.d/* | grep install install can /bin/false If the command does not return any output, or the line is commented out, and use of the CAN protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the CAN protocol. Check to see if the CAN protocol is disabled with the following command: $ sudo grep -r can /etc/modprobe.d/* | grep "blacklist" blacklist can If the command does not return any output or the output is not "blacklist can", and use of the CAN protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56478r824896_fix

Configure the operating system to disable the ability to use the CAN protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install can /bin/false blacklist can Reboot the system for the settings to take effect.

b
TOSS must disable the stream control transmission (SCTP) protocol.
CM-7 - Medium - CCI-000381 - V-253076 - SV-253076r824900_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040210
Vuln IDs
  • V-253076
Rule IDs
  • SV-253076r824900_rule
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Failing to disconnect unused protocols can result in a system compromise. The Stream Control Transmission Protocol (SCTP) is a transport layer protocol, designed to support the idea of message-oriented communication, with several streams of messages within one connection. Disabling SCTP protects the system against exploitation of any flaws in its implementation.
Checks: C-56529r824898_chk

Verify the operating system disables the ability to load the SCTP protocol kernel module. $ sudo grep -r sctp /etc/modprobe.d/* | grep install install sctp /bin/false If the command does not return any output, or the line is commented out, and use of the SCTP protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the SCTP protocol. Check to see if the SCTP protocol is disabled with the following command: $ sudo grep -r sctp /etc/modprobe.d/* | grep "blacklist" blacklist sctp If the command does not return any output or the output is not "blacklist sctp", and use of the SCTP protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56479r824899_fix

Configure the operating system to disable the ability to use the SCTP protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install sctp /bin/false blacklist sctp Reboot the system for the settings to take effect.

b
TOSS must disable the transparent inter-process communication (TIPC) protocol.
CM-7 - Medium - CCI-000381 - V-253077 - SV-253077r824903_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040220
Vuln IDs
  • V-253077
Rule IDs
  • SV-253077r824903_rule
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Failing to disconnect unused protocols can result in a system compromise. The Transparent Inter-Process Communication (TIPC) protocol is designed to provide communications between nodes in a cluster. Disabling TIPC protects the system against exploitation of any flaws in its implementation.
Checks: C-56530r824901_chk

Verify the operating system disables the ability to load the TIPC protocol kernel module. $ sudo grep -r tipc /etc/modprobe.d/* | grep install install tipc /bin/false If the command does not return any output, or the line is commented out, and use of the TIPC protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the TIPC protocol. Check to see if the TIPC protocol is disabled with the following command: $ sudo grep -r tipc /etc/modprobe.d/* | grep "blacklist" blacklist tipc If the command does not return any output or the output is not "blacklist tipc", and use of the TIPC protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56480r824902_fix

Configure the operating system to disable the ability to use the TIPC protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install tipc /bin/false blacklist tipc Reboot the system for the settings to take effect.

b
TOSS must not have any automated bug reporting tools installed.
CM-7 - Medium - CCI-000381 - V-253078 - SV-253078r824906_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040230
Vuln IDs
  • V-253078
Rule IDs
  • SV-253078r824906_rule
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Examples of non-essential capabilities include, but are not limited to, games, software packages, tools, and demonstration software not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled. Verify the operating system is configured to disable non-essential capabilities. The most secure way of ensuring a non-essential capability is disabled is to not have the capability installed.
Checks: C-56531r824904_chk

Check to see if any automated bug reporting packages are installed with the following command: $ sudo yum list installed abrt* If any automated bug reporting package is installed, this is a finding.

Fix: F-56481r824905_fix

Configure the operating system to disable nonessential capabilities by removing automated bug reporting packages from the system with the following command: $ sudo yum remove abrt*

b
TOSS must not have the sendmail package installed.
CM-7 - Medium - CCI-000381 - V-253079 - SV-253079r824909_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040250
Vuln IDs
  • V-253079
Rule IDs
  • SV-253079r824909_rule
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Examples of non-essential capabilities include, but are not limited to, games, software packages, tools, and demonstration software not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled. Verify the operating system is configured to disable non-essential capabilities. The most secure way of ensuring a non-essential capability is disabled is to not have the capability installed.
Checks: C-56532r824907_chk

Check to see if the sendmail package is installed with the following command: $ sudo yum list installed sendmail If the sendmail package is installed, this is a finding.

Fix: F-56482r824908_fix

Configure the operating system to disable non-essential capabilities by removing the sendmail package from the system with the following command: $ sudo yum remove sendmail

b
TOSS must not have the telnet-server package installed.
CM-7 - Medium - CCI-000381 - V-253080 - SV-253080r824912_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
TOSS-04-040260
Vuln IDs
  • V-253080
Rule IDs
  • SV-253080r824912_rule
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Examples of non-essential capabilities include, but are not limited to, games, software packages, tools, and demonstration software not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled. Verify the operating system is configured to disable non-essential capabilities. The most secure way of ensuring a non-essential capability is disabled is to not have the capability installed. The telnet service provides an unencrypted remote access service that does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to log on using this service, the privileged user password could be compromised.
Checks: C-56533r824910_chk

Check to see if the telnet-server package is installed with the following command: $ sudo yum list installed telnet-server If the telnet-server package is installed, this is a finding.

Fix: F-56483r824911_fix

Configure the operating system to disable non-essential capabilities by removing the telnet-server package from the system with the following command: $ sudo yum remove telnet-server

b
TOSS must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.
CM-7 - Medium - CCI-000382 - V-253081 - SV-253081r824915_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
TOSS-04-040270
Vuln IDs
  • V-253081
Rule IDs
  • SV-253081r824915_rule
In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.
Checks: C-56534r824913_chk

Inspect the firewall configuration and running services to verify it is configured to prohibit or restrict the use of functions, ports, protocols, and/or services that are unnecessary or prohibited. Check which services are currently active with the following command: $ sudo firewall-cmd --list-all-zones custom (active) target: DROP icmp-block-inversion: no interfaces: ens33 sources: services: dhcpv6-client dns http https ldaps rpc-bind ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules: Ask the System Administrator for the site or program Ports, Protocols, and Services Management Component Local Service Assessment (PPSM CLSA). Verify the services allowed by the firewall match the PPSM CLSA. If there are additional ports, protocols, or services that are not in the PPSM CLSA, or there are ports, protocols, or services that are prohibited by the PPSM Category Assurance List (CAL), this is a finding.

Fix: F-56484r824914_fix

Update the host's firewall settings and/or running services to comply with the PPSM Component Local Service Assessment (CLSA) for the site or program and the PPSM CAL.

b
TOSS must be configured to disable USB mass storage.
IA-3 - Medium - CCI-000778 - V-253082 - SV-253082r942859_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-000778
Version
TOSS-04-040280
Vuln IDs
  • V-253082
Rule IDs
  • SV-253082r942859_rule
USB mass storage permits easy introduction of unknown devices, thereby facilitating malicious activity. Satisfies: SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163
Checks: C-56535r824916_chk

Verify the operating system disables the ability to load the USB Storage kernel module. $ sudo grep -r usb-storage /etc/modprobe.d/* | grep "install" install usb-storage /bin/false If the command does not return any output, or the line is commented out, and use of USB Storage is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use USB mass storage devices. Check to see if USB mass storage is disabled with the following command: $ sudo grep -r usb-storage /etc/modprobe.d/* | grep "blacklist" blacklist usb-storage If the command does not return any output or the output is not "blacklist usb-storage", and use of USB storage devices is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56485r942858_fix

Configure the operating system to disable the ability to use the USB Storage kernel module. Create a file under "/etc/modprobe.d" with the following command: $ sudo touch /etc/modprobe.d/usb-storage.conf Add the following line to the created file: install usb-storage /bin/false Configure the operating system to disable the ability to use USB mass storage devices. $ sudo vi /etc/modprobe.d/blacklist.conf Add or update the line: blacklist usb-storage

b
TOSS must be configured so that all network connections associated with SSH traffic are terminated at the end of the session or after 10 minutes of inactivity, except to fulfill documented and validated mission requirements.
MA-4 - Medium - CCI-000879 - V-253083 - SV-253083r824921_rule
RMF Control
MA-4
Severity
Medium
CCI
CCI-000879
Version
TOSS-04-040290
Vuln IDs
  • V-253083
Rule IDs
  • SV-253083r824921_rule
Terminating an idle SSH session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle SSH session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level and de-allocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. This does not mean that the operating system terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session. TOSS utilizes /etc/ssh/sshd_config for configurations of OpenSSH. Within the sshd_config the product of the values of "ClientAliveInterval" and "ClientAliveCountMax" are used to establish the inactivity threshold. The "ClientAliveInterval" is a timeout interval in seconds after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The "ClientAliveCountMax" is the number of client alive messages that may be sent without sshd receiving any messages back from the client. If this threshold is met, sshd will disconnect the client. The default setting for "ClientAliveCountMax" is "3." If "ClientAliveInterval is set to "15" and "ClientAliveCountMax" is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds. Satisfies: SRG-OS-000126-GPOS-00066, SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109
Checks: C-56536r824919_chk

Verify all network connections associated with SSH traffic are automatically terminated at the end of the session or after 10 minutes of inactivity, or as long as documented with the Information System Security Officer (ISSO) as an operational requirement. Check that the "ClientAliveInterval" variable is set to a value of "600" or less and that the "ClientAliveCountMax" is set to "1" by performing the following command: $ sudo grep -i clientalive /etc/ssh/ss