This PR follows #14834 and continues addressing issue #8709.

linux_os/guide/services/http/securing_httpd/httpd_public_resources_not_shared/rule.yml

@@ -13,8 +13,8 @@ rationale: |-
     public web server and private servers the intent of data and resource
     segregation can be compromised.
 
-    In addition to the requirements of the DoD Internet-NIPRNet DMZ STIG that
-    isolates inbound traffic from external network to the internal network,
+    In addition to the requirements of applicable DMZ segmentation policies that
+    isolate inbound traffic from the external network to the internal network,
     resources such as printers, files, and folders/directories will not be
     shared between public web servers and assets located within the internal
     network.

linux_os/guide/services/ssh/ssh_client/ssh_use_approved_macs_ordered_stig/rule.yml

@@ -14,8 +14,9 @@ description: |-
     is commented out, or is missing, this is a finding.
 
 rationale: |-
-    DoD Information Systems are required to use FIPS-approved cryptographic hash
-    functions. The only hash algorithms meeting this requirement is SHA2.
+    FIPS-approved cryptographic hash functions are required for protecting the
+    integrity of communications. The only hash algorithms meeting this requirement
+    are SHA2-based algorithms.
 
 severity: medium
 

linux_os/guide/services/sssd/sssd_certificate_verification/policy/stig/shared.yml

@@ -2,9 +2,9 @@ srg_requirement: |-
     {{{ full_name }}} must implement certificate status checking for multifactor authentication.
 
 vuldiscussion: |-
-    Using an authentication device, such as a DoD Common Access Card (CAC) or token that is separate from the information system, ensures that even if the information system is compromised, credentials stored on the authentication device will not be affected.
+    Using an authentication device, such as a hardware token or smart card that is separate from the information system, ensures that even if the information system is compromised, credentials stored on the authentication device will not be affected.
 
-    Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification (PIV) card and the DoD CAC.
+    Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification (PIV) card.
 
     {{{ full_name }}} includes multiple options for configuring certificate status checking, but for this requirement focuses on the System Security Services Daemon (SSSD). By default, sssd performs Online Certificate Status Protocol (OCSP) checking and certificate verification using a sha256 digest function.
 

linux_os/guide/system/accounts/accounts-banners/banner_etc_issue_net/rule.yml

@@ -8,7 +8,7 @@ description: |-
     default text with a message compliant with the local site policy or a legal
     disclaimer.
 
-    The DoD required text is either:
+    The required text is either:
     <br /><br />
     <tt>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

linux_os/guide/system/accounts/accounts-banners/banner_etc_motd/rule.yml

@@ -8,7 +8,7 @@ description: |-
     default text with a message compliant with the local site policy or a legal
     disclaimer.
 
-    The DoD required text is either:
+    The required text is either:
     <br /><br />
     <tt>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

linux_os/guide/system/accounts/accounts-banners/banner_etc_profiled_ssh_confirm/rule.yml

@@ -4,10 +4,10 @@
 title: 'Enable the SSH login confirmation banner'
 
 description: |-
-    This rule verifies that that the SSH login confirmation banner is set 
+    This rule verifies that that the SSH login confirmation banner is set
     correctly.
 
-    The DoD required text is:
+    The required text is:
     <br /><br />
     <tt>if [ -n "$SSH_CLIENT" ] || [ -n "$SSH_TTY" ]; then<br/>
             while true; do<br/>
@@ -45,7 +45,7 @@
     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.
-    
+
 severity: medium
 
 ocil_clause: 'it does not display the required banner'
@@ -54,4 +54,4 @@
     To check if the system motd banner is compliant,
     run the following command:
     <pre>$ less /etc/profile.d/ssh_confirm.sh</pre>
 

linux_os/guide/system/accounts/accounts-banners/gui_login_banner/banner_etc_gdm_banner/rule.yml

@@ -8,7 +8,7 @@ description: |-
     Replace the default text with a message compliant with the local site
     policy or a legal disclaimer.
 
-    The DoD required text is either:
+    The required text is either:
     <br /><br />
     <tt>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

linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_minlen/policy/stig/shared.yml

@@ -10,7 +10,6 @@ vuldiscussion: |-
 
     The "minlen", sometimes noted as minimum length, acts as a "score" of complexity based on the credit components of the "pwquality" module. By setting the credit components to a negative value, not only will those components be required, they will not count towards the total "score" of "minlen". This will enable "minlen" to require a 15-character minimum.
 
-    The DoD minimum password requirement is 15 characters.
 
 checktext: |-
     Verify that {{{ full_name }}} enforces a minimum 15-character password length with the following command:

linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_algorithm_systemauth/policy/stig/rhel10.yml

@@ -3,11 +3,11 @@ srg_requirement: |-
     {{{ full_name }}} pam_unix.so module must be configured in the system-auth file to use a FIPS 140-3 approved cryptographic hashing algorithm for system authentication.
 
 vuldiscussion: |-
-    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.
+    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 sensitive data may be compromised.
 
     {{{ full_name }}} systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules.
 
-    FIPS 140-3 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.
+    FIPS 140-3 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets organizational requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.
 
 checktext: |-
     Verify that the pam_unix.so module is configured to use yescrypt in /etc/pam.d/system-auth with the following command:

linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_algorithm_systemauth/policy/stig/shared.yml

@@ -2,11 +2,11 @@ srg_requirement: |-
     {{{ full_name }}} pam_unix.so module must be configured in the system-auth file to use a FIPS 140-3 approved cryptographic hashing algorithm for system authentication.
 
 vuldiscussion: |-
-    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.
+    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 sensitive data may be compromised.
 
     {{{ full_name }}} systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules.
 
-    FIPS 140-3 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.
+    FIPS 140-3 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets organizational requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.
 
 checktext: |-
     Verify that the pam_unix.so module is configured to use sha512 in /etc/pam.d/system-auth with the following command:

linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/var_smartcard_drivers.var

@@ -4,7 +4,6 @@ title: 'OpenSC Smart Card Drivers'
 
 description: |-
     Choose the Smart Card Driver in use by your organization.
-    <br />For DoD, choose the <tt>cac</tt> driver.
     <br />If your driver is not listed and you don't want to use the
     <tt>default</tt> driver, use the <tt>other</tt> option and
     manually specify your driver.
@@ -46,7 +45,7 @@ options:
     npa: npa
     oberthur: oberthur
     openpgp: openpgp
-    other: 
+    other:
     PIV-II: PIV-II
     rutoken_ecp: rutoken_ecp
     rutoken: rutoken

linux_os/guide/system/network/network-firewalld/ruleset_modifications/set_firewalld_default_zone/policy/stig/shared.yml

@@ -2,7 +2,7 @@ srg_requirement: |-
     A {{{ full_name }}} firewall must employ a deny-all, allow-by-exception policy for allowing connections to other systems.
 
 vuldiscussion: |-
-    Failure to restrict network connectivity only to authorized systems permits inbound connections from malicious systems. It also permits outbound connections that may facilitate exfiltration of DoD data.
+    Failure to restrict network connectivity only to authorized systems permits inbound connections from malicious systems. It also permits outbound connections that may facilitate exfiltration of sensitive data.
 
     {{{ full_name }}} incorporates the "firewalld" daemon, which allows for many different configurations. One of these configurations is zones. Zones can be utilized to a deny-all, allow-by-exception approach. The default "drop" zone will drop all incoming network packets unless it is explicitly allowed by the configuration file or is related to an outgoing network connection.
 

linux_os/guide/system/software/integrity/crypto/configure_gnutls_tls_crypto_policy/rule.yml

@@ -1,7 +1,7 @@
 documentation_complete: true
 
 
-title: 'Configure GnuTLS library to use DoD-approved TLS Encryption'
+title: 'Configure GnuTLS library to use Approved TLS Encryption'
 
 description: |-
     Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
@@ -33,17 +33,17 @@ references:
 ocil_clause: 'cryptographic policy for gnutls is not configured or is configured incorrectly'
 
 ocil: |-
-    To verify if GnuTLS uses defined DoD-approved TLS Crypto Policy, run:
+    To verify if GnuTLS uses the defined approved TLS Crypto Policy, run:
     <pre>$ sudo grep
     '+VERS-ALL:-VERS-DTLS0.9:-VERS-TLS1.1:-VERS-TLS1.0:-VERS-SSL3.0:-VERS-DTLS1.0'
     /etc/crypto-policies/back-ends/gnutls.config</pre> and verify that a match exists.
 
 fixtext: |-
-    Configure the {{{ full_name }}} GnuTLS library to use only DoD-approved encryption by adding the following line to "/etc/crypto-policies/back-ends/gnutls.config":
+    Configure the {{{ full_name }}} GnuTLS library to use only approved encryption by adding the following line to "/etc/crypto-policies/back-ends/gnutls.config":
 
     +VERS-ALL:-VERS-DTLS0.9:-VERS-TLS1.1:-VERS-TLS1.0:-VERS-SSL3.0:-VERS-DTLS1.0
 
     A reboot is required for the changes to take effect.
 
 srg_requirement:
-    {{{ full_name }}} must implement DoD-approved TLS encryption in the GnuTLS package.
+    {{{ full_name }}} must implement approved TLS encryption in the GnuTLS package.

linux_os/guide/system/software/integrity/crypto/harden_sshd_macs_opensshserver_conf_crypto_policy/policy/stig/shared.yml

@@ -4,7 +4,7 @@ srg_requirement: |-
 vuldiscussion: |-
     Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
 
-    Remote access (e.g., RDP) is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
+    Remote access (e.g., RDP) is access to nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
 
     Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash.
 

linux_os/guide/system/software/updating/ensure_gpgcheck_repo_metadata/rule.yml

@@ -23,8 +23,8 @@ rationale: |-
     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. NOTE: For U.S. Military systems, this
-    requirement does not mandate DoD certificates for this purpose; however,
+    to verify the software again. NOTE: For regulated systems, this requirement
+    does not mandate organization-specific certificates for this purpose; however,
     the certificate used to verify the software must be from an approved
     Certificate Authority.