build_shorthand.py from SCAP Security Guide ssg: 0.1.81 2.0 2026-04-01T21:16:40 Set Account Expiration Following Inactivity ocil:ssg-account_disable_post_pw_expiration_action:testaction:1 Assign Expiration Date to Temporary Accounts ocil:ssg-account_temp_expire_date_action:testaction:1 Limit the Number of Concurrent Login Sessions Allowed Per User ocil:ssg-accounts_max_concurrent_login_sessions_action:testaction:1 Set Password Maximum Age ocil:ssg-accounts_maximum_age_login_defs_action:testaction:1 Set Password Minimum Age ocil:ssg-accounts_minimum_age_login_defs_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Digit Characters ocil:ssg-accounts_password_pam_dcredit_action:testaction:1 Ensure PAM Enforces Password Requirements - Prevent the Use of Dictionary Words ocil:ssg-accounts_password_pam_dictcheck_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Different Characters ocil:ssg-accounts_password_pam_difok_action:testaction:1 Ensure PAM Enforces Password Requirements - Enforcing ocil:ssg-accounts_password_pam_enforcing_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters ocil:ssg-accounts_password_pam_lcredit_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Length ocil:ssg-accounts_password_pam_minlen_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Special Characters ocil:ssg-accounts_password_pam_ocredit_action:testaction:1 Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session ocil:ssg-accounts_password_pam_retry_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters ocil:ssg-accounts_password_pam_ucredit_action:testaction:1 Set number of Password Hashing Rounds - password-auth ocil:ssg-accounts_password_pam_unix_rounds_password_auth_action:testaction:1 Enforce Delay After Failed Logon Attempts ocil:ssg-accounts_passwords_pam_faildelay_delay_action:testaction:1 Account Lockouts Must Be Logged ocil:ssg-accounts_passwords_pam_faillock_audit_action:testaction:1 Lock Accounts After Failed Password Attempts ocil:ssg-accounts_passwords_pam_faillock_deny_action:testaction:1 Set Interval For Counting Failed Password Attempts ocil:ssg-accounts_passwords_pam_faillock_interval_action:testaction:1 Do Not Show System Messages When Unsuccessful Logon Attempts Occur ocil:ssg-accounts_passwords_pam_faillock_silent_action:testaction:1 Set Lockout Time for Failed Password Attempts ocil:ssg-accounts_passwords_pam_faillock_unlock_time_action:testaction:1 Set Interactive Session Timeout ocil:ssg-accounts_tmout_action:testaction:1 Ensure the Default Umask is Set Correctly in login.defs ocil:ssg-accounts_umask_etc_login_defs_action:testaction:1 Build and Test AIDE Database ocil:ssg-aide_build_database_action:testaction:1 Configure AIDE to Verify the Audit Tools ocil:ssg-aide_check_audit_tools_action:testaction:1 Configure AIDE To Notify Personnel if Baseline Configurations Are Altered ocil:ssg-aide_disable_silentreports_action:testaction:1 Configure Periodic Execution of AIDE ocil:ssg-aide_periodic_cron_checking_action:testaction:1 Ensure AppArmor is Active and Configured ocil:ssg-apparmor_configured_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - chmod ocil:ssg-audit_rules_dac_modification_chmod_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - chown ocil:ssg-audit_rules_dac_modification_chown_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fchmod ocil:ssg-audit_rules_dac_modification_fchmod_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fchmodat ocil:ssg-audit_rules_dac_modification_fchmodat_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fchown ocil:ssg-audit_rules_dac_modification_fchown_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fchownat ocil:ssg-audit_rules_dac_modification_fchownat_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fremovexattr ocil:ssg-audit_rules_dac_modification_fremovexattr_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fsetxattr ocil:ssg-audit_rules_dac_modification_fsetxattr_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - lchown ocil:ssg-audit_rules_dac_modification_lchown_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - lremovexattr ocil:ssg-audit_rules_dac_modification_lremovexattr_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - lsetxattr ocil:ssg-audit_rules_dac_modification_lsetxattr_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - removexattr ocil:ssg-audit_rules_dac_modification_removexattr_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - setxattr ocil:ssg-audit_rules_dac_modification_setxattr_action:testaction:1 Ensure auditd Collects Changes to Cron Jobs - /etc/cron.d/ ocil:ssg-audit_rules_etc_cron_d_action:testaction:1 Record Any Attempts to Run chacl ocil:ssg-audit_rules_execution_chacl_action:testaction:1 Record Any Attempts to Run chcon ocil:ssg-audit_rules_execution_chcon_action:testaction:1 Record Any Attempts to Run setfacl ocil:ssg-audit_rules_execution_setfacl_action:testaction:1 Ensure auditd Collects File Deletion Events by User - rename ocil:ssg-audit_rules_file_deletion_events_rename_action:testaction:1 Ensure auditd Collects File Deletion Events by User - renameat ocil:ssg-audit_rules_file_deletion_events_renameat_action:testaction:1 Ensure auditd Collects File Deletion Events by User - rmdir ocil:ssg-audit_rules_file_deletion_events_rmdir_action:testaction:1 Ensure auditd Collects File Deletion Events by User - unlink ocil:ssg-audit_rules_file_deletion_events_unlink_action:testaction:1 Ensure auditd Collects File Deletion Events by User - unlinkat ocil:ssg-audit_rules_file_deletion_events_unlinkat_action:testaction:1 Ensure auditd Collects Information on Kernel Module Unloading - delete_module ocil:ssg-audit_rules_kernel_module_loading_delete_action:testaction:1 Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module ocil:ssg-audit_rules_kernel_module_loading_finit_action:testaction:1 Ensure auditd Collects Information on Kernel Module Loading - init_module ocil:ssg-audit_rules_kernel_module_loading_init_action:testaction:1 Record Attempts to Alter Logon and Logout Events - faillog ocil:ssg-audit_rules_login_events_faillog_action:testaction:1 Record Attempts to Alter Logon and Logout Events - lastlog ocil:ssg-audit_rules_login_events_lastlog_action:testaction:1 Record Any Attempts to Run apparmor_parser ocil:ssg-audit_rules_privileged_commands_apparmor_parser_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - chage ocil:ssg-audit_rules_privileged_commands_chage_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - chfn ocil:ssg-audit_rules_privileged_commands_chfn_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - chsh ocil:ssg-audit_rules_privileged_commands_chsh_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - crontab ocil:ssg-audit_rules_privileged_commands_crontab_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - fdisk ocil:ssg-audit_rules_privileged_commands_fdisk_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd ocil:ssg-audit_rules_privileged_commands_gpasswd_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - kmod ocil:ssg-audit_rules_privileged_commands_kmod_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - modprobe ocil:ssg-audit_rules_privileged_commands_modprobe_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - mount ocil:ssg-audit_rules_privileged_commands_mount_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - newgrp ocil:ssg-audit_rules_privileged_commands_newgrp_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check ocil:ssg-audit_rules_privileged_commands_pam_timestamp_check_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - passwd ocil:ssg-audit_rules_privileged_commands_passwd_action:testaction:1 Record Any Attempts to Run ssh-agent ocil:ssg-audit_rules_privileged_commands_ssh_agent_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign ocil:ssg-audit_rules_privileged_commands_ssh_keysign_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - su ocil:ssg-audit_rules_privileged_commands_su_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - sudo ocil:ssg-audit_rules_privileged_commands_sudo_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - sudoedit ocil:ssg-audit_rules_privileged_commands_sudoedit_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - umount ocil:ssg-audit_rules_privileged_commands_umount_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - unix_update ocil:ssg-audit_rules_privileged_commands_unix_update_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - usermod ocil:ssg-audit_rules_privileged_commands_usermod_action:testaction:1 Record Attempts to Alter Process and Session Initiation Information btmp ocil:ssg-audit_rules_session_events_btmp_action:testaction:1 Record Attempts to Alter Process and Session Initiation Information utmp ocil:ssg-audit_rules_session_events_utmp_action:testaction:1 Record Attempts to Alter Process and Session Initiation Information wtmp ocil:ssg-audit_rules_session_events_wtmp_action:testaction:1 Ensure auditd Collects System Administrator Actions - /etc/sudoers ocil:ssg-audit_rules_sudoers_action:testaction:1 Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/ ocil:ssg-audit_rules_sudoers_d_action:testaction:1 Record Events When Privileged Executables Are Run ocil:ssg-audit_rules_suid_privilege_function_action:testaction:1 Record Unsuccessful Access Attempts to Files - creat ocil:ssg-audit_rules_unsuccessful_file_modification_creat_action:testaction:1 Record Unsuccessful Access Attempts to Files - ftruncate ocil:ssg-audit_rules_unsuccessful_file_modification_ftruncate_action:testaction:1 Record Unsuccessful Access Attempts to Files - open ocil:ssg-audit_rules_unsuccessful_file_modification_open_action:testaction:1 Record Unsuccessful Access Attempts to Files - open_by_handle_at ocil:ssg-audit_rules_unsuccessful_file_modification_open_by_handle_at_action:testaction:1 Record Unsuccessful Access Attempts to Files - openat ocil:ssg-audit_rules_unsuccessful_file_modification_openat_action:testaction:1 Record Unsuccessful Access Attempts to Files - truncate ocil:ssg-audit_rules_unsuccessful_file_modification_truncate_action:testaction:1 Record Events that Modify User/Group Information - /etc/group ocil:ssg-audit_rules_usergroup_modification_group_action:testaction:1 Record Events that Modify User/Group Information - /etc/gshadow ocil:ssg-audit_rules_usergroup_modification_gshadow_action:testaction:1 Record Events that Modify User/Group Information - /etc/security/opasswd ocil:ssg-audit_rules_usergroup_modification_opasswd_action:testaction:1 Record Events that Modify User/Group Information - /etc/passwd ocil:ssg-audit_rules_usergroup_modification_passwd_action:testaction:1 Record Events that Modify User/Group Information - /etc/shadow ocil:ssg-audit_rules_usergroup_modification_shadow_action:testaction:1 Ensure auditd Collects records for events that affect "/var/log/journal" ocil:ssg-audit_rules_var_log_journal_action:testaction:1 Ensure auditd Collects Changes to Cron Jobs - /var/spool/cron ocil:ssg-audit_rules_var_spool_cron_action:testaction:1 Record Attempts to perform maintenance activities ocil:ssg-audit_sudo_log_events_action:testaction:1 Configure audispd Plugin To Send Logs To Remote Server ocil:ssg-auditd_audispd_configure_remote_server_action:testaction:1 Configure a Sufficiently Large Partition for Audit Logs ocil:ssg-auditd_audispd_configure_sufficiently_large_partition_action:testaction:1 Configure auditd Disk Full Action when Disk Space Is Full ocil:ssg-auditd_data_disk_full_action_action:testaction:1 Configure auditd mail_acct Action on Low Disk Space ocil:ssg-auditd_data_retention_action_mail_acct_action:testaction:1 Configure auditd space_left Action on Low Disk Space ocil:ssg-auditd_data_retention_space_left_action_action:testaction:1 Configure auditd space_left on Low Disk Space ocil:ssg-auditd_data_retention_space_left_percentage_action:testaction:1 Offload audit Logs to External Media ocil:ssg-auditd_offload_logs_action:testaction:1 Modify the System Login Banner for Remote Connections ocil:ssg-banner_etc_issue_net_action:testaction:1 Enable NX or XD Support in the BIOS ocil:ssg-bios_enable_execution_restrictions_action:testaction:1 Configure Time Service Maxpoll Interval ocil:ssg-chronyd_or_ntpd_set_maxpoll_action:testaction:1 Synchronize internal information system clocks ocil:ssg-chronyd_sync_clock_action:testaction:1 Ensure apt_get Removes Previous Package Versions ocil:ssg-clean_components_post_updating_action:testaction:1 Claroty CTD must accept the DOD CAC or other PKI credential for identity management and personal authentication. ocil:ssg-ctd5_accept_dod_cac_or_pki_for_authentication_action:testaction:1 Claroty CTD must alert the information system security officer (ISSO), information system security manager (ISSM), and other individuals designated by the local organization when events are detected that indicate a compromise or potential for compromise. ocil:ssg-ctd5_alert_isso_issm_on_compromise_events_action:testaction:1 Claroty CTD must allocate audit record storage retention length. ocil:ssg-ctd5_allocate_audit_record_storage_retention_action:testaction:1 Claroty CTD must only allow authorized local accounts as documented in the System Security Plan (SSP). ocil:ssg-ctd5_allow_only_authorized_local_accounts_action:testaction:1 Before establishing a network connection with a Network Time Protocol (NTP) server, Claroty CTD must authenticate using a bidirectional, cryptographically based authentication method that uses a FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to authenticate with the NTP server. ocil:ssg-ctd5_authenticate_ntp_with_bidirectional_crypto_action:testaction:1 Change Default Administrator Password ocil:ssg-ctd5_change_default_admin_password_action:testaction:1 Claroty CTD must configure local password policies. ocil:ssg-ctd5_configure_local_password_policies_action:testaction:1 Claroty CTD must have disk encryption enabled on virtual machines (VMs). ocil:ssg-ctd5_disk_encryption_enabled_for_vms_action:testaction:1 Claroty CTD must display the Standard Mandatory DOD Notice and Consent Banner before granting local or remote access to the system. ocil:ssg-ctd5_display_dod_banner_before_system_access_action:testaction:1 The publicly accessible Claroty CTD application must display the Standard Mandatory DOD Notice and Consent Banner before granting access to Claroty CTD. ocil:ssg-ctd5_display_dod_banner_before_web_access_action:testaction:1 Claroty CTD must configure idle timeouts at 10 minutes. ocil:ssg-ctd5_idle_timeout_10_minutes_action:testaction:1 Claroty CTD must have notification and audit services operational. ocil:ssg-ctd5_notification_and_audit_services_operational_action:testaction:1 Claroty CTD must notify system administrators and information system security officer (ISSO) of local account activity. ocil:ssg-ctd5_notify_admins_and_isso_of_local_account_activity_action:testaction:1 Claroty CTD must only allow the use of DOD PKI established certificate authorities for verification of the establishment of protected sessions. ocil:ssg-ctd5_only_allow_dod_pki_certificate_authorities_action:testaction:1 Claroty CTD must allow only the individuals appointed by the information system security manager (ISSM) to have full admin rights to the system. ocil:ssg-ctd5_only_issm_appointed_admins_have_full_rights_action:testaction:1 Claroty CTD must limit privileges and restrict administrative shell access. ocil:ssg-ctd5_restrict_administrative_shell_access_action:testaction:1 Claroty CTD must be configured to send backup audit records. ocil:ssg-ctd5_send_backup_audit_records_action:testaction:1 The Claroty CTD Syslog client must use TCP connections. ocil:ssg-ctd5_syslog_client_uses_tcp_action:testaction:1 Claroty CTD must use FIPS-validated encryption and hashing algorithms to protect the confidentiality and integrity of application configuration files and user-generated data stored or aggregated on the device. ocil:ssg-ctd5_use_fips_validated_encryption_and_hashing_action:testaction:1 Claroty CTD must use an Identity Provider (IDP) for authentication and authorization processes. ocil:ssg-ctd5_use_identity_provider_for_authentication_action:testaction:1 Enable GNOME3 Login Warning Banner ocil:ssg-dconf_gnome_banner_enabled_action:testaction:1 Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME3 ocil:ssg-dconf_gnome_disable_ctrlaltdel_reboot_action:testaction:1 Set the GNOME3 Login Warning Banner Text ocil:ssg-dconf_gnome_login_banner_text_action:testaction:1 Set GNOME3 Screensaver Inactivity Timeout ocil:ssg-dconf_gnome_screensaver_idle_delay_action:testaction:1 Set GNOME3 Screensaver Lock Delay After Activation Period ocil:ssg-dconf_gnome_screensaver_lock_delay_action:testaction:1 Enable GNOME3 Screensaver Lock After Idle Period ocil:ssg-dconf_gnome_screensaver_lock_enabled_action:testaction:1 Verify that Shared Library Directories Have Root Group Ownership ocil:ssg-dir_group_ownership_library_dirs_action:testaction:1 Verify that system commands directories are group owned by root ocil:ssg-dir_groupownership_binary_dirs_action:testaction:1 Verify that System Executable Have Root Ownership ocil:ssg-dir_ownership_binary_dirs_action:testaction:1 Verify that Shared Library Directories Have Root Ownership ocil:ssg-dir_ownership_library_dirs_action:testaction:1 Verify that System Executable Directories Have Restrictive Permissions ocil:ssg-dir_permissions_binary_dirs_action:testaction:1 Verify that All World-Writable Directories Have Sticky Bits Set ocil:ssg-dir_perms_world_writable_sticky_bits_action:testaction:1 System Audit Logs Must Have Mode 0750 or Less Permissive ocil:ssg-directory_permissions_var_log_audit_action:testaction:1 Disable Ctrl-Alt-Del Reboot Activation ocil:ssg-disable_ctrlaltdel_reboot_action:testaction:1 Encrypt Partitions ocil:ssg-encrypt_partitions_action:testaction:1 Ensure real-time clock is set to UTC ocil:ssg-ensure_rtc_utc_configuration_action:testaction:1 Ensure sudo group has only necessary members ocil:ssg-ensure_sudo_group_restricted_action:testaction:1 Verify Group Who Owns the system journal ocil:ssg-file_groupowner_system_journal_action:testaction:1 Verify Group Who Owns /var/log Directory ocil:ssg-file_groupowner_var_log_action:testaction:1 Verify Group Who Owns /var/log/syslog File ocil:ssg-file_groupowner_var_log_syslog_action:testaction:1 Audit Configuration Files Must Be Owned By Group root ocil:ssg-file_groupownership_audit_configuration_action:testaction:1 Verify that system commands files are group owned by root or a system account ocil:ssg-file_groupownership_system_commands_dirs_action:testaction:1 Verify Owner on the system journal ocil:ssg-file_owner_system_journal_action:testaction:1 Verify User Who Owns /var/log Directory ocil:ssg-file_owner_var_log_action:testaction:1 Verify User Who Owns /var/log/syslog File ocil:ssg-file_owner_var_log_syslog_action:testaction:1 Verify that audit tools are owned by root ocil:ssg-file_ownership_audit_binaries_action:testaction:1 Audit Configuration Files Must Be Owned By Root ocil:ssg-file_ownership_audit_configuration_action:testaction:1 Verify that System Executables Have Root Ownership ocil:ssg-file_ownership_binary_dirs_action:testaction:1 Verify that Shared Library Files Have Root Ownership ocil:ssg-file_ownership_library_dirs_action:testaction:1 System Audit Logs Must Be Owned By Root ocil:ssg-file_ownership_var_log_audit_stig_action:testaction:1 Verify that audit tools Have Mode 0755 or less ocil:ssg-file_permissions_audit_binaries_action:testaction:1 Verify that System Executables Have Restrictive Permissions ocil:ssg-file_permissions_binary_dirs_action:testaction:1 Verify Permissions on /etc/audit/auditd.conf ocil:ssg-file_permissions_etc_audit_auditd_action:testaction:1 Verify Permissions on /etc/audit/audit.rules ocil:ssg-file_permissions_etc_audit_rules_action:testaction:1 Verify Permissions on /etc/audit/rules.d/*.rules ocil:ssg-file_permissions_etc_audit_rulesd_action:testaction:1 Verify that Shared Library Files Have Restrictive Permissions ocil:ssg-file_permissions_library_dirs_action:testaction:1 Verify Permissions on the system journal ocil:ssg-file_permissions_system_journal_action:testaction:1 Verify Permissions on /var/log Directory ocil:ssg-file_permissions_var_log_action:testaction:1 Verify Permissions on /var/log/syslog File ocil:ssg-file_permissions_var_log_syslog_action:testaction:1 Enable Auditing for Processes Which Start Prior to the Audit Daemon ocil:ssg-grub2_audit_argument_action:testaction:1 Set Boot Loader Password in grub2 ocil:ssg-grub2_password_action:testaction:1 Set the UEFI Boot Loader Password ocil:ssg-grub2_uefi_password_action:testaction:1 Install Smart Card Packages For Multifactor Authentication ocil:ssg-install_smartcard_packages_action:testaction:1 The Installed Operating System Is Vendor Supported ocil:ssg-installed_OS_is_vendor_supported_action:testaction:1 Verify '/proc/sys/crypto/fips_enabled' exists ocil:ssg-is_fips_mode_enabled_action:testaction:1 Disable Modprobe Loading of USB Storage Driver ocil:ssg-kernel_module_usb-storage_disabled_action:testaction:1 Prevent Login to Accounts With Empty Password ocil:ssg-no_empty_passwords_action:testaction:1 Ensure There Are No Accounts With Blank or Null Passwords ocil:ssg-no_empty_passwords_etc_shadow_action:testaction:1 Install AIDE ocil:ssg-package_aide_installed_action:testaction:1 Ensure the default plugins for the audit dispatcher are Installed ocil:ssg-package_audit-audispd-plugins_installed_action:testaction:1 Ensure the audit Subsystem is Installed ocil:ssg-package_audit_installed_action:testaction:1 The Chrony package is installed ocil:ssg-package_chrony_installed_action:testaction:1 Uninstall nfs-common Package ocil:ssg-package_nfs-common_removed_action:testaction:1 Uninstall nfs-kernel-server Package ocil:ssg-package_nfs-kernel-server_removed_action:testaction:1 Install the opensc Package For Multifactor Authentication ocil:ssg-package_opensc_installed_action:testaction:1 Install the OpenSSH Server Package ocil:ssg-package_openssh-server_installed_action:testaction:1 Install pam_pwquality Package ocil:ssg-package_pam_pwquality_installed_action:testaction:1 Uninstall rsh-server Package ocil:ssg-package_rsh-server_removed_action:testaction:1 Install the SSSD Package ocil:ssg-package_sssd_installed_action:testaction:1 Install ufw Package ocil:ssg-package_ufw_installed_action:testaction:1 Verify permissions of log files ocil:ssg-permissions_local_var_log_action:testaction:1 Direct root Logins Are Not Allowed ocil:ssg-prevent_direct_root_logins_action:testaction:1 Verify the system-wide library files in directories "/lib", "/lib64", "/usr/lib/" and "/usr/lib64" are group-owned by root. ocil:ssg-root_permissions_syslibrary_files_action:testaction:1 Ensure remote access methods are monitored in Rsyslog ocil:ssg-rsyslog_remote_access_monitoring_action:testaction:1 Enable auditd Service ocil:ssg-service_auditd_enabled_action:testaction:1 Disable KDump Kernel Crash Analyzer (kdump) ocil:ssg-service_kdump_disabled_action:testaction:1 Enable rsyslog Service ocil:ssg-service_rsyslog_enabled_action:testaction:1 Enable the OpenSSH Service ocil:ssg-service_sshd_enabled_action:testaction:1 Enable the SSSD Service ocil:ssg-service_sssd_enabled_action:testaction:1 Verify ufw Enabled ocil:ssg-service_ufw_enabled_action:testaction:1 Set Password Hashing Algorithm in /etc/login.defs ocil:ssg-set_password_hashing_algorithm_logindefs_action:testaction:1 Configure Smart Card Certificate Authority Validation ocil:ssg-smartcard_configure_ca_action:testaction:1 Configure Smart Card Certificate Status Checking ocil:ssg-smartcard_configure_cert_checking_action:testaction:1 Configure Smart Card Local Cache of Revocation Data ocil:ssg-smartcard_configure_crl_action:testaction:1 Enable Smart Card Logins in PAM ocil:ssg-smartcard_pam_enabled_action:testaction:1 Disable SSH Access via Empty Passwords ocil:ssg-sshd_disable_empty_passwords_action:testaction:1 Disable X11 Forwarding ocil:ssg-sshd_disable_x11_forwarding_action:testaction:1 Do Not Allow SSH Environment Options ocil:ssg-sshd_do_not_permit_user_env_action:testaction:1 Enable PAM ocil:ssg-sshd_enable_pam_action:testaction:1 Enable Public Key Authentication ocil:ssg-sshd_enable_pubkey_auth_action:testaction:1 Enable SSH Warning Banner ocil:ssg-sshd_enable_warning_banner_net_action:testaction:1 Set SSH Client Alive Interval ocil:ssg-sshd_set_idle_timeout_action:testaction:1 Set SSH Client Alive Count Max ocil:ssg-sshd_set_keepalive_action:testaction:1 Use Only FIPS 140-2 Validated Ciphers ocil:ssg-sshd_use_approved_ciphers_ordered_stig_action:testaction:1 Use Only FIPS 140-2 Validated Key Exchange Algorithms ocil:ssg-sshd_use_approved_kex_ordered_stig_action:testaction:1 Use Only FIPS 140-2 Validated MACs ocil:ssg-sshd_use_approved_macs_ordered_stig_action:testaction:1 Prevent remote hosts from connecting to the proxy display ocil:ssg-sshd_x11_use_localhost_action:testaction:1 Certificate trust path in SSSD ocil:ssg-sssd_certification_path_trust_anchor_action:testaction:1 Configure PAM in SSSD Services ocil:ssg-sssd_enable_pam_services_action:testaction:1 Enable Smartcards in SSSD ocil:ssg-sssd_enable_smartcards_action:testaction:1 Configure SSSD to Expire Offline Credentials ocil:ssg-sssd_offline_cred_expiration_action:testaction:1 Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate ocil:ssg-sudo_remove_no_authenticate_action:testaction:1 Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD ocil:ssg-sudo_remove_nopasswd_action:testaction:1 The operating system must restrict privilege elevation to authorized personnel ocil:ssg-sudo_restrict_privilege_elevation_to_authorized_action:testaction:1 Restrict Access to Kernel Message Buffer ocil:ssg-sysctl_kernel_dmesg_restrict_action:testaction:1 Enable Randomized Layout of Virtual Address Space ocil:ssg-sysctl_kernel_randomize_va_space_action:testaction:1 Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces ocil:ssg-sysctl_net_ipv4_tcp_syncookies_action:testaction:1 Only Allow Authorized Network Services in ufw ocil:ssg-ufw_only_required_services_action:testaction:1 ufw Must rate-limit network interfaces ocil:ssg-ufw_rate_limit_action:testaction:1 Verify that 'use_mappers' is set to 'pwent' in PAM ocil:ssg-verify_use_mappers_action:testaction:1 Check that vlock is installed to allow session locking ocil:ssg-vlock_installed_action:testaction:1 Deactivate Wireless Network Interfaces ocil:ssg-wireless_disable_interfaces_action:testaction:1 PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL To verify the INACTIVE setting, run the following command: $ grep "INACTIVE" /etc/default/useradd The output should indicate the INACTIVE configuration option is set to an appropriate integer as shown in the example below: $ grep "INACTIVE" /etc/default/useradd INACTIVE= Is it the case that the value of INACTIVE is greater than the expected value or is -1? Verify that temporary accounts have been provisioned with an expiration date of 72 hours. For every temporary account, run the following command to obtain its account aging and expiration information: $ sudo chage -l temporary_account_name Verify each of these accounts has an expiration date set within 72 hours or as documented. Is it the case that any temporary accounts have no expiration date set or do not expire within 72 hours? Verify Claroty CTD 5.x limits the number of concurrent sessions to "" for all accounts and/or account types with the following command: $ grep -r -s maxlogins /etc/security/limits.conf /etc/security/limits.d/*.conf /etc/security/limits.conf:* hard maxlogins 10 This can be set as a global domain (with the * wildcard) but may be set differently for multiple domains. Is it the case that the "maxlogins" item is missing, commented out, or the value is set greater than "<sub idref="var_accounts_max_concurrent_login_sessions" />" and is not documented with the Information System Security Officer (ISSO) as an operational requirement for all domains that have the "maxlogins" item assigned'? Verify that Claroty CTD 5.x enforces a -day maximum password lifetime for new user accounts by running the following command: $ grep -i pass_max_days /etc/login.defs PASS_MAX_DAYS Is it the case that the "PASS_MAX_DAYS" parameter value is greater than "<sub idref="var_accounts_maximum_age_login_defs" />", or commented out? Verify Claroty CTD 5.x enforces 24 hours/one day as the minimum password lifetime for new user accounts. Check for the value of "PASS_MIN_DAYS" in "/etc/login.defs" with the following command: $ grep -i pass_min_days /etc/login.defs PASS_MIN_DAYS Is it the case that the "PASS_MIN_DAYS" parameter value is not "<sub idref="var_accounts_minimum_age_login_defs" />" or greater, or is commented out? Verify that Claroty CTD 5.x enforces password complexity by requiring that at least one numeric character be used. Check the value for "dcredit" with the following command: $ sudo grep dcredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf /etc/security/pwquality.conf:dcredit = Is it the case that the value of "dcredit" is a positive number or is commented out? Verify Claroty CTD 5.x prevents the use of dictionary words for passwords with the following command: $ sudo grep dictcheck /etc/security/pwquality.conf /etc/pwquality.conf.d/*.conf /etc/security/pwquality.conf:dictcheck=1 Is it the case that "dictcheck" does not have a value other than "0", or is commented out? Verify the value of the "difok" option in "/etc/security/pwquality.conf" with the following command: $ sudo grep difok /etc/security/pwquality.conf difok = Is it the case that the value of "difok" is set to less than "<sub idref="var_password_pam_difok" />", or is commented out? To verify that enforcing is correctly applied, run the following command: $ grep -i enforcing /etc/security/pwquality.conf The output should return enforcing = 1 uncommented. Is it the case that enforcing is not uncommented or configured correctly? Verify that Claroty CTD 5.x enforces password complexity by requiring that at least one lower-case character. Check the value for "lcredit" with the following command: $ sudo grep lcredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf /etc/security/pwquality.conf:lcredit = -1 Is it the case that the value of "lcredit" is a positive number or is commented out? Verify that Claroty CTD 5.x enforces a minimum -character password length with the following command: $ grep minlen /etc/security/pwquality.conf minlen = Is it the case that the command does not return a "minlen" value of "<sub idref="var_password_pam_minlen" />" or greater, does not return a line, or the line is commented out? Verify that Claroty CTD 5.x enforces password complexity by requiring that at least one special character with the following command: $ sudo grep ocredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf ocredit = Is it the case that value of "ocredit" is a positive number or is commented out? Verify Claroty CTD 5.x is configured to limit the "pwquality" retry option to . Check for the use of the "pwquality" retry option in the PAM files with the following command: $ grep pam_pwquality /etc/pam.d/system-auth password requisite pam_pwquality.so retry= Is it the case that the value of "retry" is set to "0" or greater than "<sub idref="var_password_pam_retry" />", or is missing? Verify that Claroty CTD 5.x enforces password complexity by requiring that at least one upper-case character. Check the value for "ucredit" with the following command: $ sudo grep ucredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf ucredit = -1 Is it the case that the value of "ucredit" is a positive number or is commented out? To verify the number of rounds for the password hashing algorithm is configured, run the following command: $ sudo grep rounds /etc/pam.d/password-auth The output should show the following match: password sufficient pam_unix.so sha512 rounds= Is it the case that rounds is not set to <sub idref="var_password_pam_unix_rounds" /> or is commented out? Verify that the Claroty CTD 5.x operating system enforces a minimum delay between logon prompts following a failed logon attempt. # grep pam_faildelay /etc/pam.d/common-auth auth required pam_faildelay.so delay= If the value of delay is not set to or greater, "delay" is commented out, "delay" is missing, or the "pam_faildelay" line is missing completely, this is a finding. Is it the case that the value of delay is not set properly or the line is commented or missing? Verify the "/etc/security/faillock.conf" file is configured to log user name information when unsuccessful logon attempts occur: $ sudo grep audit /etc/security/faillock.conf audit Is it the case that the "audit" option is not set, is missing or commented out? Verify Claroty CTD 5.x is configured to lock an account after unsuccessful logon attempts with the command: $ grep 'deny =' /etc/security/faillock.conf deny = . Is it the case that the "deny" option is not set to "<sub idref="var_accounts_passwords_pam_faillock_deny" />" or less (but not "0"), is missing or commented out? To ensure the failed password attempt policy is configured correctly, run the following command: $ grep fail_interval /etc/security/faillock.conf The output should show fail_interval = <interval-in-seconds> where interval-in-seconds is or greater. Is it the case that the "fail_interval" option is not set to "<sub idref="var_accounts_passwords_pam_faillock_fail_interval" />" or less (but not "0"), the line is commented out, or the line is missing? To ensure that the system prevents messages from being shown when three unsuccessful logon attempts occur, run the following command: $ grep silent /etc/security/faillock.conf The output should show silent. Is it the case that the system shows messages when three unsuccessful logon attempts occur? Verify Claroty CTD 5.x is configured to lock an account until released by an administrator after unsuccessful logon attempts with the command: $ grep 'unlock_time =' /etc/security/faillock.conf unlock_time = Is it the case that the "unlock_time" option is not set to "<sub idref="var_accounts_passwords_pam_faillock_unlock_time" />", the line is missing, or commented out? Run the following command to ensure the TMOUT value is configured for all users on the system: $ sudo grep TMOUT /etc/profile /etc/profile.d/*.sh The output should return the following: TMOUT= Is it the case that the TMOUT value is not configured, is set to 0, or is not less than or equal to the expected setting? Verify Claroty CTD 5.x defines default permissions for all authenticated users in such a way that the user can only read and modify their own files with the following command: # grep -i umask /etc/login.defs UMASK Is it the case that the value for the "UMASK" parameter is not "<sub idref="var_accounts_user_umask" />", or the "UMASK" parameter is missing or is commented out? To find the location of the AIDE database file, run the following command: $ sudo ls -l DBDIR/database_file_name Is it the case that there is no database file? Check that AIDE is properly configured to protect the integrity of the audit tools by running the following command: # sudo cat /etc/aide/aide.conf | grep /usr/sbin/au /usr/sbin/auditctl p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/auditd p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/ausearch p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/aureport p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/autrace p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/audispd p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/augenrules p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 If AIDE is configured properly to protect the integrity of the audit tools, all lines listed above will be returned from the command. If one or more lines are missing, this is a finding. Is it the case that integrity checks of the audit tools are missing or incomplete? Verify that Advanced Intrusion Detection Environment (AIDE) notifies the System Administrator when anomalies in the operation of any security functions are discovered with the following command: # grep SILENTREPORTS /etc/default/aide SILENTREPORTS=no If SILENTREPORTS is commented out, this is a finding. If SILENTREPORTS is set to "yes", this is a finding. If SILENTREPORTS is not set to "no", this is a finding. Is it the case that silentreports is enabled in aide default configuration, or is missing? Verify the operating system routinely checks the baseline configuration for unauthorized changes. To determine that periodic AIDE execution has been scheduled, run the following command: $ grep aide /etc/crontab The output should return something similar to the following: 05 4 * * * root /usr/bin/aide --check NOTE: The usage of special cron times, such as @daily or @weekly, is acceptable. Is it the case that AIDE is not configured to scan periodically? Run the following command to determine the current status of the apparmor service: $ sudo systemctl is-active apparmor If the service is running, it should return the following: active Is it the case that it is not? To determine if the system is configured to audit calls to the chmod system call, run the following command: $ sudo grep "chmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the chown system call, run the following command: $ sudo grep "chown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fchmod system call, run the following command: $ sudo grep "fchmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fchmodat system call, run the following command: $ sudo grep "fchmodat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fchown system call, run the following command: $ sudo grep "fchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fchownat system call, run the following command: $ sudo grep "fchownat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fremovexattr system call, run the following command: $ sudo grep "fremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fsetxattr system call, run the following command: $ sudo grep "fsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the lchown system call, run the following command: $ sudo grep "lchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the lremovexattr system call, run the following command: $ sudo grep "lremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the lsetxattr system call, run the following command: $ sudo grep "lsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the removexattr system call, run the following command: $ sudo grep "removexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the setxattr system call, run the following command: $ sudo grep "setxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/cron.d/" with the following command: $ sudo auditctl -l | grep /etc/cron.d/ -w /etc/cron.d/ -p wa -k cronjobs Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "chacl" command with the following command: $ sudo auditctl -l | grep chacl -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "chcon" command with the following command: $ sudo auditctl -l | grep chcon -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "setfacl" command with the following command: $ sudo auditctl -l | grep setfacl -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod Is it the case that the command does not return a line, or the line is commented out? To determine if the system is configured to audit calls to the rename system call, run the following command: $ sudo grep "rename" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the renameat system call, run the following command: $ sudo grep "renameat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the rmdir system call, run the following command: $ sudo grep "rmdir" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the unlink system call, run the following command: $ sudo grep "unlink" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the unlinkat system call, run the following command: $ sudo grep "unlinkat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the delete_module system call, run the following command: $ sudo grep "delete_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the finit_module system call, run the following command: $ sudo grep "finit_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the init_module system call, run the following command: $ sudo grep "init_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/faillog" with the following command: $ sudo auditctl -l | grep /var/log/faillog -w /var/log/faillog -p wa -k logins Is it the case that there is no output? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/lastlog" with the following command: $ sudo auditctl -l | grep /var/log/lastlog -w /var/log/lastlog -p wa -k logins Is it the case that the command does not return a line, or the line is commented out? To verify that execution of the command is being audited, run the following command: sudo auditctl -l | grep apparmor_parser The output should return something similar to: -a always,exit -F path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged Is it the case that ? Verify that Claroty CTD 5.x is configured to audit the execution of the "chage" command with the following command: $ sudo auditctl -l | grep chage -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chage Is it the case that the command does not return a line, or the line is commented out? To verify that auditing of privileged command use is configured, run the following command: $ sudo grep chfn /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "chsh" command with the following command: $ sudo auditctl -l | grep chsh -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chsh Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "crontab" command with the following command: $ sudo auditctl -l | grep crontab -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -k privileged-crontab Is it the case that the command does not return a line, or the line is commented out? To verify that auditing of privileged command use is configured, run the following command: $ sudo auditctl -l | grep fdisk -w /sbin/fdisk -p x -k fdisk If the command does not return a line, or the line is commented out, this is a finding. Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "gpasswd" command with the following command: $ sudo auditctl -l | grep gpasswd -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-gpasswd Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "kmod" command with the following command: $ sudo auditctl -l | grep kmod -a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -k privileged-kmod Is it the case that the command does not return a line, or the line is commented out? To verify that auditing of privileged command use is configured, run the following command: sudo auditctl -l | grep -w '/sbin/modprobe' -w /sbin/modprobe -p x -k modules It should return a relevant line in the audit rules. Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "mount" command with the following command: $ sudo auditctl -l | grep mount -a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-mount Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "newgrp" command with the following command: $ sudo auditctl -l | grep newgrp -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -k privileged-newgrp Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "pam_timestamp_check" command with the following command: $ sudo auditctl -l | grep pam_timestamp_check -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -k privileged-pam_timestamp_check Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "passwd" command with the following command: $ sudo auditctl -l | grep passwd -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-passwd Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "ssh-agent" command with the following command: $ sudo auditctl -l | grep ssh-agent -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "ssh-keysign" command with the following command: $ sudo auditctl -l | grep ssh-keysign -a always,exit -F path=/usr/libexec/openssh/ssh-keysignssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-keysign Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "su" command with the following command: $ sudo auditctl -l | grep su -a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k privileged-su Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "sudo" command with the following command: $ sudo auditctl -l | grep sudo -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -k privileged-sudo Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "sudoedit" command with the following command: $ sudo auditctl -l | grep sudoedit -a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -k privileged-sudoedit Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "umount" command with the following command: $ sudo auditctl -l | grep umount -a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-umount Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "unix_update" command with the following command: $ sudo auditctl -l | grep unix_update -a always,exit -F path=/usr/bin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix_update Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "usermod" command with the following command: $ sudo auditctl -l | grep usermod -a always,exit -F path=/usr/bin/usermod -F perm=x -F auid>=1000 -F auid!=unset -k privileged-usermod Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/btmp" with the following command: $ sudo auditctl -l | grep /var/log/btmp -w /var/log/btmp -p wa -k session Is it the case that Audit rule is not present? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/run/utmp" with the following command: $ sudo auditctl -l | grep /var/run/utmp -w /var/run/utmp -p wa -k session Is it the case that Audit rule is not present? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/wtmp" with the following command: $ sudo auditctl -l | grep /var/log/wtmp -w /var/log/wtmp -p wa -k session Is it the case that Audit rule is not present? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/sudoers" with the following command: $ sudo auditctl -l | grep /etc/sudoers -w /etc/sudoers -p wa -k actions Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/sudoers.d/" with the following command: $ sudo auditctl -l | grep /etc/sudoers.d/ -w /etc/sudoers.d/ -p wa -k actions Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x audits the execution of privileged functions. Check if Claroty CTD 5.x is configured to audit the execution of the "execve" system call using the following command: $ sudo grep execve /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k setuid -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k setgid -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid Is it the case that the command does not return all lines, or the lines are commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the creat system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r creat /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep creat /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the ftruncate system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r ftruncate /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep ftruncate /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the open system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r open /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep open /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the open_by_handle_at system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r open_by_handle_at /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep open_by_handle_at /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the openat system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r openat /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep openat /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the truncate system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r truncate /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep truncate /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/group" with the following command: $ sudo auditctl -l | grep /etc/group -w /etc/group -p wa -k audit_rules_usergroup_modification Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/gshadow" with the following command: $ sudo auditctl -l | grep /etc/gshadow -w /etc/gshadow -p wa -k audit_rules_usergroup_modification Is it the case that the system is not configured to audit account changes? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/security/opasswd" with the following command: $ sudo auditctl -l | grep /etc/security/opasswd -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/passwd" with the following command: $ sudo auditctl -l | grep /etc/passwd -w /etc/passwd -p wa -k audit_rules_usergroup_modification Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/shadow" with the following command: $ sudo auditctl -l | grep /etc/shadow -w /etc/shadow -p wa -k audit_rules_usergroup_modification Is it the case that command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/journal" with the following command: $ sudo auditctl -l | grep /var/log/journal -w /var/log/journal -p wa -k systemd_journal Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/spool/cron" with the following command: $ sudo auditctl -l | grep /var/spool/cron -w /var/spool/cron -p wa -k cronjobs Is it the case that command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/sudo.log" with the following command: $ sudo auditctl -l | grep /var/log/sudo.log -w /var/log/sudo.log -p wa -k maintenance Is it the case that Audit rule is not present? To verify the audispd plugin off-loads audit records onto a different system or media from the system being audited, run the following command: $ sudo grep -i remote_server /etc/audit/audisp-remote.conf The output should return something similar to remote_server = Is it the case that audispd is not sending logs to a remote system? To verify whether audispd plugin off-loads audit records onto a different system or media from the system being audited, run the following command: $ sudo grep -i remote_server /etc/audit/audisp-remote.conf The output should return something similar to where REMOTE_SYSTEM is an IP address or hostname: remote_server = REMOTE_SYSTEM Determine which partition the audit records are being written to with the following command: $ sudo grep log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Check the size of the partition that audit records are written to with the following command and verify whether it is sufficiently large: $ sudo df -h /var/log/audit/ /dev/sda2 24G 10.4G 13.6G 43% /var/log/audit Is it the case that audispd is not sending logs to a remote system and the local partition has inadequate space? Verify Claroty CTD 5.x takes the appropriate action when the audit storage volume is full. Check that Claroty CTD 5.x takes the appropriate action when the audit storage volume is full with the following command: $ sudo grep disk_full_action /etc/audit/auditd.conf disk_full_action = If the value of the "disk_full_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, ask the system administrator to indicate how the system takes appropriate action when an audit storage volume is full. Is it the case that there is no evidence of appropriate action? Verify that Claroty CTD 5.x is configured to notify the SA and/or ISSO (at a minimum) in the event of an audit processing failure with the following command: $ sudo grep action_mail_acct /etc/audit/auditd.conf action_mail_acct = Is it the case that the value of the "action_mail_acct" keyword is not set to "<sub idref="var_auditd_action_mail_acct" />" and/or other accounts for security personnel, the "action_mail_acct" keyword is missing, or the returned line is commented out, ask the system administrator to indicate how they and the ISSO are notified of an audit process failure. If there is no evidence of the proper personnel being notified of an audit processing failure? Verify Claroty CTD 5.x notifies the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity with the following command: $ sudo grep -w space_left_action /etc/audit/auditd.conf space_left_action = If the value of the "space_left_action" is not set to "", or if the line is commented out, ask the System Administrator to indicate how the system is providing real-time alerts to the SA and ISSO. Is it the case that there is no evidence that real-time alerts are configured on the system? Verify Claroty CTD 5.x takes action when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity with the following command: $ sudo grep -w space_left /etc/audit/auditd.conf space_left = % Is it the case that the value of the "space_left" keyword is not set to <sub idref="var_auditd_space_left_percentage" />% of the storage volume allocated to audit logs, or if the line is commented out, ask the System Administrator to indicate how the system is providing real-time alerts to the SA and ISSO. If the "space_left" value is not configured to the correct value? Verify there is a script that offloads audit data and that script runs weekly. Check if there is a script in the "/etc/cron.weekly" directory that offloads audit data: # sudo ls /etc/cron.weekly audit-offload Check if the script inside the file does offloading of audit logs to external media. If the script file does not exist or does not offload audit logs, this is a finding. Is it the case that Cron job has not been configured to offload audit logs to external media? To check if the system login banner is compliant, run the following command: $ cat /etc/issue.net Is it the case that it does not display the required banner? Verify the NX (no-execution) bit flag is set on the system. Check that the no-execution bit flag is set with the following commands: $ sudo dmesg | grep NX [ 0.000000] NX (Execute Disable) protection: active If "dmesg" does not show "NX (Execute Disable) protection" active, check the cpuinfo settings with the following command: $ sudo grep flags /proc/cpuinfo flags : fpu vme de pse tsc ms nx rdtscp lm constant_ts The output should contain the "nx" flag. Is it the case that NX is disabled? Verify Claroty CTD 5.x is securely comparing internal information system clocks at a regular interval with an NTP server with the following command: $ sudo grep maxpoll /etc/ntp.conf /etc/chrony/chrony.conf /etc/chrony/conf.d/ server [ntp.server.name] iburst maxpoll . Is it the case that "maxpoll" has not been set to the value of "<sub idref="var_time_service_set_maxpoll" />", is commented out, or is missing? Verify the operating system synchronizes internal system clocks to the authoritative time source when the time difference is greater than one second. Check the value of "makestep" by running the following command: $ sudo grep makestep /etc/chrony/chrony.conf makestep 1 -1 If it is not set to the above value, edit the /etc/chrony/chrony.conf file and add: makestep 1 -1 Restart the chrony service: $ sudo systemctl restart chrony.service Is it the case that ? Verify Claroty CTD 5.x removes all software components after updated versions have been installed. $ grep clean_requirements_on_remove /etc/apt/apt.conf clean_requirements_on_remove=1 Is it the case that '"clean_requirements_on_remove" is not set to "1"'? Review Claroty CTD authentication configuration. Verify the platform accepts the DoD CAC or another approved PKI credential for identity management and personal authentication where required by the deployment. If CAC or PKI authentication is required but not supported or not configured, this is a finding. Is it the case that Claroty CTD does not accept approved CAC or PKI credentials for authentication where required? Review Claroty CTD alerting and notification settings for compromise-related events. Verify the ISSO, ISSM, and other designated personnel are notified when events indicate a compromise or potential compromise. If required compromise-event alerts are not configured, this is a finding. Is it the case that Claroty CTD does not alert designated personnel when compromise-related events are detected? Review Claroty CTD audit storage and retention settings. Verify the platform allocates and retains audit records for the length of time required by the organization. If audit record storage retention is not configured appropriately, this is a finding. Is it the case that Claroty CTD audit record storage retention is not configured as required? Review the configured Claroty CTD local accounts and compare them to the accounts documented in the System Security Plan (SSP). Verify only authorized local accounts exist on the platform. If unauthorized or undocumented local accounts are present, this is a finding. Is it the case that Claroty CTD contains undocumented or unauthorized local accounts? Review Claroty CTD time synchronization settings and the configured NTP trust model. Verify the platform authenticates to the NTP server using a bidirectional, cryptographically based method that uses a FIPS-validated AES cipher block algorithm where required. If NTP authentication is not configured as required, this is a finding. Is it the case that Claroty CTD does not use bidirectional cryptographic authentication with its NTP server? Log in to the Claroty CTD 4 administrative console. Open the administrator menu and review the Change Password function. Verify the default administrative password has been changed to an organization-approved value. If the default administrative password is still in use, this is a finding. Is it the case that the default Claroty CTD 4 administrative password has not been changed? Review Claroty CTD local password policy settings. Verify the platform enforces the organization-approved password policy for local accounts, including complexity, length, and related controls where required. If local password policies are not configured appropriately, this is a finding. Is it the case that Claroty CTD local password policies are not configured as required? Determine whether Claroty CTD is deployed as a virtual machine. If so, review the virtualization and storage configuration and verify disk encryption is enabled for the CTD virtual disks. If Claroty CTD is deployed as a VM without disk encryption, this is a finding. Is it the case that disk encryption is not enabled for the Claroty CTD virtual machine? Access the Claroty CTD login interface and any local or remote system access entry points. Verify the Standard Mandatory DOD Notice and Consent Banner is displayed before access is granted. If the required banner is not displayed, this is a finding. Is it the case that Claroty CTD does not display the Standard Mandatory DOD Notice and Consent Banner before system access? Open the Claroty CTD web login page. Verify the Standard Mandatory DOD Notice and Consent Banner is displayed before the user is granted access to the application. If the required banner is not displayed, this is a finding. Is it the case that the Claroty CTD web application does not display the Standard Mandatory DOD Notice and Consent Banner before login? Review the Claroty CTD administrative session timeout configuration. Verify the platform is configured to terminate or lock idle sessions after no more than 10 minutes of inactivity. If the timeout exceeds 10 minutes or is not configured, this is a finding. Is it the case that Claroty CTD does not enforce a 10-minute idle session timeout? Review the Claroty CTD audit and notification service status. Verify audit collection, audit storage, and platform notification services are enabled and operational. If required notification or audit services are not operational, this is a finding. Is it the case that Claroty CTD notification or audit services are not operational? Review Claroty CTD alerting and notification settings for local account activity. Verify system administrators and the ISSO are notified of local account activity in accordance with site policy. If required notifications are not configured, this is a finding. Is it the case that Claroty CTD does not notify administrators and the ISSO of local account activity? Log in to the Claroty CTD administrative console. Review the Upload Certificate configuration under OS Configuration > Manage. Verify the certificate chain used for protected sessions is issued by DoD PKI-established certificate authorities where required by the deployment. If unapproved certificate authorities are trusted for protected sessions, this is a finding. Is it the case that Claroty CTD trusts certificate authorities that are not approved for protected sessions? Review the list of Claroty CTD accounts with full administrative privileges. Verify each individual with full administrative rights is appointed by the information system security manager (ISSM). If unapproved users have full administrative rights, this is a finding. Is it the case that individuals without ISSM appointment have full administrative rights in Claroty CTD? Review Claroty CTD administrative access methods and privilege assignments. Verify administrative shell access is restricted to authorized personnel and unavailable to users who do not require it. If unnecessary shell access or excessive privilege exists, this is a finding. Is it the case that Claroty CTD permits unnecessary administrative shell access or excessive privileges? Review Claroty CTD audit backup and export settings. Verify backup audit records are sent or otherwise preserved in accordance with organizational requirements. If backup audit records are not configured, this is a finding. Is it the case that Claroty CTD is not configured to send or preserve backup audit records? Review Claroty CTD syslog forwarding settings. Verify any configured syslog client uses TCP connections for remote log transmission. If syslog forwarding uses a noncompliant transport, this is a finding. Is it the case that the Claroty CTD syslog client is not configured to use TCP connections? Log in to the Claroty CTD administrative console. Open the administrator menu and review the displayed platform status. Verify the platform shows Fips Mode: Enabled and that deployed cryptographic protections rely on FIPS-validated algorithms. If FIPS mode is not enabled or approved cryptographic protections are not in use, this is a finding. Is it the case that Claroty CTD is not using FIPS-validated encryption and hashing mechanisms for stored data? Review Claroty CTD authentication and authorization settings. Verify an approved identity provider is configured and used for authentication and authorization processes. If the system relies only on unmanaged local authentication where an IDP is required, this is a finding. Is it the case that Claroty CTD is not configured to use an approved identity provider? To ensure a login warning banner is enabled, run the following: $ grep banner-message-enable /etc/dconf/db/gdm.d/* If properly configured, the output should be true. To ensure a login warning banner is locked and cannot be changed by a user, run the following: $ grep banner-message-enable /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/banner-message-enable. Is it the case that it is not? To ensure the system is configured to ignore the Ctrl-Alt-Del sequence, run the following command: $ gsettings get org.gnome.settings-daemon.plugins.media-keys logout $ grep logout /etc/dconf/db/local.d/locks/* If properly configured, the output should be /org/gnome/settings-daemon/plugins/media-keys/logout Is it the case that GNOME3 is configured to reboot when Ctrl-Alt-Del is pressed? To ensure the login warning banner text is properly set, run the following: $ grep banner-message-text /etc/dconf/db/gdm.d/* If properly configured, the proper banner text will appear. To ensure the login warning banner text is locked and cannot be changed by a user, run the following: $ grep banner-message-text /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/banner-message-text. Is it the case that it does not? To check the current idle time-out value, run the following command: $ gsettings get org.gnome.desktop.session idle-delay If properly configured, the output should be 'uint32 '. To ensure that users cannot change the screensaver inactivity timeout setting, run the following: $ grep idle-delay /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/desktop/session/idle-delay Is it the case that idle-delay is set to 0 or a value greater than <sub idref="inactivity_timeout_value" />? To check that the screen locks immediately when activated, run the following command: $ gsettings get org.gnome.desktop.screensaver lock-delay If properly configured, the output should be 'uint32 '. Is it the case that the screensaver lock delay is missing, or is set to a value greater than <sub idref="var_screensaver_lock_delay" />? To check the status of the idle screen lock activation, run the following command: $ gsettings get org.gnome.desktop.screensaver lock-enabled If properly configured, the output should be true. To ensure that users cannot change how long until the screensaver locks, run the following: $ grep lock-enabled /etc/dconf/db/gdm.d/locks/* If properly configured, the output for lock-enabled should be /org/gnome/desktop/screensaver/lock-enabled Is it the case that screensaver locking is not enabled and/or has not been set or configured correctly? Verify the system-wide shared library directories are group-owned by "root" with the following command: $ sudo find /lib /lib64 /usr/lib /usr/lib64 ! -group root -type d -exec stat -c "%n %G" '{}' \; If any system-wide shared library directory is returned and is not group-owned by a required system account, this is a finding. Is it the case that any system-wide shared library directory is returned and is not group-owned by a required system account? System commands are stored in the following directories: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin For each of these directories, run the following command to find files not owned by root group: $ sudo find -L $DIR ! -group root -type d \; Is it the case that any of these directories are not owned by root group? System executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/local/bin /usr/local/sbin /usr/sbin For each of these directories, run the following command to find files not owned by root: $ sudo find -L DIR/ ! -user root -type d -exec chown root {} \; Is it the case that any system executables directories are found to not be owned by root? Verify the system-wide shared library directories are owned by "root" with the following command: $ sudo find /lib /lib64 /usr/lib /usr/lib64 ! -user root -type d -exec stat -c "%n %U" '{}' \; Is it the case that any system-wide shared library directory is not owned by root? System executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin To find system executables directories that are group-writable or world-writable, run the following command for each directory DIR which contains system executables: $ sudo find -L DIR -perm /022 -type d Is it the case that any of these files are group-writable or world-writable? To find world-writable directories that lack the sticky bit, run the following command: $ sudo find / -type d \( -perm -0002 -a ! -perm -1000 \) -print 2>/dev/null fixtext: |- Configure all world-writable directories to have the sticky bit set to prevent unauthorized and unintended information transferred via shared system resources. Set the sticky bit on all world-writable directories using the command, replace "[World-Writable Directory]" with any directory path missing the sticky bit: $ chmod a+t [World-Writable Directory] srg_requirement: A sticky bit must be set on all Claroty CTD 5.x public directories to prevent unauthorized and unintended information transferred via shared system resources. Is it the case that any world-writable directories are missing the sticky bit? Verify the audit log directories have a correct mode or less permissive mode. Find the location of the audit logs: $ sudo grep "^log_file" /etc/audit/auditd.conf Find the group that owns audit logs: $ sudo grep "^log_group" /etc/audit/auditd.conf Run the following command to check the mode of the system audit logs: $ sudo stat -c "%a %n" [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit". If the log_group is "root" or is not set, the correct permissions are 0700, otherwise they are 0750. Is it the case that audit logs have a more permissive mode? To ensure the system is configured to mask the Ctrl-Alt-Del sequence, Check that the ctrl-alt-del.target is masked and not active with the following command: sudo systemctl status ctrl-alt-del.target The output should indicate that the target is masked and not active. It might resemble following output: ctrl-alt-del.target Loaded: masked (/dev/null; bad) Active: inactive (dead) Is it the case that the system is configured to reboot when Ctrl-Alt-Del is pressed? Check the system partitions to determine if they are encrypted with the following command: blkid Output will be similar to: /dev/sda1: UUID=" ab12c3de-4f56-789a-8f33-3850cc8ce3a2 " TYPE="crypto_LUKS" /dev/sda2: UUID=" bc98d7ef-6g54-321h-1d24-9870de2ge1a2 " TYPE="crypto_LUKS" The boot partition and pseudo-file systems, such as /proc, /sys, and tmpfs, are not required to use disk encryption and are not a finding. Is it the case that partitions do not have a type of crypto_LUKS? To verify that the system real-time clock is set to UTC or GMT, run the following command: # timedatectl status | grep -i timezone Timezone: UTC (UTC, +0000) If "Timezone" is not set to UTC, this is a finding. Fix Text: Configure the SUSE operating system is configured to use UTC. To configure the system time zone to use UTC or GMT, run the following command, replacing [ZONE] with "UTC" or "GMT". # sudo timedatectl set-timezone [ZONE] Is it the case that the system real-time clock is not configured to use UTC as its time base? Configure the sudo group with only members requiring access to security functions. To remove a user from the sudo group, run: $ sudo gpasswd -d username sudo Is it the case that sudo group contains users not needing access to security functions? To check the group ownership of /var/log/journal/.*/system.journal, run the command: $ ls -lL /var/log/journal/.*/system.journal If properly configured, the output should indicate the following group-owner: systemd-journal Is it the case that /var/log/journal/.*/system.journal does not have a group owner of systemd-journal ? To check the group ownership of /var/log, run the command: $ ls -lL /var/log If properly configured, the output should indicate the following group-owner: root Is it the case that /var/log does not have a group owner of root ? To check the group ownership of /var/log/syslog, run the command: $ ls -lL /var/log/syslog If properly configured, the output should indicate the following group-owner: adm Is it the case that /var/log/syslog does not have a group owner of adm ? To properly set the group owner of /etc/audit/, run the command: $ sudo chgrp root /etc/audit/ To properly set the group owner of /etc/audit/rules.d/, run the command: $ sudo chgrp root /etc/audit/rules.d/ Is it the case that ? Verify the system commands contained in the following directories are group-owned by "root", or a required system account, with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -exec ls -l {} \; Is it the case that any system commands are returned and is not group-owned by a required system account? To check the ownership of /var/log/journal/.*/system.journal, run the command: $ ls -lL /var/log/journal/.*/system.journal If properly configured, the output should indicate the following owner: root Is it the case that /var/log/journal/.*/system.journal does not have an owner of root? To check the ownership of /var/log, run the command: $ ls -lL /var/log If properly configured, the output should indicate the following owner: root Is it the case that /var/log does not have an owner of root? To check the ownership of /var/log/syslog, run the command: $ ls -lL /var/log/syslog If properly configured, the output should indicate the following owner: syslog Is it the case that /var/log/syslog does not have an owner of syslog? Verify it by running the following command: $ stat -c "%n %U" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/audispd root /sbin/augenrules root If the command does not return all the above lines, the missing ones need to be added. Run the following command to correct the permissions of the missing entries: $ sudo chown root [audit_tool] Replace "[audit_tool]" with each audit tool not owned by root. Is it the case that ? To properly set the owner of /etc/audit/, run the command: $ sudo chown root /etc/audit/ To properly set the owner of /etc/audit/rules.d/, run the command: $ sudo chown root /etc/audit/rules.d/ Is it the case that ? Verify the system commands contained in the following directories are owned by "root" with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/libexec /usr/local/bin /usr/local/sbin ! -user root -exec ls -l {} \; Is it the case that any system commands are found to not be owned by root? Verify the system-wide shared library files are owned by "root" with the following command: $ sudo find -L /lib /lib64 /usr/lib /usr/lib64 ! -user root -exec ls -l {} \; Is it the case that any system wide shared library file is not owned by root? Verify the audit logs are owned by "root". First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the location of the audit log file, determine if the audit log is owned by "root" using the following command: $ sudo stat -c "%n %U" /var/log/audit/audit.log Audit logs must be owned by user root. If the log_file isn't defined in /etc/audit/auditd.conf, check all files in /var/log/audit/ directory instead. Is it the case that the audit log is not owned by root? Verify it by running the following command: $ stat -c "%n %a" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl 755 /sbin/aureport 755 /sbin/ausearch 755 /sbin/autrace 755 /sbin/auditd 755 /sbin/audispd 755 /sbin/augenrules 755 If the command does not return all the above lines, the missing ones need to be added. Run the following command to correct the permissions of the missing entries: $ sudo chmod 0755 [audit_tool] Replace "[audit_tool]" with the audit tool that does not have the correct permissions. Is it the case that ? Verify the system commands contained in the following directories have mode "755" or less permissive with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/libexec /usr/local/bin /usr/local/sbin -perm /022 -exec ls -l {} \; Is it the case that any system commands are found to be group-writable or world-writable? To check the permissions of /etc/audit/auditd.conf, run the command: $ ls -l /etc/audit/auditd.conf If properly configured, the output should indicate the following permissions: -rw-r----- Is it the case that /etc/audit/auditd.conf does not have unix mode -rw-r-----? To check the permissions of /etc/audit/audit.rules, run the command: $ ls -l /etc/audit/audit.rules If properly configured, the output should indicate the following permissions: -rw-r----- Is it the case that /etc/audit/audit.rules does not have unix mode -rw-r-----? To check the permissions of /etc/audit/rules.d/*.rules, run the command: $ ls -l /etc/audit/rules.d/*.rules If properly configured, the output should indicate the following permissions: -rw------- Is it the case that /etc/audit/rules.d/*.rules does not have unix mode -rw-------? Verify the system-wide shared library files contained in the following directories have mode "755" or less permissive with the following command: $ sudo find -L /lib /lib64 /usr/lib /usr/lib64 -perm /022 -type f -exec ls -l {} \; Is it the case that any system-wide shared library file is found to be group-writable or world-writable? To check the permissions of /var/log/journal/.*/system.journal, run the command: $ ls -l /var/log/journal/.*/system.journal If properly configured, the output should indicate the following permissions: -rw-r----- Is it the case that /var/log/journal/.*/system.journal does not have unix mode -rw-r-----? To check the permissions of /var/log, run the command: $ ls -l /var/log If properly configured, the output should indicate the following permissions: drwxr-xr-x Is it the case that /var/log does not have unix mode drwxr-xr-x? To check the permissions of /var/log/syslog, run the command: $ ls -l /var/log/syslog If properly configured, the output should indicate the following permissions: -rw-r----- Is it the case that /var/log/syslog does not have unix mode -rw-r-----? Inspect the form of default GRUB 2 command line for the Linux operating system in grubenv that can be found either in /boot/grub in case of legacy BIOS systems, or in /boot/efi/EFI/ubuntu in case of UEFI systems. If they include audit=1, then the parameter is configured at boot time. $ sudo grep 'kernelopts.*audit=1.*' GRUBENV_FILE_LOCATION Fill in GRUBENV_FILE_LOCATION based on information above. Is it the case that auditing is not enabled at boot time? First, check whether the password is defined in either /boot/grub/user.cfg or /boot/grub/grub.cfg. Run the following commands: $ sudo grep '^[\s]*GRUB2_PASSWORD=grub\.pbkdf2\.sha512.*$' /boot/grub/user.cfg $ sudo grep '^[\s]*password_pbkdf2[\s]+.*[\s]+grub\.pbkdf2\.sha512.*$' /boot/grub/grub.cfg Second, check that a superuser is defined in /boot/grub/grub.cfg. $ sudo grep '^[\s]*set[\s]+superusers=("?)[a-zA-Z_]+\1$' /boot/grub/grub.cfg Is it the case that it does not produce any output? To verify the boot loader superuser password has been set, run the following command: $ sudo grep "^[\s]*GRUB2_PASSWORD=grub\.pbkdf2\.sha512.*$" /boot/efi/EFI/ubuntu/user.cfg The output should be similar to: GRUB2_PASSWORD=grub.pbkdf2.sha512.10000.C4E08AC72FBFF7E837FD267BFAD7AEB3D42DDC 2C99F2A94DD5E2E75C2DC331B719FE55D9411745F82D1B6CFD9E927D61925F9BBDD1CFAA0080E0 916F7AB46E0D.1302284FCCC52CD73BA3671C6C12C26FF50BA873293B24EE2A96EE3B57963E6D7 0C83964B473EC8F93B07FE749AA6710269E904A9B08A6BBACB00A2D242AD828 Is it the case that no password is set? Check that Claroty CTD 5.x has the packages for smart card support installed. Run the following command to determine if the openssl-pkcs11 package is installed: $ dpkg -l openssl-pkcs11 Is it the case that smartcard software is not installed? To verify that the installed operating system is supported, run the following command: Claroty CTD 5.x Is it the case that the installed operating system is not supported? To verify /proc/sys/crypto/fips_enabled exists, run the following command: cat /proc/sys/crypto/fips_enabled The output should be: 1 Is it the case that the command 'cat /proc/sys/crypto/fips_enabled' returns nothing or '0' or the file does not exist? If the system is configured to prevent the loading of the usb-storage kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated /etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r usb-storage /etc/modprobe.conf /etc/modprobe.d Is it the case that no line is returned? To verify that null passwords cannot be used, run the following command: $ grep nullok /etc/pam.d/system-auth /etc/pam.d/password-auth If this produces any output, it may be possible to log into accounts with empty passwords. Remove any instances of the nullok option to prevent logins with empty passwords. Is it the case that NULL passwords can be used? To verify that null passwords cannot be used, run the following command: $ sudo awk -F: '!$2 {print $1}' /etc/shadow If this produces any output, it may be possible to log into accounts with empty passwords. Is it the case that Blank or NULL passwords can be used? Run the following command to determine if the aide package is installed: $ dpkg -l aide Is it the case that the package is not installed? Is it the case that the package is not installed? Run the following command to determine if the audit package is installed: $ dpkg -l audit Is it the case that the audit package is not installed? Run the following command to determine if the chrony package is installed: $ dpkg -l chrony Is it the case that the package is not installed? Run the following command to determine if the nfs-common package is installed: $ dpkg -l nfs-common Is it the case that the package is installed? Run the following command to determine if the nfs-kernel-server package is installed: $ dpkg -l nfs-kernel-server Is it the case that the package is installed? Run the following command to determine if the opensc package is installed: $ dpkg -l opensc Is it the case that the package is not installed? Run the following command to determine if the openssh-server package is installed: $ dpkg -l openssh-server Is it the case that the package is not installed? Run the following command to determine if the libpwquality package is installed: $ dpkg -l libpwquality Is it the case that the package is not installed? Run the following command to determine if the rsh-server package is installed: $ dpkg -l rsh-server Is it the case that the package is installed? Run the following command to determine if the sssd package is installed: $ dpkg -l sssd Is it the case that the package is not installed? Run the following command to determine if the ufw package is installed: $ dpkg -l ufw Is it the case that the package is not installed? Verify the operating system has all system log files under the /var/log directory with a permission set to 640, by using the following command: sudo find /var/log -perm /137 -type f -exec stat -c "%n %a" {} \; Is it the case that not all log files have permission 640 or stricter? Verify the operating system prevents direct logins to the root account with the following command: $ sudo passwd -S root root L 04/23/2020 0 99999 7 -1 If the output does not contain "L" in the second field to indicate the account is locked, then run the following command: $ sudo passwd -l root Is it the case that the output does not contain "L" in the second field? Verify the system-wide shared library files are group-owned by root with the following command: $ sudo find -L /lib /lib64 /usr/lib /usr/lib64 ! -group root -exec ls -l {} \; Is it the case that any system wide shared library file is returned and is not group-owned by root? To verify that remote access methods are logging to rsyslog, run the following command: grep -rE '(auth.\*|authpriv.\*|daemon.\*)' /etc/rsyslog.* The output should contain auth.*, authpriv.*, and daemon.* pointing to a log file. Is it the case that remote access methods are not logging to rsyslog? Run the following command to determine the current status of the auditd service: $ sudo systemctl is-active auditd If the service is running, it should return the following: active Is it the case that the auditd service is not running? To check that the kdump service is disabled in system boot configuration, run the following command: $ sudo systemctl is-enabled kdump Output should indicate the kdump service has either not been installed, or has been disabled at all runlevels, as shown in the example below: $ sudo systemctl is-enabled kdump disabled Run the following command to verify kdump is not active (i.e. not running) through current runtime configuration: $ sudo systemctl is-active kdump If the service is not running the command will return the following output: inactive The service will also be masked, to check that the kdump is masked, run the following command: $ sudo systemctl show kdump | grep "LoadState\|UnitFileState" If the service is masked the command will return the following outputs: LoadState=masked UnitFileState=masked Is it the case that the "kdump" is loaded and not masked? Run the following command to determine the current status of the rsyslog service: $ sudo systemctl is-active rsyslog If the service is running, it should return the following: active Is it the case that the "rsyslog" service is disabled, masked, or not started.? Run the following command to determine the current status of the sshd service: $ sudo systemctl is-active sshd If the service is running, it should return the following: active Is it the case that sshd service is disabled? Run the following command to determine the current status of the sssd service: $ sudo systemctl is-active sssd If the service is running, it should return the following: active Is it the case that the service is not enabled? Run the following command to determine the current status of the ufw service: $ sudo systemctl is-active ufw If the service is running, it should return the following: active Is it the case that the service is not enabled? Verify that the shadow password suite configuration is set to encrypt password with a FIPS 140-2 approved cryptographic hashing algorithm. Check the hashing algorithm that is being used to hash passwords with the following command: $ sudo grep -i ENCRYPT_METHOD /etc/login.defs ENCRYPT_METHOD Is it the case that ENCRYPT_METHOD is not set to <sub idref="var_password_hashing_algorithm" />? To verify the operating system implements certificate status checking for PKI authentication, run the following command: $ sudo grep -i cert_policy /etc/pam_pkcs11/pam_pkcs11.conf The output should return multiple lines similar to the following: cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; Is it the case that ca is not configured? To verify the operating system implements certificate status checking for PKI authentication, run the following command: $ sudo grep -i cert_policy /etc/pam_pkcs11/pam_pkcs11.conf The output should return multiple lines similar to the following: cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; Is it the case that ocsp_on is not configured? To verify the operating system implements local cache of revocation data for PKI authentication, run the following command: sudo grep cert_policy /etc/pam_pkcs11/pam_pkcs11.conf | grep -E -- 'crl_auto|crl_offline' The output should return multiple lines similar to the following: cert_policy = ca,signature,ocsp_on,crl_auto; Is it the case that crl_auto or crl_offline is not configured? Remote access 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. 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). Check that the pam_pkcs11.so option is configured in the etc/pam.d/common-auth file with the following command: # grep pam_pkcs11.so /etc/pam.d/common-auth auth sufficient pam_pkcs11.so If pam_pkcs11.so is not set in etc/pam.d/common-auth this is a finding. Is it the case that non-exempt accounts are not using CAC authentication? To determine how the SSH daemon's PermitEmptyPasswords option is set, run the following command: $ sudo grep -i PermitEmptyPasswords /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf $ sudo grep -i PermitEmptyPasswords /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf If a line indicating no is returned, then the required value is set. Is it the case that the required value is not set? To determine how the SSH daemon's X11Forwarding option is set, run the following command: $ sudo grep -i X11Forwarding /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf $ sudo grep -i X11Forwarding /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf If a line indicating no is returned, then the required value is set. Is it the case that the required value is not set? To determine how the SSH daemon's PermitUserEnvironment option is set, run the following command: $ sudo grep -i PermitUserEnvironment /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf $ sudo grep -i PermitUserEnvironment /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf If a line indicating no is returned, then the required value is set. Is it the case that the required value is not set? To determine how the SSH daemon's UsePAM option is set, run the following command: $ sudo grep -i UsePAM /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf If a line indicating yes is returned, then the required value is set. Is it the case that the required value is not set? To determine how the SSH daemon's PubkeyAuthentication option is set, run the following command: $ sudo grep -i PubkeyAuthentication /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf If a line indicating yes is returned, then the required value is set. Is it the case that the required value is not set? To determine how the SSH daemon's Banner option is set, run the following command: $ sudo grep -i Banner /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf If a line indicating /etc/issue.net is returned, then the required value is set. Is it the case that the required value is not set? Run the following command to see what the timeout interval is: $ sudo grep ClientAliveInterval /etc/ssh/sshd_config If properly configured, the output should be: ClientAliveInterval Is it the case that it is commented out or not configured properly? To ensure ClientAliveInterval is set correctly, run the following command: $ sudo grep ClientAliveCountMax /etc/ssh/sshd_config If properly configured, the output should be: ClientAliveCountMax For SSH earlier than v8.2, a ClientAliveCountMax value of 0 causes a timeout precisely when the ClientAliveInterval is set. Starting with v8.2, a value of 0 disables the timeout functionality completely. If the option is set to a number greater than 0, then the session will be disconnected after ClientAliveInterval * ClientAliveCountMax seconds without receiving a keep alive message. Is it the case that it is commented out or not configured properly? Only FIPS ciphers should be used. To verify that only FIPS-approved ciphers are in use, run the following command: $ sudo grep Ciphers /etc/ssh/sshd_config The output should contain only following ciphers (or a subset) in the exact order: aes256-ctr,aes192-ctr,aes128-ctr Is it the case that FIPS ciphers are not configured or the enabled ciphers are not FIPS-approved? Only FIPS-approved key exchange algorithms must be used. To verify that only FIPS-approved key exchange algorithms are in use, run the following command: $ sudo grep -i kexalgorithms The output should contain only following algorithms (or a subset) in the exact order: Is it the case that KexAlgorithms option is commented out, contains non-approved algorithms, or the FIPS-approved algorithms are not in the exact order? Only FIPS-approved MACs should be used. To verify that only FIPS-approved MACs are in use, run the following command: $ sudo grep -i macs /etc/ssh/sshd_config The output should contain only following MACs (or a subset) in the exact order: MACs Is it the case that MACs option is commented out or not using FIPS-approved hash algorithms? To determine how the SSH daemon's X11UseLocalhost option is set, run the following command: $ sudo grep -i X11UseLocalhost /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf $ sudo grep -i X11UseLocalhost /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf If a line indicating yes is returned, then the required value is set. Is it the case that the display proxy is listening on wildcard address? Ensure "ca" is enabled in "certificate_verification" with the following command: $ sudo grep certificate_verification /etc/sssd/sssd.conf. If configured properly, output should look like certificate_verification = ca_cert,ocsp Is it the case that certificate_verification in sssd is not configured? To verify that SSSD is configured for PAM services, run the following command: $ sudo grep services /etc/sssd/sssd.conf If configured properly, output should be similar to services = pam Is it the case that it does not exist or 'pam' is not added to the 'services' option under the 'sssd' section? To verify that smart cards are enabled in SSSD, run the following command: $ sudo grep pam_cert_auth /etc/sssd/sssd.conf If configured properly, output should be pam_cert_auth = True Is it the case that smart cards are not enabled in SSSD? To verify that SSSD expires offline credentials, run the following command: $ sudo grep offline_credentials_expiration /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf If configured properly, output should be offline_credentials_expiration = 1 Is it the case that it does not exist or is not configured properly? To determine if !authenticate has not been configured for sudo, run the following command: $ sudo grep -r \!authenticate /etc/sudoers /etc/sudoers.d/ The command should return no output. Is it the case that !authenticate is specified in the sudo config files? To determine if NOPASSWD has been configured for sudo, run the following command: $ sudo grep -ri nopasswd /etc/sudoers /etc/sudoers.d/ The command should return no output. Is it the case that nopasswd is specified in the sudo config files? Determine if "sudoers" file restricts sudo access run the following commands: $ sudo grep -PR '^\s*ALL\s+ALL\=\(ALL\)\s+ALL\s*$' /etc/sudoers /etc/sudoers.d/* $ sudo grep -PR '^\s*ALL\s+ALL\=\(ALL\:ALL\)\s+ALL\s*$' /etc/sudoers /etc/sudoers.d/* Is it the case that either of the commands returned a line? The runtime status of the kernel.dmesg_restrict kernel parameter can be queried by running the following command: $ sysctl kernel.dmesg_restrict 1. Is it the case that the correct value is not returned? The runtime status of the kernel.randomize_va_space kernel parameter can be queried by running the following command: $ sysctl kernel.randomize_va_space 2. Is it the case that the correct value is not returned? The runtime status of the net.ipv4.tcp_syncookies kernel parameter can be queried by running the following command: $ sysctl net.ipv4.tcp_syncookies 1. Is it the case that the correct value is not returned? Check the firewall configuration for any unnecessary or prohibited functions, ports, protocols, and/or services by running the following command: $ sudo ufw show raw Ask the System Administrator for the site or program PPSM CLSA. Verify the services allowed by the firewall match the PPSM CLSA. Add all ports, protocols, or services allowed by the PPSM CLSA by using the following command: $ sudo ufw allow "direction" "port/protocol/service" where the direction is "in" or "out" and the port is the one corresponding to the protocol or service allowed. To deny access to ports, protocols, or services, use: $ sudo ufw deny "direction" "port/protocol/service" Is it the case that unauthorized network services can be accessed from the network? Check all the services listening to the ports with the following command: $ sudo ss -l46ut Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 128 [::]:ssh [::]:* For each entry, verify that the ufw is configured to rate limit the service ports with the following command: $ sudo ufw status If any port with a state of "LISTEN" is not marked with the "LIMIT" action, run the following command, replacing "service" with the service that needs to be rate limited: $ sudo ufw limit "service" Rate-limiting can also be done on an interface. An example of adding a rate-limit on the eth0 interface follows: $ sudo ufw limit in on eth0 Is it the case that network interface not rate-limit? Verify that use_mappers is set to pwent in /etc/pam_pkcs11/pam_pkcs11.conf file with the following command: $ grep ^use_mappers /etc/pam_pkcs11/pam_pkcs11.conf use_mappers = pwent Is it the case that use_mappers is not uncommented or configured correctly? Run the following command to determine if the kbd package is installed: $ dpkg -l kbd Is it the case that the package is not installed? Verify that there are no wireless interfaces configured on the system with the following command: Note: This requirement is Not Applicable for systems that do not have physical wireless network radios. $ nmcli device status DEVICE TYPE STATE CONNECTION virbr0 bridge connected virbr0 wlp7s0 wifi connected wifiSSID enp6s0 ethernet disconnected -- p2p-dev-wlp7s0 wifi-p2p disconnected -- lo loopback unmanaged -- virbr0-nic tun unmanaged -- Is it the case that a wireless interface is configured and has not been documented and approved by the Information System Security Officer (ISSO)?