Review All STIG Controls

Use your browser’s search function (usually CTRL-f or ⌘-f) to find the
security configuration in the full list shown here. You can search for STIG
ID numbers, such as V-38463, or for particular topics, like audit.

The file permissions, ownership, and group membership of system files and commands must match the vendor values. (V-71849)¶

Ubuntu’s debsums command does not support verification of permissions
and ownership for files that were installed by packages. This STIG
requirement will be skipped on Ubuntu.

The STIG requires that all files owned by an installed package must have their
permissions, user ownership, and group ownership set back to the vendor
defaults.

Although this is a good practice, it can cause issues if permissions or
ownership were intentionally set after the packages were installed. It also
causes significant delays in deployments. Therefore, this STIG is not applied
by default.

Deployers may opt in for the change by setting the following Ansible variable:

security_reset_perm_ownership:yes

The cryptographic hash of system files and commands must match vendor values. (V-71855)¶

Without cryptographic integrity protections, system command and files can be altered by unauthorized users without detection.

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 key used to generate the hash.

Ansible tasks will check the rpm-Va output (on CentOS, RHEL, openSUSE and SLE) or
the output of debsums (on Ubuntu) to see if any files installed from packages
have been altered. The tasks will print a list of files that have changed
since their package was installed.

Deployers should be most concerned with any checksum failures for binaries and
their libraries. These are most often a sign of system compromise or poor
system administration practices.

Configuration files may appear in the list as well, but these are often less
concerning since some of these files are adjusted by the security role itself.

Generating and validating checksums of all files installed by packages consume a
significant amount of disk I/O and could impact the performance of a production system.
It can also delay the playbook’s completion. Therefore, the check is disabled by default.

Deployers can enable the check by setting the following Ansible variable:

security_check_package_checksums:yes

The operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting local or remote access to the system via a graphical user logon. (V-71859)¶

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 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:

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests–not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.”

Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:

The operating system must display the approved Standard Mandatory DoD Notice and Consent Banner before granting local or remote access to the system via a graphical user logon. (V-71861)¶

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 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:

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

The security role configures a login banner for graphical logins using
dconf. Deployers can opt out of this change by setting the following
Ansible variable:

security_enable_graphical_login_message:no

The message is customized by setting another Ansible variable:

security_enable_graphical_login_message_text:>You are accessing a secured system and your actions will be logged alongwith identifying information. Disconnect immediately if you are not anauthorized user of this system.

Note

The space available for the graphical banner is relatively short. Deployers
should limit the length of their graphical login banners to the shortest
length possible.

The operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting local or remote access to the system via a command line user logon. (V-71863)¶

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 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:

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests–not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.”

Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:

The operating system must enable a user session lock until that user re-establishes access using established identification and authentication procedures. (V-71891)¶

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 must remain in place until the user reauthenticates. No other activity aside from reauthentication must unlock the system.

The STIG requires that graphical sessions are locked when the screensaver
starts and that users must re-enter credentials to restore access to the
system. The screensaver lock is enabled by default if dconf is present on
the system.

Deployers can opt out of this change by setting an Ansible variable:

security_lock_session:no

The operating system must initiate a screensaver after a 15-minute period of inactivity for graphical user interfaces. (V-71893)¶

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.

The operating system must set the idle delay setting for all connection types. (V-71895)¶

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.

The operating system must have the screen package installed. (V-71897)¶

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 screen package allows for a session lock to be implemented and configured.

The operating system must initiate a session lock for the screensaver after a period of inactivity for graphical user interfaces. (V-71899)¶

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.

The operating system must initiate a session lock for graphical user interfaces when the screensaver is activated. (V-71901)¶

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.

The STIG requires that a graphical session is locked when the screensaver
starts. This requires a user to re-enter their credentials to regain access to
the system.

The tasks will set a timeout of 5 seconds after the screensaver has started
before the session is locked. This gives a user a few seconds to press a key or
wiggle their mouse after the screensaver appears without needing to re-enter
their credentials.

Deployers can adjust this timeout by setting an Ansible variable:

security_lock_session_screensaver_lock_delay:5

When passwords are changed or new passwords are established, the new password must contain at least one upper-case character. (V-71903)¶

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.

The password quality requirements from the STIG are examples of good security
practice, but deployers are strongly encouraged to use centralized
authentication for administrative server access whenever possible.

Password quality requirements are controlled by two Ansible variables: one for
each individual password requirement and one “master switch” variable. The
master switch variable controls all password requirements and it is disabled
by default.

Deployers can enable all password quality requirements by setting the master
switch variable to yes:

security_pwquality_apply_rules:yes

When the master switch variable is enabled, each individual password quality
requirement can be disabled by a variable. To disable the fix for this STIG
control, set the following Ansible variable:

security_pwquality_require_uppercase:no

When passwords are changed or new passwords are established, the new password must contain at least one lower-case character. (V-71905)¶

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.

The password quality requirements from the STIG are examples of good security
practice, but deployers are strongly encouraged to use centralized
authentication for administrative server access whenever possible.

Password quality requirements are controlled by two Ansible variables: one for
each individual password requirement and one “master switch” variable. The
master switch variable controls all password requirements and it is disabled
by default.

Deployers can enable all password quality requirements by setting the master
switch variable to yes:

security_pwquality_apply_rules:yes

When the master switch variable is enabled, each individual password quality
requirement can be disabled by a variable. To disable the fix for this STIG
control, set the following Ansible variable:

security_pwquality_require_lowercase:no

When passwords are changed or new passwords are assigned, the new password must contain at least one numeric character. (V-71907)¶

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.

The password quality requirements from the STIG are examples of good security
practice, but deployers are strongly encouraged to use centralized
authentication for administrative server access whenever possible.

Password quality requirements are controlled by two Ansible variables: one for
each individual password requirement and one “master switch” variable. The
master switch variable controls all password requirements and it is disabled
by default.

Deployers can enable all password quality requirements by setting the master
switch variable to yes:

security_pwquality_apply_rules:yes

When the master switch variable is enabled, each individual password quality
requirement can be disabled by a variable. To disable the fix for this STIG
control, set the following Ansible variable:

security_pwquality_require_numeric:no

When passwords are changed or new passwords are assigned, the new password must contain at least one special character. (V-71909)¶

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.

The password quality requirements from the STIG are examples of good security
practice, but deployers are strongly encouraged to use centralized
authentication for administrative server access whenever possible.

Password quality requirements are controlled by two Ansible variables: one for
each individual password requirement and one “master switch” variable. The
master switch variable controls all password requirements and it is disabled
by default.

Deployers can enable all password quality requirements by setting the master
switch variable to yes:

security_pwquality_apply_rules:yes

When the master switch variable is enabled, each individual password quality
requirement can be disabled by a variable. To disable the fix for this STIG
control, set the following Ansible variable:

security_pwquality_require_special:no

When passwords are changed a minimum of eight of the total number of characters must be changed. (V-71911)¶

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.

The password quality requirements from the STIG are examples of good security
practice, but deployers are strongly encouraged to use centralized
authentication for administrative server access whenever possible.

Password quality requirements are controlled by two Ansible variables: one for
each individual password requirement and one “master switch” variable. The
master switch variable controls all password requirements and it is disabled
by default.

Deployers can enable all password quality requirements by setting the master
switch variable to yes:

security_pwquality_apply_rules:yes

When the master switch variable is enabled, each individual password quality
requirement can be disabled by a variable. To disable the fix for this STIG
control, set the following Ansible variable:

security_pwquality_require_characters_changed:no

When passwords are changed a minimum of four character classes must be changed. (V-71913)¶

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.

The password quality requirements from the STIG are examples of good security
practice, but deployers are strongly encouraged to use centralized
authentication for administrative server access whenever possible.

Password quality requirements are controlled by two Ansible variables: one for
each individual password requirement and one “master switch” variable. The
master switch variable controls all password requirements and it is disabled
by default.

Deployers can enable all password quality requirements by setting the master
switch variable to yes:

security_pwquality_apply_rules:yes

When the master switch variable is enabled, each individual password quality
requirement can be disabled by a variable. To disable the fix for this STIG
control, set the following Ansible variable:

security_pwquality_require_character_classes_changed:no

When passwords are changed the number of repeating consecutive characters must not be more than three characters. (V-71915)¶

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.

The password quality requirements from the STIG are examples of good security
practice, but deployers are strongly encouraged to use centralized
authentication for administrative server access whenever possible.

Password quality requirements are controlled by two Ansible variables: one for
each individual password requirement and one “master switch” variable. The
master switch variable controls all password requirements and it is disabled
by default.

Deployers can enable all password quality requirements by setting the master
switch variable to yes:

security_pwquality_apply_rules:yes

When the master switch variable is enabled, each individual password quality
requirement can be disabled by a variable. To disable the fix for this STIG
control, set the following Ansible variable:

security_pwquality_limit_repeated_characters:no

When passwords are changed the number of repeating characters of the same character class must not be more than four characters. (V-71917)¶

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.

The password quality requirements from the STIG are examples of good security
practice, but deployers are strongly encouraged to use centralized
authentication for administrative server access whenever possible.

Password quality requirements are controlled by two Ansible variables: one for
each individual password requirement and one “master switch” variable. The
master switch variable controls all password requirements and it is disabled
by default.

Deployers can enable all password quality requirements by setting the master
switch variable to yes:

security_pwquality_apply_rules:yes

When the master switch variable is enabled, each individual password quality
requirement can be disabled by a variable. To disable the fix for this STIG
control, set the following Ansible variable:

security_pwquality_limit_repeated_character_classes:no

The PAM system service must be configured to store only encrypted representations of passwords. (V-71919)¶

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. Passwords encrypted with a weak algorithm are no more protected than if they are kept in plain text.

The shadow file must be configured to store only encrypted representations of passwords. (V-71921)¶

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. Passwords encrypted with a weak algorithm are no more protected than if they are kept in plain text.

The default password storage mechanism for Ubuntu 16.04, CentOS 7, openSUSE Leap,
SUSE Linux Enterprise 12 and Red Hat Enterprise Linux 7 is SHA512 and the tasks
in the security role ensure that the default is maintained.

Deployers can configure a different password storage mechanism by setting the
following Ansible variable:

security_password_encrypt_method:SHA512

Warning

SHA512 is the default on most modern Linux distributions and it meets the
requirement of the STIG. Do not change the value unless a system has
a specific need for a different password mechanism.

User and group account administration utilities must be configured to store only encrypted representations of passwords. (V-71923)¶

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. Passwords encrypted with a weak algorithm are no more protected than if they are kept in plain text.

Passwords for new users must be restricted to a 24 hours/1 day minimum lifetime. (V-71925)¶

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, the password could be repeatedly changed in a short period of time to defeat the organization’s policy regarding password reuse.

Passwords must be restricted to a 24 hours/1 day minimum lifetime. (V-71927)¶

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, the password could be repeatedly changed in a short period of time to defeat the organization’s policy regarding password reuse.

Setting a minimum password lifetime on interactive user accounts provides
security benefits by limiting the frequency of password changes. However, this
can cause login problems for users without proper communication and
coordination.

Deployers can opt-in for this change by setting the following Ansible variable:

security_set_minimum_password_lifetime:yes

The tasks will examine each interactive user account and set the minimum
password age if the existing setting is not equal to one day.

Passwords for new users must be restricted to a 60-day maximum lifetime. (V-71929)¶

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.

Although the STIG requires that all passwords have a maximum lifetime set, this
can cause authentication disruptions in production environments if users are
not aware that their password will expire. Therefore, this change is not
applied by default.

Deployers can opt in for this change and provide a maximum lifetime for user
passwords (in days) by setting the following Ansible variable:

security_password_max_lifetime_days:60

The STIG requires that all passwords expire after 60 days.

Existing passwords must be restricted to a 60-day maximum lifetime. (V-71931)¶

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.

Although the STIG requires that a maximum password lifetime is set for all
interactive user accounts, the security benefits of this configuration are
debatable. The draft of NIST Publication 800-63B argues that password
rotation may reduce overall security in some situations.

Deployers can opt-in for this change by setting the following Ansible variable:

security_set_maximum_password_lifetime:yes

The tasks will examine each interactive user account and set the maximum
password age if the existing setting is not equal to 60 days.

Passwords must be prohibited from reuse for a minimum of five generations. (V-71933)¶

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 per policy requirements.

Although the STIG requires that five passwords are remembered to prevent re-
use, this can cause issues in production environment if the change is not
communicated well to users. Therefore, the tasks in the security role do not
apply this change by default.

Deployers can opt in for the change and specify a number of passwords to
remember by setting the following Ansible variable:

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.

Although the STIG requires that passwords have a minimum length of 15
characters, this change might be disruptive to users on a production system
without communicating the change first. Therefore, this change is not applied
by default.

Deployers can opt in for the change by setting the following Ansible variable:

security_pwquality_require_minimum_password_length:yes

The system must not have accounts configured with blank or null passwords. (V-71937)¶

The operating system must disable account identifiers (individuals, groups, roles, and devices) if the password expires. (V-71941)¶

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 zero days of inactivity.

The STIG requires that user accounts are disabled when their password expires.
This might be disruptive for some users or for automated processes. Therefore,
the tasks in the security role do not apply this change by default.

Deployers can opt in for this change by setting the following Ansible variable:

security_disable_account_if_password_expires:yes

Accounts subject to three unsuccessful logon attempts within 15 minutes must be locked for the maximum configurable period. (V-71943)¶

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.

If three unsuccessful root logon attempts within 15 minutes occur the associated account must be locked. (V-71945)¶

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.

The STIG requires that accounts with excessive failed login attempts are
locked. It sets a limit of three failed attempts in a 15 minute interval and
these restrictions are applied to all users (including root). Accounts cannot
be automatically unlocked for seven days.

This change might cause disruptions in production environments without proper
communication to users. Therefore, this change is not applied by default.

Deployers can opt in for the change by setting the following variable:

security_pam_faillock_enable:yes

There are also three configuration options that can be adjusted by setting
Ansible variables:

security_pam_faillock_attempts: This many failed login attempts within
the specified time interval with trigger the account to lock.
(STIG requirement: 3 attempts)

security_pam_faillock_interval: This is the time interval (in seconds)
to use when measuring excessive failed login attempts.
(STIG requirement: 900 seconds)

security_pam_faillock_deny_root: Set to yes to apply the restriction
to the root user or set to no to exempt the root user from the account
locking restrictions.
(STIG requirement: yes)

security_pam_faillock_unlock_time: This sets the time delay (in seconds)
before a locked account is automatically unlocked.
(STIG requirement: 604800 seconds)

The STIG requires all users to authenticate when using sudo, but this
change can be highly disruptive for automated scripts or applications that
cannot perform interactive authentication. Automated edits from Ansible tasks
might cause authentication disruptions on some hosts, and deployers are urged
to carefully review each use of the NOPASSWD directive in their sudo
configuration files.

The STIG requires all users to re-authenticate when using sudo, but this
change can be highly disruptive for automated scripts or applications that
cannot perform interactive authentication. Automated edits from Ansible tasks
might cause authentication disruptions on some hosts, and deployers are urged
to carefully review each use of the !authenticate directive in their
sudo configuration files.

The delay between logon prompts following a failed console logon attempt must be at least four seconds. (V-71951)¶

Configuring the operating system to implement organization-wide security implementation guides and security checklists verifies compliance with federal standards and establishes a common security baseline across 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, and directory permission settings; and settings for functions, ports, protocols, services, and remote connections.

The operating system must not allow an unattended or automatic logon to the system via a graphical user interface. (V-71953)¶

If AutomaticLoginEnable=true exists in the gdm configuration file,
/etc/gdm/custom.conf, the configuration will removed. This disallows
automatic logins for gdm and requires a user to complete the username and
password prompts.

Deployers can opt-out of this change by setting an Ansible variable:

security_disable_gdm_automatic_login:no

The operating system must not allow an unrestricted logon to the system. (V-71955)¶

Systems with a Basic Input/Output System (BIOS) must require authentication upon booting into single-user and maintenance modes. (V-71961)¶

If the system does not require valid root authentication before it boots into single-user or maintenance mode, anyone who invokes single-user or maintenance mode is granted privileged access to all files on the system. GRUB 2 is the default boot loader for RHEL 7 and is designed to require a password to boot into single-user mode or make modifications to the boot menu.

Although the STIG requires that GRUB 2 asks for a password whenever a user
attempts to enter single-user or maintenance mode, this change might be
disruptive in an emergency situation. Therefore, this change is not applied by
default.

Deployers that wish to opt in for this change should set two Ansible variables:

The default password set in the security role is ‘secrete’, but deployers
should set a much more secure password for production environments. Use the
grub2-mkpasswd-pbkdf2 command to create a password hash string and use it
as the value for the Ansible variable security_grub_password_hash.

Warning

This change must be tested in a non-production environment first. Requiring
authentication in GRUB 2 without proper communication to users could cause
extensive delays in emergency situations.

If the system does not require valid root authentication before it boots into single-user or maintenance mode, anyone who invokes single-user or maintenance mode is granted privileged access to all files on the system. GRUB 2 is the default boot loader for RHEL 7 and is designed to require a password to boot into single-user mode or make modifications to the boot menu.

The operating system must uniquely identify and must authenticate organizational users (or processes acting on behalf of organizational users) using multifactor authentication. (V-71965)¶

To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system.

Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following:

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.

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

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.

If a privileged user were to log on using this service, the privileged user password could be compromised.

A file integrity tool must verify the baseline operating system configuration at least weekly. (V-71973)¶

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.

Initializing the AIDE database and completing the first AIDE run causes
increased disk I/O and CPU usage for extended periods. Therefore, the AIDE
database is not automatically initialized by the tasks in the security role.

Deployers can enable the AIDE database initialization within the security role
by setting the following Ansible variable:

security_rhel7_initialize_aide:yes

Designated personnel must be notified if baseline configurations are changed in an unauthorized manner. (V-71975)¶

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.

The cron job for AIDE is configured to send emails to the root user after each
AIDE run.

The operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components from a repository without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. (V-71977)¶

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

On Ubuntu systems, the tasks check for the AllowUnauthenticated string
anywhere in the apt configuration files found within /etc/apt/apt.conf.d/.
If the string is found, a warning is printed on the console.

On CentOS 7 systems, the tasks set the gpgcheck option to 1 in the
/etc/yum.conf file. This enables GPG checks for all packages installed
with yum.

On openSUSE Leap systems, the tasks set the gpgcheck option to 1 in the
/etc/zypp/zypp.conf file. This enables GPG checks for all packages installed
with zypper.

Setting security_enable_gpgcheck_packages to no will skip the
AllowUnauthenticated string check on Ubuntu and it will set gpgcheck=0
in /etc/yum.conf or /etc/zypp/zypp.conf on CentOS and openSUSE Leap systems
respectively.

The operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. (V-71979)¶

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

On Ubuntu systems, the tasks comment out the no-debsig configuration line
in /etc/dpkg/dpkg.cfg. This causes dpkg to verify GPG signatures for
all packages that are installed locally.

On CentOS 7 systems, the tasks set the localpkg_gpgcheck option to 1 in
the /etc/yum.conf file. This enables GPG checks for all packages installed
locally with yum.

On openSUSE Leap systems, the tasks set the gpgcheck option to 1 in the
/etc/zypp/zypp.conf file. This enables GPG checks for all packages installed
with zypper.

Setting security_enable_gpgcheck_packages_local to no will skip the
no-debsig adjustment on Ubuntu and it will set local_gpgcheck=0 in
/etc/yum.conf on CentOS systems. Similarly, on openSUSE Leap systems, it will set
gpgcheck=0 in /etc/zypp/zypp.conf.

The operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of packages without verification of the repository metadata. (V-71981)¶

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 Certificate Authority.

The STIG requires that repository XML files are verified during yum runs.

Warning

This setting is disabled by default because it can cause issues with CentOS
systems and prevent them from retrieving repository information. Deployers
who choose to enable this setting should test it thoroughly on
non-production environments before applying it to production systems.

Deployers can override this default and opt in for the change by setting the
following Ansible variable:

The operating system must remove all software components after updated versions have been installed. (V-71987)¶

Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system.

Although the STIG requires that dependent packages are removed automatically
when a package is removed, this can cause problems with certain packages,
especially kernels. Deployers must opt in to meet the requirements of this STIG
control.

Deployers should set the following variable to enable automatic dependent
package removal:

Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as 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. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

For CentOS or Red Hat Enterprise Linux systems, SELinux is enabled (in
enforcing mode) and its user tools are automatically installed. If SELinux is
not in enforcing mode already, a reboot is required to enable SELinux and
relabel the filesystem.

Warning

Relabeling a filesystem takes time and the server must be offline for the
relabeling to complete. Filesystems with large amounts of files and
filesystems on slow disks will cause the relabeling process to take more
time.

Deployers can opt out of this change by setting the following Ansible variable:

security_rhel7_enable_linux_security_module:no

The operating system must enable the SELinux targeted policy. (V-71991)¶

Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as 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. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

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 the GNOME graphical environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.

The STIG requires that the umask for all authenticated users is 077. This
ensures that all new files and directories created by a user are accessible
only by that user.

Although this change has a significant security benefit, it can cause problems
for users who are not expecting the change. The security role will not adjust
the umask by default.

Deployers can opt-in for the change by setting the default umask with an
Ansible variable:

security_shadow_utils_umask:077

Note

Ubuntu, openSUSE Leap and SUSE Linux Enterpsise 12 use pam_umask and it uses
the default umask provided by the UMASK line in /etc/login.defs.
The default setting on Ubuntu, openSUSE Leap and SUSE Linux Enterprise 12
systems is 022. This allows the user’s group and other users on the
system to read and execute files, but they cannot write to them.

CentOS and Red Hat Enterprise Linux do not use pam_umask and instead
set a default umask of 0002 for regular users and 0022 for root.
This gives the regular user’s group full access to newly created files, but
other users cannot write to those files.

The tasks for this STIG requirement are not currently applied to CentOS and
Red Hat Enterprise Linux systems. See Launchpad Bug #1656003 for more
details.

An operating system release is considered “supported” if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve security issues discovered in the system software.

The STIG requires that the current release of the operating system is still
supported and is actively receiving security updates. Deployers are urged to
stay current with the latest releases from Ubuntu, SUSE, CentOS and Red Hat.

The following links provide more details on end of life (EOL) dates for the
distributions supported by this role:

Vendor packaged system security patches and updates must be installed and up to date. (V-71999)¶

Timely patching is critical for maintaining the operational availability, confidentiality, and integrity of information technology (IT) systems. However, failure to keep operating system and application software patched is a common mistake made by IT professionals. New patches are released daily, and it is often difficult for even experienced System Administrators to keep abreast of all the new patches. When new weaknesses in an operating system exist, patches are usually made available by the vendor to resolve the problems. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses in the unpatched software. The lack of prompt attention to patching could result in a system compromise.

Although the STIG requires that security patches and updates are applied when
they are made available, this might be disruptive to some systems. Therefore,
the tasks in the security role will not configure automatic updates by default.

Deployers can opt in for automatic package updates by setting the following
Ansible variable:

security_rhel7_automatic_package_updates:yes

When enabled, the tasks install and configure yum-cron on CentOS and Red
Hat Enterprise Linux. On Ubuntu systems, the unattended-upgrades package
is installed and configured. On openSUSE Leap and SUSE Linux Enterprise systems,
a daily cronjob is installed.

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.

Deployers are strongly urged to review the list of user accounts on each server
regularly. Evaluation of user accounts must be done on a case-by-case basis and
the tasks in the security role are unable to determine which user accounts are
valid. Deployers must complete this work manually.

All Group Identifiers (GIDs) referenced in the /etc/passwd file must be defined in the /etc/group file. (V-72003)¶

If any users are found with invalid GIDs, those users are printed in the
Ansible output. Deployers should review the list and ensure all users are
assigned to a valid group that is defined in /etc/group.

The root account must be the only account having unrestricted access to the system. (V-72005)¶

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.

Searching an entire filesystem with find reduces system performance and
might impact certain applications negatively. Therefore, the search for files
and directories with an invalid owner is disabled by default.

Deployers can opt in for this search by setting the following Ansible variable:

security_search_for_invalid_owner:yes

Any files or directories without a valid user owner are displayed in the
Ansible output.

Searching an entire filesystem with find reduces system performance and
might impact certain applications negatively. Therefore, the search for files
and directories with an invalid group owner is disabled by default.

Deployers can opt in for this search by setting the following Ansible variable:

security_search_for_invalid_group_owner:yes

Any files or directories without a valid group owner are displayed in the
Ansible output.

All local interactive users must have a home directory assigned in the /etc/passwd file. (V-72011)¶

The usernames of all users without home directories assigned are provided in
the Ansible console output. Deployers should use this list of usernames to
audit each system to ensure every user has a valid home directory.

All local interactive user accounts, upon creation, must be assigned a home directory. (V-72013)¶

The CREATE_HOME variable is set to yes by the tasks in the security
role. This ensures that home directories are created each time a new user
account is created.

Deployers can opt out of this change by setting the following Ansible variable:

security_shadow_utils_create_home:no

Note

On CentOS 7, Red Hat Enterprise Linux 7 systems, openSUSE Leap and SUSE
Linux Enterprise 12, home directories are always created with new users by default.
Home directories are not created by default on Ubuntu systems.

All local interactive user home directories defined in the /etc/passwd file must exist. (V-72015)¶

If a local interactive user has a home directory defined that does not exist, the user may be given access to the / directory as the current working directory upon logon. This could create a Denial of Service because the user would not be able to access their logon configuration files, and it may give them visibility to system files they normally would not be able to access.

Each interactive user on the system is checked to verify that their assigned
home directory exists on the filesystem. If a home directory is missing, the
name of the user and their assigned home directory is printed in the Ansible
console output.

All local interactive user home directories must have mode 0750 or less permissive. (V-72017)¶

Although the STIG requires that all home directories have the proper owner,
group owner, and permissions, these changes might be disruptive in some
environments. These tasks are not executed by default.

Deployers can opt in for the following changes to each home directory:

Permissions are set to 0750 at a maximum. If permissions are already
more restrictive than 0750, the permissions are left unchanged.

User ownership is set to the UID of the user.

Group ownership is set to the GID of the user.

Deployers can opt in for these changes by setting the following Ansible
variable:

security_set_home_directory_permissions_and_owners:yes

All local interactive user home directories must be owned by their respective users. (V-72019)¶

All local interactive user home directories must be group-owned by the home directory owners primary group. (V-72021)¶

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.

All files and directories contained in local interactive user home directories must be owned by the owner of the home directory. (V-72023)¶

If local interactive users do not own the files in their directories, unauthorized users may be able to access them. Additionally, if files are not owned by the user, this could be an indication of system compromise.

Although the STIG has requirements for ownership and permissions of files and
directories in each user’s home directory, broad changes to these settings
might cause disruptions to users on a system. Therefore, these changes are left
to deployers to examine and adjust manually.

All files and directories contained in local interactive user home directories must be group-owned by a group of which the home directory owner is a member. (V-72025)¶

Although the STIG has requirements for ownership and permissions of files and
directories in each user’s home directory, broad changes to these settings
might cause disruptions to users on a system. Therefore, these changes are left
to deployers to examine and adjust manually.

All files and directories contained in local interactive user home directories must have mode 0750 or less permissive. (V-72027)¶

Although the STIG has requirements for ownership and permissions of files and
directories in each user’s home directory, broad changes to these settings
might cause disruptions to users on a system. Therefore, these changes are left
to deployers to examine and adjust manually.

All local initialization files for interactive users must be owned by the home directory user or root. (V-72029)¶

Although the STIG requires that all initialization files for interactive users
have proper owners, group owners, and permissions, these changes are often
disruptive for users. The tasks in the security role do not make any changes
to user initialization files.

Deployers should review the content and discretionary access controls applied
to each user’s initialization files in their home directory.

Local initialization files for local interactive users must be group-owned by the users primary group or root. (V-72031)¶

Although the STIG requires that all initialization files for interactive users
have proper owners, group owners, and permissions, these changes are often
disruptive for users. The tasks in the security role do not make any changes
to user initialization files.

Deployers should review the content and discretionary access controls applied
to each user’s initialization files in their home directory.

All local initialization files must have mode 0740 or less permissive. (V-72033)¶

Although the STIG requires that all initialization files for interactive users
have proper owners, group owners, and permissions, these changes are often
disruptive for users. The tasks in the security role do not make any changes
to user initialization files.

Deployers should review the content and discretionary access controls applied
to each user’s initialization files in their home directory.

All local interactive user initialization files executable search paths must contain only paths that resolve to the users home directory. (V-72035)¶

The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory (other than the user’s home directory), executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. If deviations from the default system search path for the local interactive user are required, they must be documented with the Information System Security Officer (ISSO).

Although the STIG requires that all initialization files must contain
executable search paths that resolve to the user’s home directory, this change
be disruptive for most users. The tasks in the security role do not make any
changes to user initialization files.

Local initialization files must not execute world-writable programs. (V-72037)¶

If user start-up files execute world-writable programs, especially in unprotected directories, they could be maliciously modified to destroy user files or otherwise compromise the system at the user level. If the system is compromised at the user level, it is easier to elevate privileges to eventually compromise the system at the root and network level.

The tasks in the security role examine the SELinux contexts on each device file
found on the system. Any devices without appropriate labels are printed in
the Ansible output.

Deployers should investigate the unlabeled devices and ensure that the correct
labels are applied for the class of device.

Note

This change applies only to CentOS or Red Hat Enterprise Linux systems
since they rely on SELinux as their default Linux Security Module (LSM).
Ubuntu, openSUSE Leap and SUSE Linux Enterprise systems use AppArmor, which
uses policy files rather than labels applied to individual files.

File systems that contain user home directories must be mounted to prevent files with the setuid and setgid bit set from being executed. (V-72041)¶

The “nosuid” mount option causes the system to not execute setuid and setgid files with owner privileges. This option must be used for mounting any file system not containing approved setuid and setguid files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

File systems that are used with removable media must be mounted to prevent files with the setuid and setgid bit set from being executed. (V-72043)¶

The “nosuid” mount option causes the system to not execute “setuid” and “setgid” files with owner privileges. This option must be used for mounting any file system not containing approved “setuid” and “setguid” files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

File systems that are being imported via Network File System (NFS) must be mounted to prevent files with the setuid and setgid bit set from being executed. (V-72045)¶

The “nosuid” mount option causes the system to not execute “setuid” and “setgid” files with owner privileges. This option must be used for mounting any file system not containing approved “setuid” and “setguid” files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

All world-writable directories must be group-owned by root, sys, bin, or an application group. (V-72047)¶

If a world-writable directory has the sticky bit set and is not group-owned by a privileged Group Identifier (GID), unauthorized users may be able to modify files created by others.

The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access.

The tasks in the security role examine the world-writable directories on the
system and report any directories that are not group-owned by the root
user. Those directories appear in the Ansible output.

Deployers should review the list of directories and group owners to ensure
that they are appropriate for the directory. Unauthorized group ownership
could allow certain users to modify files from other users.

Searching the entire filesystem for world-writable directories will consume
a significant amount of disk I/O and could impact the performance of a
production system. It can also delay the playbook’s completion. Therefore,
the search is disabled by default.

Deployers can enable the search by setting the following Ansible variable:

security_find_world_writable_dirs:yes

The umask must be set to 077 for all local interactive user accounts. (V-72049)¶

The umask controls the default access mode assigned to newly created files. A umask of 077 limits new files to mode 700 or less permissive. Although umask can be represented as a four-digit number, the first digit representing special access modes is typically ignored or required to be “0”. This requirement applies to the globally configured system defaults and the local interactive user defaults for each account on the system.

Although the STIG requires that all local interactive user accounts have a
umask of 077, this change can be disruptive for users and the applications
they run. This change cannot be applied in an automated way.

Deployers should review user initialization files regularly to ensure that the
umask is not specified. This allows the system-wide setting of 077 to be
applied to all user sessions.

The tasks in the security role check for the existence of /etc/cron.allow
and set both the user and group ownership to root. This is the default on
Ubuntu, CentOS, Red Hat Enterprise Linux systems, openSUSE Leap and SUSE Linux
Enterprise 12 already.

If the cron.allow file exists it must be group-owned by root. (V-72055)¶

Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps may consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition.

The operating system must implement NIST FIPS-validated cryptography for the following: to provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (V-72067)¶

Use of weak or untested encryption algorithms undermines the purposes of using 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.

The tasks in the Ansible role install the dracut-fips (RHEL and SLE) and
dracut-fips-aesni (RHEL) packages and check to see if FIPS is enabled on the
system. If it is not enabled, a warning message is printed in the Ansible
output.

Enabling FIPS at boot time requires additional manual configuration. Refer to
Chapter 7. Federal Standards and Regulations in the Red Hat documentation
for more details. Section 7.1.1 contains the steps required for updating
the bootloader configuration and regenerating the initramfs.

Note

This change only applies to CentOS, Red Hat Enterprise Linux, openSUSE Leap
and SUSE Linux Enterprise. Ubuntu does not use dracut by default and the process
for enabling the FIPS functionality at boot time is more complex.

The file integrity tool must be configured to verify Access Control Lists (ACLs). (V-72069)¶

CentOS 7 and Red Hat Enterprise Linux 7 already deploy a very secure AIDE
configuration that checks access control lists (ACLs) and extended attributes
by default. No configuration changes are applied on these systems.

However, Ubuntu lacks the rules that include ACL and extended attribute checks.
The tasks in the security role will add a small configuration block at the end
of the AIDE configuration file to meet the requirements of this STIG, as well
as V-72071.

openSUSE Leap and SUSE Linux Enterprise 12 also lack a rule to check ACLs and
extended attributes. The default configuration file is adjusted to include those
as well.

The file integrity tool must be configured to verify extended attributes. (V-72071)¶

CentOS 7 and Red Hat Enterprise Linux 7 already deploy a very secure AIDE
configuration that checks access control lists (ACLs) and extended attributes
by default. No configuration changes are applied on these systems.

However, Ubuntu lacks the rules that include ACL and extended attribute checks.
The tasks in the security role will add a small configuration block at the end
of the AIDE configuration file to meet the requirements of this STIG, as well
as V-72069.

openSUSE Leap and SUSE Linux Enterprise 12 also lack a rule to check ACLs and
extended attributes. The default configuration file is adjusted to include those
as well.

The system must not allow removable media to be used as the boot loader unless approved. (V-72075)¶

Malicious users with removable boot media can gain access to a system configured to use removable media as the boot loader. If removable media is designed to be used as the boot loader, the requirement must be documented with the Information System Security Officer (ISSO).

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.

These audit records must also identify individual identities of group account users. (V-72079)¶

Without establishing what type of events occurred, 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 the operating system audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured operating system.

The tasks in the security role start the audit daemon immediately and ensure
that it starts at boot time.

The operating system must shut down upon audit processing failure, unless availability is an overriding concern. If availability is a concern, the system must alert the designated staff (System Administrator [SA] and Information System Security Officer [ISSO] at a minimum) in the event of an audit processing failure. (V-72081)¶

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.

The audit daemon takes various actions when there is an auditing failure. There
are three options for the -f flag for auditctl:

0: In the event of an auditing failure, do nothing.

1: In the event of an auditing failure, write messages to the kernel log.

2: In the event of an auditing failure, cause a kernel panic.

Most operating systems set the failure flag to 1 by default, which
maximizes system availability while still causing an alert. The tasks in the
security role set the flag to 1 by default.

Deployers can adjust the following Ansible variable to customize the failure
flag:

security_rhel7_audit_failure_flag:1

Warning

Setting the failure flag to 2 is strongly discouraged unless the
security of the system takes priority over its availability. Any failure in
auditing causes a kernel panic and the system requires a hard reboot.

The operating system must off-load audit records onto a different system or media from the system being audited. (V-72083)¶

The audispd daemon transmits audit logs without encryption by default. The
STIG requires that these logs are encrypted while they are transferred across
the network. The encryption is controlled by the enable_krb5 option in
/etc/audisp/audisp-remote.conf.

Deployers can opt-in for encrypted audit log transmission by setting the
following Ansible variable:

security_audisp_enable_krb5:yes

Warning

Only enable this setting if kerberos is already configured.

The audit system must take appropriate action when the audit storage volume is full. (V-72087)¶

The tasks in the security role set the disk_full_action and
network_failure_action to syslog in the audispd remote configuration.
In the event of a full disk on the remote log server or a network interruption,
the local system sends warnings to syslog. This is the safest option since it
maximizes the availability of the local system.

Deployers have two other options available:

single: Switch the local server into single-user mode in the event of a
logging failure.

halt: Shut off the local server gracefully in the event of a logging
failure.

Warning

Choosing single or halt causes a server to go into a degraded or
offline state immediately after a logging failure.

Deployers can adjust these configurations by setting the following Ansible
variables (the safe defaults are shown here):

The operating system must immediately notify the System Administrator (SA) and Information System Security Officer ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity. (V-72089)¶

The operating system must immediately notify the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) via email when the threshold for the repository maximum audit record storage capacity is reached. (V-72091)¶

If security personnel are not notified immediately when the threshold for the repository maximum audit record storage capacity is reached, they are unable to expand the audit record storage capacity before records are lost.

The space_left_action in the audit daemon configuration is set to
email. This configuration causes the root user to receive an email when the
space_left threshold is reached.

Deployers can customize this configuration by setting the following Ansible
variable:

security_rhel7_auditd_space_left_action:email

The operating system must immediately notify the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) when the threshold for the repository maximum audit record storage capacity is reached. (V-72093)¶

If security personnel are not notified immediately when the threshold for the repository maximum audit record storage capacity is reached, they are unable to expand the audit record storage capacity before records are lost.

The action_mail_acct configuration in the audit daemon configuration file
is set to root to meet the requirements of the STIG. Deployers can
customize the recipient of the emails that come from auditd by setting the
following Ansible variable:

Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat.

This STIG is difficult to implement in an automated way because the number of
applications on a system with setuid/setgid permissions changes over time.
In addition, adding audit rules for some of these automatically could cause a
significant increase in logging traffic when these applications are used
regularly.

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 STIG requires that all chown syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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 STIG requires that all fchown syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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 STIG requires that all lchown syscalls are audited, but this change
creates a significant increase in logging on most systems. This increase can
cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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 STIG requires that all fchownat syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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 STIG requires that all chmod syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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 STIG requires that all fchmod syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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 STIG requires that all fchmodat syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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

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 STIG requires that all fsetxattr syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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 STIG requires that all lsetxattr syscalls are audited, but this change
creates a significant increase in logging on most systems. This increase can
cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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

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 STIG requires that all fremovexattr syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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 STIG requires that all lremovexattr syscalls are audited, but this
change creates a significant increase in logging on most systems. This increase
can cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space
exhaustion. Deployers should only enable this rule if they have tested it
thoroughly in a non-production environment with system health monitoring
enabled.

Deployers can opt in for this change by setting the following Ansible variable:

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

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

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

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

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

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

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

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

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

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 operating system must generate audit records for all successful/unsuccessful account access count events. (V-72143)¶

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 operating system must generate audit records for all unsuccessful account access events. (V-72145)¶

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 operating system must generate audit records for all successful account access events. (V-72147)¶

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

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 password commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 password commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 password commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 password commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 password commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 access commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 access commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 access commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 access commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 access commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 access commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 mount commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 mount commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 postfix commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 postfix commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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 ssh commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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.

All uses of the pam_timestamp_check command must be audited. (V-72185)¶

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.

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

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

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

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

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 operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd. (V-72197)¶

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 tasks in the security role check for uncommented lines in the rsyslog
configuration that contain @ or @@, which signifies that a remote
logging configuration is in place. If these lines are not found, a warning
message is printed in the Ansible output.

The rsyslog daemon must not accept log messages from other servers unless the server is being used for log aggregation. (V-72211)¶

Unintentionally running a rsyslog server accepting remote messages puts the system at increased risk. Malicious rsyslog messages sent to the server could exploit vulnerabilities in the server software itself, could introduce misleading information in to the system’s logs, or could fill the system’s storage leading to a Denial of Service.
If the system is intended to be a log aggregation server its use must be documented with the ISSO.

Virus scanning software can be used to protect a system from penetration from computer viruses and to limit their spread through intermediate systems.

The virus scanning software should be configured to perform scans dynamically on accessed files. If this capability is not available, the system must be configured to scan, at a minimum, all altered files on the system on a daily basis.

If the system processes inbound SMTP mail, the virus scanner must be configured to scan all received mail.

The STIG requires that a virus scanner is installed and running, but the value
of a virus scanner within an OpenStack control plane or on a hypervisor is
negligible in many cases. In addition, the disk I/O impact of a virus scanner
can impact a production environment negatively.

The security role has tasks to deploy ClamAV with automatic updates, but the
tasks are disabled by default.

Deployers can enable the ClamAV virus scanner by setting the following Ansible
variable:

security_enable_virus_scanner:yes

Warning

The ClamAV packages are provided in the EPEL repository. Setting the
security_enable_virus_scanner will also cause the EPEL repository to
be installed by the role.

The system must update the virus scan program every seven days or more frequently. (V-72215)¶

Virus scanning software can be used to protect a system from penetration from computer viruses and to limit their spread through intermediate systems.

The virus scanning software should be configured to check for software and virus definition updates with a frequency no longer than seven days. If a manual process is required to update the virus scan software or definitions, it must be documented with the Information System Security Officer (ISSO).

The operating system must limit the number of concurrent sessions to 10 for all accounts and/or account types. (V-72217)¶

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 DoS attacks.

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 on mission needs and the operational environment for each system.

Although the STIG requires that each account is limited to 10 concurrent
connections, this change might be disruptive in some environments. Therefore,
this change is not applied by default.

Deployers can opt in for this change by setting a concurrent connection limit
with this Ansible variable:

security_rhel7_concurrent_session_limit:10

The host must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the Ports, Protocols, and Services Management Component Local Service Assessment (PPSM CLSA) and vulnerability assessments. (V-72219)¶

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.

A FIPS 140-2 approved cryptographic algorithm must be used for SSH communications. (V-72221)¶

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.

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

The Ciphers configuration is set to aes128-ctr,aes192-ctr,aes256-ctr in
/etc/ssh/sshd_config and sshd is restarted.

Deployers can change the list of ciphers by setting the following Ansible
variable:

security_sshd_cipher_list:'cipher1,cipher2,cipher3'

All network connections associated with a communication session must be terminated at the end of the session or after 10 minutes of inactivity from the user at a command prompt, except to fulfill documented and validated mission requirements. (V-72223)¶

Terminating an idle 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 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.

The tasks in the security role set a 600 second (10 minute) timeout for network
connections associated with a communication session. Deployers can change the
timeout value by setting the following Ansible variable:

The Standard Mandatory DoD Notice and Consent Banner must be displayed immediately prior to, or as part of, remote access logon prompts. (V-72225)¶

Display of a standardized and approved use notification before granting access to the publicly accessible 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 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:

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

The tasks in the security role deploy a standard notice and consent banner into
/etc/motd on each server. Ubuntu, CentOS, Red Hat Enterprise Linux,
openSUSE Leap and SUSE Linux Enterprise display this banner after each successful
login via ssh or the console.

Deployers can choose a different destination for the banner by setting the
following Ansible variable:

security_sshd_banner_file:/etc/motd

The message is customized with the following Ansible variable:

security_login_banner_text:|------------------------------------------------------------------------------* WARNING ** You are accessing a secured system and your actions will be logged along ** with identifying information. Disconnect immediately if you are not an ** authorized user of this system. *------------------------------------------------------------------------------

The operating system must implement cryptography to protect the integrity of Lightweight Directory Access Protocol (LDAP) authentication communications. (V-72227)¶

Without cryptographic integrity protections, information can be altered by unauthorized users without detection.

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 key used to generate the hash.

The operating system must implement cryptography to protect the integrity of Lightweight Directory Access Protocol (LDAP) communications. (V-72229)¶

Without cryptographic integrity protections, information can be altered by unauthorized users without detection.

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 key used to generate the hash.

Deployers are strongly urged to utilize sssd for systems that authenticate
against LDAP or Active Directory (AD) servers.

To meet this control, deployers must ensure that ldap_tls_cacert or
ldap_tls_cacertdir are set in the /etc/sssd/sssd.conf file. The
ldap_tls_cacert directive specifies a single certificate while
ldap_tls_cacertdir specifies a directory where sssd can find CA
certificates.

Warning

Use caution when adjusting these settings. If the correct CA certificates
are not already deployed to the servers that perform LDAP authentication,
their attempts to authenticate users might fail.

Consult with administrators of the LDAP system and test all changes on
a non-production system first.

The operating system must implement cryptography to protect the integrity of Lightweight Directory Access Protocol (LDAP) communications. (V-72231)¶

Without cryptographic integrity protections, information can be altered by unauthorized users without detection.

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 key used to generate the hash.

Deployers are strongly urged to utilize sssd for systems that authenticate
against LDAP or Active Directory (AD) servers.

To meet this control, deployers must ensure that ldap_tls_cacert or
ldap_tls_cacertdir are set in the /etc/sssd/sssd.conf file. The
ldap_tls_cacert directive specifies a single certificate while
ldap_tls_cacertdir specifies a directory where sssd can find CA
certificates.

Warning

Use caution when adjusting these settings. If the correct CA certificates
are not already deployed to the servers that perform LDAP authentication,
their attempts to authenticate users might fail.

Consult with administrators of the LDAP system and test all changes on
a non-production system first.

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, logical means (cryptography) do not have to be employed, and vice versa.

All networked systems must use SSH for confidentiality and integrity of transmitted and received information as well as information during preparation for transmission. (V-72235)¶

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.

The STIG has a requirement that the sshd daemon is running and enabled at
boot time. The tasks in the security role ensure that these requirements are
met.

Some deployers may not have sshd enabled on highly specialized systems and
those deployers should opt out of this change by setting the following Ansible
variable:

security_enable_sshd:no

Note

Setting security_enable_sshd to no causes the tasks to ignore the
state of the service entirely. A setting of no does not stop or alter
the sshd service.

All network connections associated with SSH traffic must terminate at the end of the session or after 10 minutes of inactivity, except to fulfill documented and validated mission requirements. (V-72237)¶

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.

The ClientAliveInterval configuration is set to 600 in
/etc/ssh/sshd_config and sshd is restarted.

Deployers can adjust the length of the interval by changing the following
Ansible variable:

security_sshd_client_alive_interval:600

Note

The STIG requires that ClientAliveInterval is set to 600 and
ClientAliveCountMax is set to zero, which sets a 10 minute session
timeout. If no data is transferred in a 10 minute period, the session is
disconnected.

The ClientAliveInterval specifies how long the ssh daemon waits
before it sends a message to the client to see if it is still alive. The
ClientAliveCountMax specifies how many of these messages are sent
without receiving a response.

All network connections associated with SSH traffic must terminate after a period of inactivity. (V-72241)¶

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.

The ClientAliveCountMax configuration is set to 0 in
/etc/ssh/sshd_config and sshd is restarted.

Deployers can adjust the maximum amount of client alive intervals by changing
the following Ansible variable.

security_sshd_client_alive_count_max:0

Note

The STIG requires that ClientAliveInterval is set to 600 and
ClientAliveCountMax is set to zero, which sets a 10 minute session
timeout. If no data is transferred in a 10 minute period, the session is
disconnected.

The ClientAliveInterval specifies how long the ssh daemon waits
before it sends a message to the client to see if it is still alive. The
ClientAliveCountMax specifies how many of these messages are sent
without receiving a response.

The system must not permit direct logons to the root account using remote access via SSH. (V-72247)¶

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.

The PermitRootLogin configuration is set to no in
/etc/ssh/sshd_config and sshd is restarted.

Deployers can select another setting for PermitRootLogin, from the available
options without-password, prohibit-password, forced-commands-only,
yes, or no by setting the following variable:

security_sshd_permit_root_login:no

Warning

Ensure that a regular user account exists with a pathway to root access
(preferably via sudo) before applying the security role. This
configuration change disallows any direct logins with the root
user.

The SSH daemon must not allow authentication using known hosts authentication. (V-72249)¶

GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system’s GSSAPI to remote hosts, increasing the attack surface of the system. GSSAPI authentication must be disabled unless needed.

Kerberos authentication for SSH is often implemented using Generic Security Service Application Program Interface (GSSAPI). If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system’s Kerberos implementation. Vulnerabilities in the system’s Kerberos implementation may then be subject to exploitation. To reduce the attack surface of the system, the Kerberos authentication mechanism within SSH must be disabled for systems not using this capability.

The SSH daemon must not allow compression or must only allow compression after successful authentication. (V-72267)¶

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.

The Compression configuration is set to delayed in
/etc/ssh/sshd_config and sshd is restarted.

Deployers can choose another option by setting the following Ansible variable:

security_sshd_compression:'no'

Note

The following are the available settings for Compression in the ssh
configuration file:

delayed: Compression is enabled after authentication.

no: Compression is disabled.

yes: Compression is enabled during authentication and during the
session (not allowed by the STIG).

The delayed option balances security with performance and is an
approved option in the STIG.

The operating system must, for networked systems, synchronize clocks with a server that is synchronized to one of the redundant United States Naval Observatory (USNO) time servers, a time server designated for the appropriate DoD network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS). (V-72269)¶

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate.

Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints).

The tasks in the security role make the following changes on each host:

The chrony package is installed.

The service (chronyd on Red Hat, CentOS, SLE and openSUSE Leap,
chrony on Ubuntu) is started and enabled at boot time.

A configuration file template is deployed that includes maxpoll10 on
each server line.

Deployers can opt out of these changes by setting the following Ansible
variable:

security_rhel7_enable_chrony:no

Note

Although the STIG mentions the traditional ntpd service, this role uses
chrony, which is a more modern implementation.

The operating system must protect against or limit the effects of Denial of Service (DoS) attacks by validating the operating system is implementing rate-limiting measures on impacted network interfaces. (V-72271)¶

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.

This requirement addresses the configuration of the operating system to mitigate the impact of DoS attacks that have occurred or are ongoing on system availability. For each system, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or establishing memory partitions). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.

Although the STIG requires that incoming TCP connections are rate limited with
firewalld, this setting can cause problems with certain applications which
handle large amounts of TCP connections. Therefore, the tasks in the security
role do not apply the rate limit by default.

Deployers can opt in for this change by setting the following Ansible variable:

security_enable_firewalld_rate_limit:yes

The STIG recommends a limit of 25 connection per minute and allowing bursts up
to 100 connections. Both of these options are adjustable with the following
Ansible variables:

Deployers should test rate limiting in a non-production environment first
before applying it to production systems. Ensure that the application
running on the system is receiving a large volume of requests so that the
rule can be thoroughly tested.

The operating system must enable an application firewall, if available. (V-72273)¶

The STIG requires that a firewall is configured on each server. This might be
disruptive to some environments since the default firewall policy for
firewalld is very restrictive. Therefore, the tasks in the security role
do not install or enable the firewalld daemon by default.

Deployers can opt in for this change by setting the following Ansible variable:

security_enable_firewalld:yes

Warning

Deployers must pre-configure firewalld or copy over a working XML file
in /etc/firewalld/zones/ from another server. The default firewalld
restrictions on Ubuntu, CentOS, Red Hat Enterprise Linux and openSUSE Leap
are highly restrictive.

The system must display the date and time of the last successful account logon upon logon. (V-72275)¶

The PAM configuration is checked for the presence of pam_lastlogin and a
warning message is printed if the directive is not found. The tasks in the
security role do not adjust PAM configurations since these changes might be
disruptive in some environments.

Deployers should review their PAM configurations and add pam_lastlogin to
/etc/pam.d/postlogin on CentOS and Red Hat Enterprise Linux or to
/etc/pam.d/login on Ubuntu, openSUSE Leap and SUSE Linux Enterprise.

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.

The shosts.equiv files are used to configure host-based authentication for 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.

For systems using DNS resolution, at least two name servers must be configured. (V-72281)¶

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.

The system must not forward Internet Protocol version 4 (IPv4) source-routed packets. (V-72283)¶

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.

The tasks in this role set net.ipv4.conf.all.accept_source_route and
net.ipv4.conf.default.accept_source_route to 0 by default. This
prevents the system from forwarding source-routed IPv4 packets on all
new and existing interfaces.

Deployers can opt out of this change by setting the following Ansible variable:

The system must not forward Internet Protocol version 4 (IPv4) source-routed packets by default. (V-72285)¶

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.

The system must prevent Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages from being accepted. (V-72289)¶

ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host’s route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.

The system must not allow interfaces to perform Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects by default. (V-72291)¶

ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system’s route table, possibly revealing portions of the network topology.

The tasks in this role set net.ipv4.conf.default.send_redirects and
net.ipv4.conf.all.send_redirects to 0 by default. This prevents a
system from sending IPv4 ICMP redirect packets on all new and existing
interfaces.

Deployers can opt out of this change by setting the following Ansible variable:

security_disallow_icmp_redirects:no

The system must not send Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects. (V-72293)¶

ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system’s route table, possibly revealing portions of the network topology.

Network interfaces in promiscuous mode allow for the capture of all network traffic visible to the system. If unauthorized individuals can access these applications, it may allow then to collect information such as logon IDs, passwords, and key exchanges between systems.

If the system is being used to perform a network troubleshooting function, the use of these tools must be documented with the Information System Security Officer (ISSO) and restricted to only authorized personnel.

The FTP service provides an unencrypted remote access 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. SSH or other encrypted file transfer methods must be used in place of this service.

The Trivial File Transfer Protocol (TFTP) server package must not be installed if not required for operational support. (V-72301)¶

If TFTP is required for operational support (such as the transmission of router configurations) its use must be documented with the Information System Security Officer (ISSO), restricted to only authorized personnel, and have access control rules established.

The tasks in the security role examine the TFTP server configuration file (if
it exists) to verify that the secure operation flag (-s) is listed on the
server_args line. If it is missing, a warning message is printed in the
Ansible output.

An X Windows display manager must not be installed unless approved. (V-72307)¶

Internet services that are not required for system or application processes must not be active to decrease the attack surface of the system. X Windows has a long history of security vulnerabilities and will not be used unless approved and documented.

The system must not be performing packet forwarding unless the system is a router. (V-72309)¶

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.

Disabling IP forwarding on a system that routes packets or host virtual
machines might cause network interruptions. The tasks in this role do not
adjust the net.ipv4.ip_forward configuration by default.

Deployers can opt in for this change and disable IP forwarding by setting the
following Ansible variable:

security_disallow_ip_forwarding:yes

Warning

IP forwarding is required in some environments. Always test in a
non-production environment before changing this setting on a production
system.

The Network File System (NFS) must be configured to use RPCSEC_GSS. (V-72311)¶

When an NFS server is configured to use RPCSEC_SYS, a selected userid and groupid are used to handle requests from the remote user. The userid and groupid could mistakenly or maliciously be set incorrectly. The RPCSEC_GSS method of authentication uses certificates on the server and client systems to more securely authenticate the remote mount request.

Whether active or not, default Simple Network Management Protocol (SNMP) community strings must be changed to maintain security. If the service is running with the default authenticators, anyone can gather data about the system and the network and use the information to potentially compromise the integrity of the system or network(s). It is highly recommended that SNMP version 3 user authentication and message encryption be used in place of the version 2 community strings.

The tasks in the security role examine the contents of the
/etc/snmp/snmpd.conf file (if it exists) and search for the default
community strings: public and private. If either default string is
found, a message is printed in the Ansible output.

The system access control program must be configured to grant or deny system access to specific hosts and services. (V-72315)¶

Deployers should review their firewalld ruleset regularly to ensure that
each firewall rule is specific as possible. Each rule should allow the smallest
number of hosts to access the smallest number of services.

The system must not have unauthorized IP tunnels configured. (V-72317)¶

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv6 forwarding is enabled and the system is functioning as a router.

The operating system must have the required packages for multifactor authentication installed. (V-72417)¶

Using an authentication device, such as a 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 card and the DoD Common Access Card.

A privileged account is defined as an information system account with authorizations of a privileged user.

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

The STIG requires that the following multifactor authentication packages are
installed:

authconfig

authconfig-gtk

esc

pam_pkcs11

These packages are benign if they are not needed on a system, but
authconfig-gtk may cause some graphical dependencies to be installed
which may not be needed on some systems. The security role installs these
packages, but it skips the installation of authconfig-gtk. Deployers can
install the graphical package manually if needed.

Using an authentication device, such as a 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 card and the DoD Common Access Card.

A privileged account is defined as an information system account with authorizations of a privileged user.

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

Although the STIG requires that the sssd.conf contains both nss and
pam authentication modules, this change can be disruptive in environments
that are already using LDAP or Active Directory for authentication. Deployers
should make these changes only if their environment is compatible.

The operating system must implement certificate status checking for PKI authentication. (V-72433)¶

Using an authentication device, such as a 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 card and the DoD Common Access Card.

A privileged account is defined as an information system account with authorizations of a privileged user.

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

The operating system must implement smart card logons for multifactor authentication for access to privileged accounts. (V-72435)¶

Using an authentication device, such as a 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 card and the DoD Common Access Card.

A privileged account is defined as an information system account with authorizations of a privileged user.

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

The operating system must set the lock delay setting for all connection types. (V-73155)¶

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.

The operating system must set the session idle delay setting for all connection types. (V-73157)¶

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.

When passwords are changed or new passwords are established, pwquality must be used. (V-73159)¶

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. “Pwquality” enforces complex password construction configuration on the system.

The security role can require new or changed passwords to follow the pwquality
rules, but this change can be disruptive for users without proper
communication. Deployers must opt in for this change by setting the following
variable:

security_enable_pwquality_password_set:yes

File systems that are being imported via Network File System (NFS) must be mounted to prevent binary files from being executed. (V-73161)¶

The “noexec” mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

The operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/group. (V-73165)¶

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 operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/gshadow. (V-73167)¶

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 operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow. (V-73171)¶

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 operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/opasswd. (V-73173)¶

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

ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host’s route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.

The use of wireless networking can introduce many different attack vectors into the organization’s network. Common attack vectors such as malicious association and ad hoc networks will allow an attacker to spoof a wireless access point (AP), allowing validated systems to connect to the malicious AP and enabling the attacker to monitor and record network traffic. These malicious APs can also serve to create a man-in-the-middle attack or be used to create a denial of service to valid network resources.

Deployers should review the configuration of any wireless networking device
connected to the system to ensure it must be enabled. The STIG requires that
all wireless network devices are enabled unless required.

The operating system must uniquely identify and must authenticate users using multifactor authentication via a graphical user logon. (V-77819)¶

To assure accountability and prevent unauthenticated access, users must be identified and authenticated to prevent potential misuse and compromise of the system.

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 card and the DoD Common Access Card.

The operating system must require authentication upon booting into single-user and maintenance modes. (V-77823)¶

If the system does not require valid root authentication before it boots into single-user or maintenance mode, anyone who invokes single-user or maintenance mode is granted privileged access to all files on the system.

Modifying sensitive systemd unit files directly or via overrides could cause
a system to have issues during the boot process. The role does not make any
adjustments to the rescue.service because this service is critical during
emergencies.

All of the distributions supported by the role already require authentication
for single user mode.

The operating system must implement virtual address space randomization. (V-77825)¶

Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code he or she has introduced into a process’s address space during an attempt at exploitation. Additionally, ASLR also makes it more difficult for an attacker to know the location of existing code in order to repurpose it using return-oriented programming (ROP) techniques.