What changed in SUSE Linux Enterprise Micro (SLEM) 5 STIG V1R5V1R5 changes

Title

SLEM 5 must display the Standard Mandatory DODoW Notice and Consent Banner before granting any local or remote connection to the system.

Check text

Verify SLEM 5 displays the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the system via SSH. Check the issue file to verify it contains one of the DODDoW required banners. If it does not, this is a finding. > more /etc/issue The output must display the following DODDoW-required banner text: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." If the output does not display the correct banner text, this is a finding.

Fix text

Configure SLEM 5 to display the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the system by running the following commands: To configure the system logon banner, edit the "/etc/issue" file. Replace the default text inside with the Standard Mandatory DODDoW banner text: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."

Discussion

Display of a standardized and approved use notification before granting access to SLEM 5 ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DODDoW policy. Use the following verbiage for SLEM 5 that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."

V-261265 in V1R5

Discussion

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

V-261267 in V1R5

Discussion

Changes to any software components can have significant effects on the overall security of SLEM 5. This requirement ensures the software has not been tampered with and has been provided by a trusted vendor. Accordingly, patches, service packs, device drivers, or SLEM 5 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. SLEM 5 should not have to verify the software again. This requirement does not mandate DODDoW certificates for this purpose; however, the certificate used to verify the software must be from an approved Certification Authority (CA). For zypper on SUSE Linux Enterprise systems, GPG signature checking is enabled by default for all repositories, even if it's not explicitly set in "/etc/zypp/zypp.conf" or individual .repo files. The presence of the gpgcheck setting in repository files (like gpgcheck=1) or a global zypp.conf entry would override this default behavior if the user wanted to disable it (e.g., gpgcheck=0), but its absence simply means the default is in effect.

V-261274 in V1R5

Fix text

Configure the system commands to be protected from unauthorized access. Run the following command: > sudo transactional-update shell > sudo find -L /bin /sbin /usr/bin /usr/sbin /bin /sbin /usr/local/bin /usr/local/sbin ! -user root -type f -exec chgrp root '{}' 1; > exit > sudo reboot

V-261300 in V1R5

Fix text

Configure the system commands to be protected from unauthorized access. Run the following command: > sudo transactional-update shell > sudo find -L /bin /sbin /usr/bin /usr/sbin /bin /sbin /usr/local/bin /usr/local/sbin ! -user root -type d -exec chown root '{}' 1; > exit > sudo reboot

V-261301 in V1R5

Fix text

Configure the system commands to be protected from unauthorized access. Run the following command: > sudo transactional-update shell > sudo find -L /bin /sbin /usr/bin /usr/sbin /bin /sbin /usr/local/bin /usr/local/sbin ! -group root -type d -exec chgrp root '{}' 1; > exit > sudo reboot

V-261302 in V1R5

Discussion

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

V-261307 in V1R5

Title

SLEM 5 clock must, for networked systems, be synchronized to an authoritative DODoW time source at least every 24 hours.

Check text

Verify that SLEM 5 clock must be configured to synchronize to an authoritative DODDoW time source when the time difference is greater than one second with the following command: > sudo grep maxpoll /etc/chrony.conf server 0.us.pool.ntp.mil maxpoll 16 If the "server" parameter is not set to an authoritative DODDoW time source, "maxpoll" is greater than "16", the line is commented out, or the line is missing, this is a finding.

Fix text

The SLEM 5 clock must be configured to synchronize to an authoritative DODDoW time source when the time difference is greater than one second. To configure the system clock to synchronize to an authoritative DODDoW time source at least every 24 hours, edit the file "/etc/chrony.conf". Add or correct the following lines by replacing "&lttime_source>" with an authoritative DODDoW time source: server &lttime_source> maxpoll 16

V-261311 in V1R5

Title

SLEM 5 must display the Standard Mandatory DODoW Notice and Consent Banner before granting access via SSH.

Check text

Verify SLEM 5 displays the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the system via SSH with the following command: > sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '1r' | tr '1n' ' ' | xargs sudo grep -iH '^1s*banner' /etc/ssh/sshd_config:Banner /etc/ssh/dod_bannerDoW_banner If "Banner" is commented out or missing, or if the location returned will be overridden by package updates, this is a finding. Note: The file /etc/issue is overridden by package updates and will not maintain the banner text as it does in other Linux distributions.

Fix text

Add or modify the following line in the "/etc/ssh/sshd_config" file: Banner /etc/ssh/dod_bannerDoW_banner Restart the "sshd.service" to use the new file location: > sudo systemctl restart sshd.service

Discussion

Display of a standardized and approved use notification before granting access to SLEM 5 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. Because SLEM 5 employs an immutable architecture and "/etc/issue" is a system file, the banner must be stored in a different location. In this example, the location is "/etc/ssh/dod_bannerDoW_banner", but any nonsystem location is acceptable. The banner must be formatted in accordance with applicable DODDoW policy. Use the following verbiage for SLEM 5 that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."

V-261329 in V1R5

Title

SLEM 5 must implement DODoW-approved encryption to protect the confidentiality of SSH remote connections.

Check text

Verify that SLEM 5 implements DODDoW-approved encryption to protect the confidentiality of SSH remote connections with the following command: > sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '1r' | tr '1n' ' ' | xargs sudo grep -iH '^1s*ciphers' /etc/ssh/sshd_config:Ciphers aes256-ctr,aes192-ctr,aes128-ctr If any ciphers other than "aes256-ctr", "aes192-ctr", or "aes128-ctr" are listed, the order differs from the example above, the line is commented out, or the "Ciphers" keyword is missing, or conflicting results are returned, this is a finding.

Discussion

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DODDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection (e.g., RDP), thereby providing a degree of confidentiality. The encryption strength of a mechanism is selected based on the security categorization of the information. The system will attempt to use the first cipher presented by the client that matches the server list. Listing the values "strongest to weakest" is a method to ensure the use of the strongest cipher available to secure the SSH connection.

V-261334 in V1R5

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DODDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. The system will attempt to use the first hash presented by the client that matches the server list. Listing the values "strongest to weakest" is a method to ensure the use of the strongest hash available to secure the SSH connection.

V-261335 in V1R5

Discussion

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

V-261338 in V1R5

Discussion

Without protection of communications with wireless peripherals, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read, altered, or used to compromise SLEM 5. This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with a SLEM 5. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR keyboards, mice, pointing devices, and Near Field Communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DODDoW requirements for wireless data transmission and be approved for use by the AO. Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise SLEM 5. 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 communications with wireless peripherals can be accomplished by physical means (e.g., employing physical barriers to wireless radio frequencies) 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. If the wireless peripheral is only passing telemetry data, encryption of the data may not be required.

V-261346 in V1R5

Fix text

Configure SLEM 5 to disable account identifiers after 35 days of inactivity after the password expiration. Run the following command to change the configuration for "useradd" to disable the account identifier after "35" days: > sudo useradd -D -f 35 DODDoW recommendation is "35" days, but a lower value greater than "0" is acceptable.

V-261360 in V1R5

Fix text

Configure SLEM 5 to enforce a minimum 15-character password length. Edit "/etc/pam.d/common-password" and edit the line containing "pam_cracklib.so" to contain the option "minlen=15" after the third column. The DODDoW standard requires a minimum 15-character password length.

V-261382 in V1R5

Title

SLEM 5 must employ user passwords with a maximum lifetime of 6180 days.

Check text

Verify that SLEM 5 enforces a maximum user password age of 60180 days or less with the following command: > sudo awk -F: '$5 > 60180 || $5 == "" {print $1 ":" $5}' /etc/shadow If any results are returned that are not associated with a system account, this is a finding.

Fix text

Configure SLEM 5 to enforce a maximum password age of each &ltusername> account to 60180 days. The command in the check text will give a list of users that need to be updated to be in compliance: > sudo passwd -x 60180 &ltusername>

V-261389 in V1R5

Discussion

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

V-261393 in V1R5

Fix text

Configure SLEM 5 to enforce 24 hours/one day or greater as the minimum password age. Add or modify the following line in the "/etc/login.defs" file: PASS_MIN_DAYS &ltdays> The DODDoW requirement is "1", but a greater value is acceptable.

V-261394 in V1R5

Title

SLEM 5 must be configured to create or update passwords with a maximum lifetime of 6180 days.

Check text

Verify that SLEM 5 is configured to create or update passwords with a maximum password age of 60180 days or less with the following command: > grep '^PASS_MAX_DAYS' /etc/login.defs If "PASS_MAX_DAYS" is not set to a value of "60180" or less, but greater than "0", the line is commented out, or no line is returned, this is a finding.

Fix text

Configure SLEM 5 to enforce a maximum password age of 60180 days or less. Add or modify the following line in the "/etc/login.defs" file: PASS_MAX_DAYS &ltdays> The DODDoW requirement is 60180 days or less (but greater than zero, as zero days will lock the account immediately).

V-261395 in V1R5

Discussion

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

V-261396 in V1R5

Discussion

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

V-261397 in V1R5

Discussion

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

V-261398 in V1R5

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DODDoW has defined the following list of events for which SLEM 5 will provide an audit record generation capability: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.

V-261433 in V1R5

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DODDoW has defined the following list of events for which SLEM 5 will provide an audit record generation capability: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.

V-261434 in V1R5

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DODDoW has defined the following list of events for which SLEM 5 will provide an audit record generation capability: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.

V-261435 in V1R5

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DODDoW has defined the following list of events for which SLEM 5 will provide an audit record generation capability: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.

V-261440 in V1R5