{"stig":{"title":"Broadcom Content Analysis System (CAS) Security Technical Implementation Guide","version":"1","release":"1"},"checks":[{"vulnId":"V-285606","ruleId":"SV-285606r1274298_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must automatically perform both continuous and weekly backups of its configuration settings to a secure, remote server to ensure continuity of operations.","description":"System-level information includes default and customized settings and security attributes, including ACLs that relate to the network device configuration, as well as software required for the execution and operation of the device. Information system backup is a critical step in ensuring system integrity and availability. If the system fails and there is no backup of the system-level information, a denial of service condition is possible for all who utilize this critical network component.\n\nThis control requires the network device to support the organizational central backup process for system-level information associated with the network device. This function may be provided by the network device itself; however, the preferred best practice is a centralized backup rather than each network device performing discrete backups.\n\nSatisfies: SRG-APP-000516-NDM-000340, SRG-APP-000516-NDM-000341","checkContent":"Verify system settings-backup weekly and continuous are set to true and a server is configured with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config system settings-backup\".\n4. Check Weekly Status. If system settings-backup weekly does not state \"true\", this is a finding.\n5. Check Continuous Status. If system settings-backup continuous does not state \"true\", this is a finding.\n6. Check Server Configuration. If there is no remote server configured, this is a finding.","fixText":"Configure system settings-backup with a remote server and enable weekly backup with the following steps:\n\n1. Log on to the SSH CLI.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Enter \"system settings-backup address [IPADDRESS]\". (Replace [IPADDRESS] with the IPv4 or IPv6 address of the backup server.)\n5. Enter \"system settings-backup port PORT\" and replace PORT with the TCP port number of the SCP backup server, e.g., 22.\n6. Enter \"system settings-backup file-path /PATH\" and replace /PATH with the full-qualified filesystem path on the server.\n7. Enter \"system settings-backup use-proxy false\" and replace false if the system must use a proxy to send the backup.\n8. Enter \"system settings-backup username USERNAME\" and replace USERNAME with the username of the SCP backup server.\n9. Enter \"system settings-backup password\", press \"Enter\", and type the password.\n10. Enter \"system settings-backup include-appliance-name true\".\n11. Enter \"system settings-backup weekly true\".\n12. Enter \"system settings-backup continuous true\".\n13. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-000366","CCI-000537","CCI-000539"]},{"vulnId":"V-285607","ruleId":"SV-285607r1273099_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must be running an operating system release that is currently supported by the vendor.","description":"Network devices running an unsupported operating system lack current security fixes required to mitigate the risks associated with recent vulnerabilities.\n\nSatisfies: SRG-APP-000516-NDM-000351, SRG-APP-000457-NDM-000352, SRG-APP-001035-NDM-000340","checkContent":"Verify the CAS release version is at a vendor-supported level with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show version\".\n3. Compare the running version against the list of supported versions found at: https://support.broadcom.com/group/ecx/products.\n\nIf the \"CAS release\" version is no longer supported by the vendor (end of life/end of support), this is a finding.","fixText":"Configure CAS to a vendor-supported release version with the following steps:\n\n1. Log on to the Broadcom Symantec Support Portal at https://support.broadcom.com/group/ecx/products.\n2. Click \"My Downloads\" and select \"Cyber Security Software\".\n3. Search for \"Content Analysis System\" or \"CAS\" from the software downloads.\n4. Expand the product list and select the appropriate hardware model or virtual appliance type.\n5. Select a supported software build and download the image file.\n6. Log on to the CAS Web Management Console.\n7. Navigate to Settings >> Maintenance >> Systems and Upgrades.\n8. Upload the downloaded image and select \"Install\".\n9. Once the installation is complete, select the new version and click \"Restart\" to boot into the supported release.","ccis":["CCI-000366","CCI-002605","CCI-003376"]},{"vulnId":"V-285608","ruleId":"SV-285608r1274299_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must implement signature based and/or nonsignature-based malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code.","description":"System entry and exit points include firewalls, remote access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats contained within compressed or hidden files or hidden in files using techniques such as steganography. Malicious code can be inserted into systems in a variety of ways, including by electronic mail, the world wide web, and portable storage devices. Malicious code insertions occur through the exploitation of system vulnerabilities. A variety of technologies and methods exist to limit or eliminate the effects of malicious code.\n\nMalicious code protection mechanisms include both signature- and nonsignature-based technologies. Nonsignature-based detection mechanisms include artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide controls against such code for which signatures do not yet exist or for which existing signatures may not be effective. Malicious code for which active signatures do not yet exist or may be ineffective includes polymorphic malicious code (i.e., code that changes signatures when it replicates). Nonsignature-based mechanisms also include reputation-based technologies. In addition to the above technologies, pervasive configuration management, comprehensive software integrity controls, and anti-exploitation software may be effective in preventing the execution of unauthorized code. Malicious code may be present in commercial off-the-shelf software as well as custom-built software and could include logic bombs, backdoors, and other types of attacks that could affect organizational mission and business functions.\n\nIn situations where malicious code cannot be detected by detection methods or technologies, organizations rely on other types of controls, including secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to ensure that software does not perform functions other than the functions intended. Organizations may determine that, in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, the detection of malicious downloads, or the detection of maliciousness when attempting to open or execute files.","checkContent":"Verify that antivirus engines, patterns, and scanning behaviors are configured correctly with the following steps:\n\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to System >> Licensing.\n3. Under \"Antivirus\", verify both \"Symantec\" and \"ClamAV\" are checked.\n4. Navigate to Services >> AV Patterns.\n5. Under \"Antivirus Patterns\", verify the \"Symantec\" and \"ClamAV\" patterns have been updated according to the policy-defined frequency.\n6. Under \"Downloads\", verify every \"Status\" entry displays \"Success (200)\".\n7. Navigate to Services >> AV Scanning Behavior.\n8. Verify that \"Cached Responses\" is set to \"Enabled\".\n9. Navigate to Services >> AV File Types.\n10. Under both \"Global Options\" and \"Symantec Options\", verify that every file category has \"scan\" selected.\n11. Navigate to Services >> File Reputation.\n12. Verify \"Cached Responses\" is checked.\n\nIf any of the above conditions are not met, this is a finding.","fixText":"Configure antivirus engines, update patterns, and set scanning behaviors with the following steps:\n\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to System >> Licensing.\n3. Under \"Antivirus\", check the boxes for \"Symantec\" and \"ClamAV\".\n4. Click \"Save Changes\".\n5. Navigate to Services >> AV Patterns.\n6. Click \"Force Update All Now\" under the \"Antivirus Patterns\" section.\n7. Navigate to Services >> AV Scanning Behavior.\n8. Select \"Enabled\" under the \"Cached Responses\" section.\n9. Click \"Save Changes\".\n10. Navigate to Services >> AV File Types.\n11. Under both \"Global Options\" and \"Symantec Options\", select the radio button for \"scan\" for all available file categories.\n12. Click \"Save Changes\".\n13. Navigate to Services >> File Reputation.\n14. Check the box for \"Cached Responses\".\n15. Click \"Save Changes\".","ccis":["CCI-000366"]},{"vulnId":"V-285609","ruleId":"SV-285609r1273161_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must be configured to operate in a FIPS-compliant mode to ensure the use of FIPS 140-3-validated cryptographic modules and algorithms.","description":"Unencrypted and weakly encrypted connections used for administrative sessions are highly susceptible to man-in-the-middle (MITM) attacks, eavesdropping, and session hijacking. If nonsecure protocols (such as HTTP or Telnet) or deprecated cryptographic algorithms are permitted, malicious actors can intercept sensitive management traffic, capture administrative credentials, or inject unauthorized commands into the session stream.\n\nTo mitigate these risks, DoW policy mandates that all administrative communications must be protected using strong, approved cryptography. This ensures the confidentiality of the data in transit (preventing unauthorized viewing), the integrity of the session (preventing unauthorized modification), and the authenticity of the endpoints (ensuring the administrator is communicating with the genuine device).\n\nFor the Broadcom CAS, enforcing FIPS mode ensures the appliance strictly utilizes FIPS 140-3-validated cryptographic modules. Activating this mode inherently disables nonsecure legacy protocols and weak ciphers, guaranteeing that all administrative management interfaces rely solely on DoW-approved encryption standards to protect the system from exploitation.\n\nSatisfies: SRG-APP-000179-NDM-000265, SRG-APP-000142-NDM-000245, SRG-APP-000224-NDM-000270, SRG-APP-000411-NDM-000330, SRG-APP-000412-NDM-000331","checkContent":"Verify the system is in FIPS mode with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show version\".\n3. Review the output for the FIPS status.\n\nIf \"System is in FIPS mode\" is not displayed, this is a finding.","fixText":"Configure the system to enable FIPS mode with the following steps:\n\nNote: Enabling FIPS mode will perform a factory reset, erasing all existing configurations, local user accounts, and data. This should only be performed during initial deployment or a scheduled maintenance window after all configurations have been backed up.\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Enter \"fips-mode enable\".\n5. When prompted to confirm the factory reset and reboot, enter \"yes\".\n\nThe system will reboot, reset all configurations, and initialize in FIPS-compliant mode.","ccis":["CCI-000803","CCI-000382","CCI-001188","CCI-002890","CCI-003123"]},{"vulnId":"V-285610","ruleId":"SV-285610r1273618_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must limit the number of concurrent sessions to a maximum of three for each account type.","description":"Device management includes the ability to control the number of administrators and management sessions that manage a device. Limiting the number of allowed administrators and sessions per administrator based on account type, role, or access type is helpful in limiting risks related to denial of service (DoS) attacks.\n\nThis requirement addresses concurrent sessions for administrative accounts and does not address concurrent sessions by a single administrator via multiple administrative accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system. At a minimum, limits must be set for SSH, HTTPS, account of last resort, and root account sessions.","checkContent":"Verify the number of concurrent user sessions is set to \"3\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config authentication\".\n4. Review the output for the \"max-concurrent-logins\" value.\n\nIf \"max-concurrent-logins\" is not set to \"3\", or the setting is missing, this is a finding.","fixText":"Configure the maximum concurrent user sessions to \"3\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and then enter the password.\n3. Enter \"configure terminal\".\n4. Enter \"authentication management max-concurrent-logins 3\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-000054"]},{"vulnId":"V-285611","ruleId":"SV-285611r1273103_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must enforce Role-Based Access Control (RBAC) to ensure least privilege and protect system configurations, cryptographic settings, and audit records from unauthorized access or modification.","description":"If a network device does not strictly enforce access control policies, a compromised account or an insider threat could gain unrestricted access to the entire system. Without the principle of least privilege and separation of duties, a standard administrator might be able to alter cryptographic keys, modify security policies, or delete audit logs to cover their tracks.\n\nTo mitigate this risk, the system must employ RBAC. By mapping authenticated users to specific, restricted roles (such as separating full Administrators from Read-Only viewers), the CAS ensures that users are only granted the specific permissions necessary to perform their assigned duties. This architectural enforcement protects the integrity of audit trails, secures cryptographic modules, and ensures compliance with DoW access control mandates.\n\nNetwork devices that rely on AAA brokers for authentication and authorization services may need to identify the available security groups or access levels available on the network devices and convey that information to the AAA operator. Once the AAA broker identifies the user persona on the centralized directory service, the user’s security group memberships can be retrieved. The AAA operator may need to create a mapping that links target security groups from the directory service to the appropriate security groups or access levels on the network device. Once these mappings are configured, authorizations can happen dynamically, based on each user’s directory service group membership.\n\nSatisfies: SRG-APP-000033-NDM-000212, SRG-APP-000119-NDM-000236, SRG-APP-000120-NDM-000237, SRG-APP-000121-NDM-000238, SRG-APP-000122-NDM-000239, SRG-APP-000123-NDM-000240, SRG-APP-000133-NDM-000244, SRG-APP-000231-NDM-000271, SRG-APP-000329-NDM-000287, SRG-APP-000340-NDM-000288, SRG-APP-000378-NDM-000302, SRG-APP-000380-NDM-000304, SRG-APP-000408-NDM-000314, SRG-APP-000516-NDM-000335","checkContent":"Verify LDAP group-to-role mappings are configured and match site documentation with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"authentication ldap list-groups\".\n4. Verify the appropriate group and roles are assigned for authenticated users.\n\nIf the group-to-role mappings are missing or do not match site documentation, this is a finding.","fixText":"Configure LDAP group-to-role mappings to match site documentation with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and enter the password.\n3. Enter \"configure terminal\".\n4. Map the Administrator Group by entering \"authentication ldap group [Distinguished Name of the Admin Group]\".\n5. Enter \"role admin\".\n6. Enter \"exit\" to return to the config context.\n7. Map the Read-Only Viewer Group by entering \"authentication ldap group [Distinguished Name of the Viewer Group]\".\n8. Enter \"role read-only\".\n9. Enter \"exit\" to return to the config context and then exit configuration mode.\n\nNote: The Distinguished Name (DN) must be the full, exact path to the security group object in the directory (e.g., \"CN=CAS_Admins,OU=Security Groups,DC=example,DC=com\").","ccis":["CCI-000213","CCI-000163","CCI-000164","CCI-001493","CCI-001494","CCI-001495","CCI-001499","CCI-001199","CCI-002169","CCI-000366","CCI-002235","CCI-003980","CCI-001813","CCI-002883","CCI-000345"]},{"vulnId":"V-285612","ruleId":"SV-285612r1273104_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured to enforce the limit of three consecutive invalid logon attempts, after which time it must block any login attempt for 15 minutes.","description":"By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced.","checkContent":"Verify \"local-lockout\" is set to \"max-failed-attempts 3\", \"lockout-duration 900\", and \"reset-interval 900\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config authentication\" and review the output for the following exact settings:\n\"local-lockout max-failed-attempts 3\"\n\"local-lockout lockout-duration 900\"\n\"local-lockout reset-interval 900\"\n\nIf the values do not match exactly as specified above, this is a finding.","fixText":"Configure \"local-lockout\" to \"max-failed-attempts 3\", \"lockout-duration 900\", and \"reset-interval 900\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Set the maximum failed attempts by entering \"authentication local-lockout max-failed-attempts 3\".\n5. Set the lockout duration by entering \"authentication local-lockout lockout-duration 900\".\n6. Set the reset interval by entering \"authentication local-lockout reset-interval 900\".\n7. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-000044"]},{"vulnId":"V-285613","ruleId":"SV-285613r1273105_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must display the Standard Mandatory DoW Notice and Consent Banner before granting access to the device.","description":"Display of the DoW-approved use notification before granting access to the network device ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSystem use notifications are required only for access via logon interfaces with human users.\n\nSatisfies: SRG-APP-000068-NDM-000215, SRG-APP-000069-NDM-000216","checkContent":"Verify the DoW consent banner is enabled and the required banner text is displayed with the following steps:\n\nValidate the banner from the Web UI:\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to Settings >> Consent Banner.\n3. Verify \"Show Consent Banner\" is checked.\n4. Verify the exact required banner is displayed in the \"Banner Text\" field.\n(Note: The required text is found below. This can also be accomplished by clicking \"Display current consent banner\" under the preview section of this page.)\n\nValidate the banner from SSH access:\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config consent-banner\".\n\nRequired Banner Text:\nYou are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\n\nIf the \"Show Consent Banner\" option is not checked, or if the required banner text is missing or incorrect in either the Web UI or the CLI, this is a finding.","fixText":"Configure the DoW consent banner to be enabled with the required banner text with the following steps:\n\nConfigure the banner for the Web UI:\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to Settings >> Consent Banner.\n3. Click the \"Show Consent Banner\" checkbox.\n4. Under the \"Banner Text\" field, copy and paste the required DoW banner text exactly as specified in the Check.\n5. Click \"Save Changes\".\n\nConfigure the banner for SSH access:\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Enable the CLI banner by entering \"consent-banner show-banner true\".\n5. Copy and paste the following command string exactly as written (with no spaces before the newlines \\n):\n\n\"consent-banner banner-text \"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\\n\\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\\n-At any time, the USG may inspect and seize data stored on this IS.\\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\\n\"\"\n\nEnter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-000048","CCI-000050"]},{"vulnId":"V-285614","ruleId":"SV-285614r1273163_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must map the authenticated identity to the user account for PKI-based authentication.","description":"This requirement supports nonrepudiation of actions taken by an administrator and is required to maintain the integrity of the configuration management process. All configuration changes to the network device are logged, and administrators authenticate with two-factor authentication before gaining administrative access. Together, these processes will ensure the administrators can be held accountable for the configuration changes they implement.\n\nTo meet this requirement, the network device must log administrator access and activity.","checkContent":"Verify the system is configured to extract the correct Principal Name from the certificate for identity mapping with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config authentication\".\n4. Review the output for the following exact setting:\n\"certificate-auth user-regex \"PN=(.*?)(,|/|$)\"\n\nIf \"certificate-auth user-regex\" is not set exactly as specified above, this is a finding.","fixText":"Configure the system to map the authenticated identity with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and then enter the password.\n3. Enter \"configure terminal\".\n4. Set the certificate user regular expression by entering \"authentication certificate-auth user-regex \"PN=(.*?)(,|/|$)\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-000166"]},{"vulnId":"V-285618","ruleId":"SV-285618r1274301_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must disable nonsecure ports, protocols, and services to prevent unauthorized access and protect the integrity of the system.","description":"Authentication for administrative (privileged level) access to the device is required at all times. An account can be created on the device's local database for use when the authentication server is down or connectivity between the device and the authentication server is not operable. This account is referred to as the account of last resort since it is intended to be used as a last resort and when immediate administrative access is absolutely necessary.\n\nThe account of last resort logon credentials must be stored in a sealed envelope and kept in a safe. The safe must be periodically audited to verify the envelope remains sealed. The signature of the auditor and the date of the audit should be added to the envelope as a record. Administrators should secure the credentials and disable the root account (if possible) when not needed for system administration functions.","checkContent":"Verify CAS does not have any unnecessary or nonsecure ports, protocols, and services enabled with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config\".\n4. Review the running configuration. For example, the following commands/settings should not be present or active:\n\n\"web-management http enable\" (HTTP web management active)\n\"agent version v1\" or \"agent version v2c\" under the SNMP configuration\n\"protocol TCP\" or \"protocol UDP\" under syslog-alerts (unless \"protocol TLS\" is used)\n\"encryption type none\" under the SMTP email-alerts settings\n\"authentication rest-api-key\" (active, undocumented REST API keys)\n\nIf any unnecessary or nonsecure ports, protocols, or services are enabled, this is a finding.","fixText":"Configure the system to disable nonsecure ports, protocols, and services with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\", enter the password, and enter \"configure terminal\".\n3. Disable unencrypted HTTP web management by entering \"web-management http disable\".\n4. Disable legacy SNMP protocols and enforce SNMPv3 by entering \"snmp\" and then \"agent version v3\".\n5. Disable plaintext syslog forwarding and enforce TLS by entering \"alerts syslog-alerts servers [HOSTNAME] protocol TLS\".\n6. Remove any active, undocumented REST API keys by entering \"authentication rest-api-key delete [ID]\". (Replace [ID] with the key identifier.)\n7. Enter \"exit\" and then \"exit\" again to leave configuration mode.","ccis":["CCI-000382"]},{"vulnId":"V-285619","ruleId":"SV-285619r1273165_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured with only one local account to be used as the account of last resort in the event the authentication server is unavailable.","description":"Authentication for administrative (privileged level) access to the device is required at all times. An account can be created on the device's local database for use when the authentication server is down or connectivity between the device and the authentication server is not operable. This account is referred to as the account of last resort since it is intended to be used as a last resort and when immediate administrative access is absolutely necessary.\n\nThe account of last resort logon credentials must be stored in a sealed envelope and kept in a safe. The safe must be periodically audited to verify the envelope remains sealed. The signature of the auditor and the date of the audit should be added to the envelope as a record. Administrators should secure the credentials and disable the root account (if possible) when not needed for system administration functions.","checkContent":"Verify only one local account exists and the console-account is set to \"fallback-only\" with the following steps:\n\nVerify local accounts via Web UI:\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to Settings >> Users >> Local Users.\n3. Scroll down to the \"Users\" section and verify only the documented and approved account of last resort exists.\n\nVerify fallback configuration via CLI:\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config authentication\".\n3. Review the output for \"authentication management console-account\".\n\nIf any user other than the documented and approved local account of last resort exists, or if the console-account configuration states \"always\" instead of \"fallback-only\", this is a finding.","fixText":"Configure the local account to \"fallback-only\" and remove all unauthorized local users with the following steps:\n\nRemove unauthorized users via Web UI:\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to Settings >> Users >> Local Users.\n3. Scroll down to the \"Users\" section.\nNote: Only the documented and approved account of last resort is permitted.\n4. Delete all other local users by selecting the user, clicking \"Delete User\", and selecting \"Yes\" when prompted to confirm.\n5. Click \"Save Changes\".\n\nConfigure fallback-only via CLI:\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Set the console account to fallback-only by entering \"authentication management console-account fallback-only\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.\n6. To verify the change, attempt to log in with the local admin account while the external authentication server is reachable. It should prompt for a password but not permit successful login.","ccis":["CCI-001358","CCI-002111"]},{"vulnId":"V-285620","ruleId":"SV-285620r1273113_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must disable nonsecure TLS versions to prevent the use of deprecated cryptographic protocols for network communications.","description":"Legacy cryptographic protocols, such as TLS version 1.0 and 1.1, contain inherent design flaws and known vulnerabilities that allow attackers to decrypt or manipulate data in transit. To secure the system's communication channels and APIs (such as the ICAP interface), these nonsecure protocols must be explicitly disabled. The appliance must be configured to enforce only DoW-approved, secure protocols (TLS 1.2 and TLS 1.3) to ensure the confidentiality and integrity of all transmitted data.","checkContent":"Verify nonsecure TLS versions are disabled and secure TLS versions are enforced with the following steps:\n\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to Settings >> ICAP.\n3. Under \"TLS Settings\", verify that \"TLSv1\" and \"TLSv1.1\" are not checked.\n4. Verify that \"TLSv1.2\" and \"TLSv1.3\" are checked.\n\nIf either \"TLSv1\" or \"TLSv1.1\" are checked, or if the approved secure TLS versions are not enabled, this is a finding.","fixText":"Configure the CAS to disable nonsecure TLS versions and enforce secure TLS versions with the following steps:\n\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to Settings >> ICAP.\n3. Under \"TLS Settings\", uncheck \"TLSv1\" and \"TLSv1.1\" to disable the nonsecure protocols.\n4. Check the boxes to enable \"TLSv1.2\" and \"TLSv1.3\".\n5. Click \"Save Settings\".","ccis":["CCI-000382"]},{"vulnId":"V-285621","ruleId":"SV-285621r1273114_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must use DoW Public Key Infrastructure (PKI) to enforce multifactor authentication for all interactive administrative logins.","description":"Multifactor authentication (MFA) is when two or more factors are used to confirm the identity of an individual who is requesting access to digital information resources. Valid factors include something the individual knows (e.g., username and password), something the individual has (e.g., a smartcard or token), or something the individual is (e.g., a fingerprint or biometric). Legacy information system environments only use a single factor for authentication, typically a username and password combination. Although two pieces of data are used in a username and password combination, this is still considered single factor because an attacker can obtain access simply by learning what the user knows. Common attacks against single-factor authentication are attacks on user passwords. These attacks include brute force password guessing, password spraying, and password credential stuffing. MFA, along with strong user account hygiene, helps mitigate against the threat of having account passwords discovered by an attacker. Even in the event of a password compromise, with MFA implemented and required for interactive login, the attacker still needs to acquire something the user has or replicate a piece of user’s biometric digital presence.\n\nPrivate industry recognizes and uses a wide variety of MFA solutions. However, DoW public key infrastructure (PKI) is the only prescribed method approved for DoW organizations to implement MFA. For authentication purposes, centralized DoW certificate authorities (CA) issue PKI certificate key pairs (public and private) to individuals using the prescribed x.509 format. The private certificates that have been generated by the issuing CA are downloaded and saved to smartcards which, within DoW, are referred to as common access cards (CAC) or personal identity verification (PIV) cards. This happens at designated DoW badge facilities. The CA maintains a record of the corresponding public keys for use with PKI-enabled environments. Privileged user smartcards, or \"alternate tokens\", function in the same manner, so this requirement applies to all interactive user sessions (authorized and privileged users).\n\nNote: This requirement is used in conjunction with the use of a centralized authentication server (e.g., AAA, RADIUS, LDAP), a separate but equally important requirement. The MFA configuration of this requirement provides identification and the first phase of authentication (the challenge and validated response, thereby confirming the PKI certificate that was presented by the user). The centralized authentication server will provide the second phase of authentication (the digital presence of the PKI ID as a valid user in the requested security domain) and authorization. The centralized authentication server will map validated PKI identities to valid user accounts and determine access levels for authenticated users based on security group membership and role. In cases where the centralized authentication server is not utilized by the network device for user authorization, the network device must map the authenticated identity to the user account for PKI-based authentication.\n\nSatisfies: SRG-APP-000149-NDM-000247, SRG-APP-000825-NDM-000180","checkContent":"Verify the system is configured to require certificate authentication with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config authentication\".\n4. Review the output for the following exact setting:\n\"certificate-auth require-certificate-auth true\"\n\nIf \"certificate-auth require-certificate-auth\" is not set to \"true\", this is a finding.","fixText":"Configure the system to require certificate authentication with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and enter the password.\n3. Enter \"configure terminal\".\n4. Enforce PKI authentication by entering \"authentication certificate-auth require-certificate-auth true\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-000765","CCI-004047"]},{"vulnId":"V-285623","ruleId":"SV-285623r1273116_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must enforce a minimum 15-character password length.","description":"Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password.\n\nThe shorter the password, the lower the number of possible combinations that must be tested before the password is compromised. Use of more characters in a password helps to increase exponentially the time and/or resources required to compromise the password.","checkContent":"Verify \"min-length\" is set to \"15\" and \"min-groups\" is set to \"4\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config authentication password-policy\".\n3. Review the output for the specific length and group requirements.\n\nIf \"min-length\" is not set to \"15\" or \"min-groups\" is not set to \"4\", this is a finding.","fixText":"Configure password \"min-length\" to \"15\" and \"min-groups\" to \"4\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Set the minimum password length by entering \"authentication password-policy min-length 15\".\n5. Set the minimum character groups required by entering \"authentication password-policy min-groups 4\".\n6. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-004066"]},{"vulnId":"V-285624","ruleId":"SV-285624r1273117_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must enforce password complexity by requiring that at least one uppercase character be used.","description":"Use of a complex passwords helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.\n\nMultifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account.","checkContent":"Verify \"min-uppercase\" is set to \"1\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config authentication password-policy\".\n3. Review the output for the uppercase character requirement.\n\nIf \"min-uppercase\" is not set to \"1\", this is a finding.","fixText":"Configure password \"min-uppercase\" to \"1\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Set the minimum uppercase character requirement by entering \"authentication password-policy min-uppercase 1\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-004066"]},{"vulnId":"V-285625","ruleId":"SV-285625r1273167_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must enforce password complexity by requiring that at least one lowercase character be used.","description":"Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.\n\nMultifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account.","checkContent":"Verify \"min-lowercase\" is set to \"1\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config authentication password-policy\".\n3. Review the output for the lowercase character requirement.\n\nIf \"min-lowercase\" is not set to \"1\", this is a finding.","fixText":"Configure password \"min-lowercase\" to \"1\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Set the minimum lowercase character requirement by entering \"authentication password-policy min-lowercase 1\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-004066"]},{"vulnId":"V-285626","ruleId":"SV-285626r1273119_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must enforce password complexity by requiring that at least one numeric character be used.","description":"Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.\n\nMultifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account.","checkContent":"Verify \"min-digits\" is set to \"1\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config authentication password-policy\".\n3. Review the output for the numeric character requirement.\n\nIf \"min-digits\" is not set to \"1\", this is a finding.","fixText":"Configure password \"min-digits\" to \"1\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Set the minimum numeric character requirement by entering \"authentication password-policy min-digits 1\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-004066"]},{"vulnId":"V-285627","ruleId":"SV-285627r1273120_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must enforce password complexity by requiring that at least one special character be used.","description":"Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.\n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.\n\nMultifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account.","checkContent":"Verify \"min-special\" is set to \"1\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config authentication password-policy\".\n3. Review the output for the special character requirement.\n\nIf \"min-special\" is not set to \"1\", this is a finding.","fixText":"Configure password \"min-special\" to \"1\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Set the minimum special character requirement by entering \"authentication password-policy min-special 1\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-004066"]},{"vulnId":"V-285628","ruleId":"SV-285628r1273168_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must require that when a password is changed, the characters are changed in at least eight of the positions within the password.","description":"If the application allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks.\n\nThe number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.\n\nMultifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account.","checkContent":"Verify \"min-changes\" is set to \"8\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config authentication password-policy\".\n3. Review the output for the minimum character changes requirement.\n\nIf \"min-changes\" is not set to \"8\", this is a finding.","fixText":"Configure password \"min-changes\" to \"8\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Set the minimum character change requirement by entering \"authentication password-policy min-changes 8\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-004066"]},{"vulnId":"V-285631","ruleId":"SV-285631r1273124_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must be configured to use DoW-approved online certificate status protocol (OCSP) responders or certificate revocation lists (CRLs) to validate certificates used for PKI-based authentication.","description":"Once issued by a DoW certificate authority (CA), public key infrastructure (PKI) certificates are typically valid for three years or shorter within the DoW. However, there are many reasons a certificate may become invalid before the prescribed expiration date. For example, an employee may leave or be terminated and still possess the smartcard on which the PKI certificates were stored. Another example is that a smartcard containing PKI certificates may become lost or stolen. A more serious issue could be that the CA or server which issued the PKI certificates has become compromised, thereby jeopardizing every certificate keypair that was issued by the CA. These examples of revocation use cases and many more can be researched further using internet cybersecurity resources.\n\nPKI user certificates presented as part of the identification and authentication criteria (e.g., DoW PKI as multifactor authentication [MFA]) must be checked for validity by network devices. For example, valid PKI certificates are digitally signed by a trusted DoW CA. Additionally, valid PKI certificates are not expired, and valid certificates have not been revoked by a DoW CA.\n\nNetwork devices can verify the validity of PKI certificates by checking with an authoritative CA. One method of checking the status of PKI certificates is to query databases referred to as CRLs. These are lists which are published, updated, and maintained by authoritative DoW CAs. For example, once certificates are expired or revoked, issuing CAs place the certificates on a CRL. Organizations can download these lists periodically (i.e., daily or weekly) and store them locally on the devices themselves or even onto another nearby local enclave resource. Storing them locally ensures revocation status can be checked even if internet connectivity is severed at the enclave’s point of presence (PoP). However, CRLs can be rather large in storage size and further, the use of CRLs can be rather taxing on some computing resources.\n\nAnother method of validating certificate status is to use the OCSP. Using OCSP, a requestor (i.e., the network device which the user is trying to authenticate to) sends a request to an authoritative CA challenging the validity of a certificate that has been presented for identification and authentication. The CA receives the request and sends a digitally signed response indicating the status of the user’s certificate as valid, revoked, or unknown. Network devices should only allow access for responses that indicate the certificates presented by the user were considered valid by an approved DoW CA. OCSP is the preferred method because it is fast, provides the most current status, and is lightweight.","checkContent":"Verify the system is configured to check certificate revocation with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config authentication\".\n4. Review the output for the setting: \"certificate-auth use-revocation true\".\n\nIf \"certificate-auth use-revocation\" is not set to \"true\", this is a finding.","fixText":"Configure the system to check certificate revocation with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\", and then enter the password.\n3. Enter \"configure terminal\".\n4. Enter \"authentication certificate-auth use-revocation true\".\n5. Enter \"exit\" and then \"exit\" again to leave configuration mode.","ccis":["CCI-000185"]},{"vulnId":"V-285632","ruleId":"SV-285632r1274303_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must be configured to use a centralized authentication server to securely map PKI-authenticated identities to administrative user accounts and roles.","description":"Without mapping the PKI certificate to a unique user account, the ability to determine the identities of individuals or the status of their nonrepudiation is considerably impacted during forensic analysis. A strength of using PKI as multifactor authentication (MFA) is that it can help ensure only the assigned individual is using their associated user account. This can only be accomplished if the network device is configured to enforce the relationship which binds PKI certificates to unique user accounts.\n\nLocal accounts (accounts created, stored, and maintained locally on the network device) should be avoided in lieu of using a centrally managed directory service. Local accounts empower the same workgroup who will be operating the network infrastructure to also control and manipulate access methods, thus creating operational autonomy. This undesirable approach breaks the concept of separation of duties. Additionally, local accounts are susceptible to poor cyber hygiene because they create another user database that must be maintained by the operator, whose primary focus is on running the network. Such examples of poor hygiene include dormant accounts that are not disabled or deleted, employees who have left the organization but whose accounts are still present, periodic password and hash rotation, password complexity shortcomings, increased exposure to insider threat, etc. For reasons such as this, local users on network devices are frequently the targets of cyber-attacks. Instead, organizations should explore examples of centrally managed account services. These examples include the implementation of AAA concepts like the use of external Remote Authentication Dial-In User Service (RADIUS) and Lightweight Directory Access Protocol (LDAP) directory service brokers.\n\nSatisfies: SRG-APP-000177-NDM-000263, SRG-APP-000516-NDM-000336","checkContent":"Verify secure LDAP is configured and PKI identities are mapped to roles with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config authentication\".\n4. Verify LDAP is enabled by checking for the setting \"authentication ldap enable\".\n5. Verify the LDAP URL utilizes a secure connection by checking that it begins with \"ldaps://\".\n6. Verify the PKI identity mapping is configured by checking for the setting \"authentication ldap public-key-attribute altSecurityIdentities\".\n7. Verify at least one group is mapped to an administrative role (e.g., \"role admin\").\n\nIf LDAP is not enabled, the URL does not use \"ldaps://\", or the PKI-to-role mappings are missing, this is a finding.","fixText":"Configure secure LDAP and map PKI identities to administrative roles with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and enter the password.\n3. Enter \"configure terminal\".\n4. Enable LDAP authentication by entering \"authentication ldap enable\".\n5. Define the secure LDAP URL by entering \"authentication ldap url ldaps://[Site URL]\". (Replace [Site URL] with the LDAPS server address.)\n6. Configure the necessary LDAP connection and search parameters by entering the following commands (replacing the bracketed text with site-specific DNs):\n\"authentication ldap search-credentials username [Full DN of Service Account]\"\n\"authentication ldap search-credentials password\" (press Enter and provide the password)\n\"authentication ldap user-search username userPrincipalName\"\n\"authentication ldap user-search base [User Search Base]\"\n\"authentication ldap role-search username userPrincipalName\"\n\"authentication ldap role-search base [Role Search Base]\"\n\"authentication ldap role-search attribute memberOf\"\n7. Map the PKI identity attribute by entering \"authentication ldap public-key-attribute altSecurityIdentities\".\n8. Map the enterprise group to the CAS administrator role by entering \"authentication ldap group [Site Admin Group DN]\".\n9. Enter \"role admin\".\n10. Enter \"exit\" and then \"exit\" again to leave configuration mode.","ccis":["CCI-000187","CCI-000764","CCI-000166","CCI-000370"]},{"vulnId":"V-285634","ruleId":"SV-285634r1273169_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must terminate all network connections associated with a device management session at the end of the session, or the session must be terminated after five minutes of inactivity.","description":"Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. \n\nTerminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. This does not mean that the device terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.","checkContent":"Verify \"inactivity-timeout\" is set to \"300\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config authentication\".\n4. Review the output for the \"inactivity-timeout\" value.\n\nIf \"inactivity-timeout\" is not set to \"300\", or the setting is missing, this is a finding.","fixText":"Configure \"inactivity-timeout\" to \"300\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Set the inactivity timeout by entering \"authentication management inactivity-timeout 300\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-001133"]},{"vulnId":"V-285641","ruleId":"SV-285641r1274305_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must provide an immediate real-time alert to appropriate personnel (such as the system administrator [SA] and information system security officer [ISSO]) upon the detection of an audit failure or the unauthorized access, modification, or deletion of audit information.","description":"It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. \n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).\n\nSatisfies: SRG-APP-000360-NDM-000295, SRG-APP-000795-NDM-000130","checkContent":"Verify \"email-alerts\" servers are configured with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config alerts\".\n3. Review the output to verify a sender, recipient, and SMTP server are defined.\n\nIf there are no \"email-alerts\" servers configured or the settings are incomplete, this is a finding.","fixText":"1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\", enter the password, and then enter \"configure terminal\".\n3. Configure the alert sender and recipient addresses (replacing bracketed text with site values) by entering:\n\"alerts email-alerts addresses sender [SENDER_EMAIL]\"\n\"alerts email-alerts addresses recipients to [SA_ISSO_EMAIL]\"\n4. Configure the SMTP server and connection settings by entering:\n\"alerts email-alerts server-settings server [SERVER_IP_OR_HOSTNAME]\"\n\"alerts email-alerts server-settings encryption port [PORT]\"\n5. Configure the SMTP service account authentication by entering:\n\"alerts email-alerts authentication username [USER]\"\n\"alerts email-alerts authentication password [PASSWORD]\"\n6. Enforce secure SMTP encryption by entering:\n\"alerts email-alerts server-settings encryption type StartTLS\" (replace with TLS if the gateway requires strict TLS)\n\"alerts email-alerts server-settings encryption verify-certificate true\"\n7. Enter \"exit\" and then \"exit\" again to leave configuration mode.","ccis":["CCI-001858","CCI-003831"]},{"vulnId":"V-285642","ruleId":"SV-285642r1273135_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).","description":"If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis.\n\nTime stamps generated by the application include date and time. Time is commonly expressed in UTC, a modern continuation of GMT, or local time with an offset from UTC.","checkContent":"Verify the time zone is set to \"UTC\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show timezone current\".\n3. Review the output for the current system time zone setting.\n\nIf \"Timezone\" does not state \"UTC\", this is a finding.","fixText":"Configure the time zone to \"UTC\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Set the system time zone by entering \"timezone UTC\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-001890"]},{"vulnId":"V-285644","ruleId":"SV-285644r1273137_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured to authenticate Simple Network Management Protocol (SNMP) messages using a Federal Information Processing Standards (FIPS)-validated Keyed-Hash Message Authentication Code (HMAC).","description":"Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk.\n\nA local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area or wide area network, internet). A remote connection is any connection with a device communicating through an external network (e.g., the internet).\n\nBecause of the challenges of applying this requirement on a large scale, organizations are encouraged to only apply the requirement to those limited number (and type) of devices that truly need to support this capability.","checkContent":"Verify the SNMP agent version is set to \"v3\" and a USM local user is configured with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config snmp\".\n4. Review the output to ensure the agent version is \"v3\" and a \"usm local user\" is defined with appropriate authentication and privacy settings.\n\nIf the agent version is not \"v3\" or if a \"usm local user\" is not configured, this is a finding.","fixText":"Configure the SNMP agent to version v3 and define a USM local user with HMAC authentication with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\", enter the password, enter \"configure terminal\", and then enter \"snmp\".\n3. Enable the SNMPv3 agent by entering the following commands:\n\"agent enabled\"\n\"agent version v3\"\n4. Create the USM user and enforce SHA (HMAC) authentication and AES privacy by typing (replacing bracketed text with site values):\n\"usm local user [USERNAME]\"\n\"auth sha password [AUTH_PASSWORD]\"\n\"priv aes password [PRIV_PASSWORD]\"\n\"exit\"\n5. Map the user to a VACM group and enforce authenticated access by entering: \n\"vacm group [GROUPNAME] member [USERNAME]\" (Enter \"usm\" when prompted for sec-model)\n\"exit\"\n\"vacm group [GROUPNAME] access usm auth-priv read-view cas-view write-view cas-view\"\n6. Enter \"exit\" and then \"exit\" again to leave configuration mode.","ccis":["CCI-001967"]},{"vulnId":"V-285645","ruleId":"SV-285645r1274307_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured to authenticate Network Time Protocol (NTP) sources using authentication with Federal Information Processing Standards (FIPS)-compliant algorithms.","description":"If NTP is not authenticated, an attacker can introduce a rogue NTP server. This rogue server can then be used to send incorrect time information to network devices, which will make log timestamps inaccurate and affect scheduled actions. \n\nNTP authentication is used to prevent this tampering by authenticating the time source.","checkContent":"Review the CAS configuration to verify it authenticates NTP sources using authentication with FIPS-compliant algorithms with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show clock\".\n4. Review the output for the NTP symmetric-key authentication status.\n\nNote: CAS is limited to SHA1 for NTP authentication, and incurs a permanent CAT III finding as it is not FIPS compliant. SHA1 partially reduces the risk but cannot fully mitigate it.\n\nIf the CAS is not configured to authenticate NTP sources with a FIPS-compliant algorithm, this is a finding.","fixText":"Configure the CAS to authenticate NTP sources using authentication with FIPS-compliant algorithms with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\", enter the password, and enter \"configure terminal\".\n3. Configure the authentication key by entering \"ntp symmetric-key [NUMBER] algorithm sha1 secret [NTPKEY]\". (Replace [NUMBER] with the ID of the key on the NTP server and [NTPKEY] with the SHA1 NTP preshared key.)\n4. Enforce authentication on the primary NTP server by entering \"ntp server [FIRSTNTPSERVER] symmetric-key [NUMBER]\". (Replace [NUMBER] with the ID of the key and [FIRSTNTPSERVER] with the IP address or hostname of the primary NTP server.)\n5. Enforce authentication on the secondary NTP server by entering \"ntp server [SECONDNTPSERVER] symmetric-key [NUMBER]\". (Replace [NUMBER] with the ID of the key and [SECONDNTPSERVER] with the IP address or hostname of the secondary NTP server.)\n6. Enter \"exit\" and then \"exit\" again to leave configuration mode.","ccis":["CCI-001967"]},{"vulnId":"V-285646","ruleId":"SV-285646r1273171_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must enforce approved authorizations for controlling the flow of management information and protect against known types of denial-of-service (DoS) attacks by implementing a web-management access list.","description":"DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.\n\nThis requirement addresses the configuration of network devices to mitigate the impact of DoS attacks that have occurred or are ongoing on device availability. For each network device, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or restricting the number of sessions the device opens at one time). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.\n\nThe security safeguards cannot be defined at the DoW level because they vary according to the capabilities of the individual network devices and the security controls applied on the adjacent networks (for example, firewalls performing packet filtering to block DoS attacks).\n\nSatisfies: SRG-APP-000435-NDM-000315, SRG-APP-000038-NDM-000213","checkContent":"Verify a web-management access-list is configured with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config web-management access-list\".\n(Example IPv4: 10.1.0.128/24)\n(Example IPv6: 2001:db8:1::1/128)\n\nIf there is no output, this is a finding.","fixText":"Configure the web-management access-list with approved IP addresses or subnets with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Add approved IPv4 or IPv6 addresses or subnets using CIDR notation by entering \"web-management access-list [IPADDRESS-OR-SUBNET]\".\n(Example IPv4: 10.1.0.128/24)\n(Example IPv6: 2001:db8:1::1/128)\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-002385","CCI-001368"]},{"vulnId":"V-285649","ruleId":"SV-285649r1273142_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured to generate audit records and alert administrators upon detecting potential system or file integrity violations using Intelligent Connection Traffic Monitoring (ICTM) and Hash Reputation.","description":"Without an audit capability, an integrity violation may not be detected. Organizations select response actions based on types of software, specific software, or information for which there are potential integrity violations. The integrity verification application must be configured to perform one or more of following actions: Generates an audit record; alerts current user; alerts organization-defined personnel or roles. The organization may define additional actions to be taken.","checkContent":"Verify ICTM is enabled to generate alerts and Hash Reputation engines are enabled to generate audit records for integrity violations with the following steps:\n\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to Settings >> ICTM.\n3. Verify \"Enable Intelligent Connection Traffic Monitoring (ICTM)\" is checked and configured to send an alert.\n4. Navigate to System >> Licensing.\n5. Under \"Hash Reputation\", verify \"File Reputation\" and \"Custom Whitelist/Blacklist\" are checked.\n\nIf ICTM alerting is disabled, or if the required hash reputation engines are unselected, this is a finding.","fixText":"Configure ICTM alerting and enable Hash Reputation mechanisms to respond to integrity violations with the following steps:\n\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to Settings >> ICTM.\n3. Check the box for \"Enable Intelligent Connection Traffic Monitoring (ICTM)\".\n4. Check the box to \"Send an alert when warning level is reached\", set the level to \"20\" seconds, and click \"Save Changes\".\n5. Navigate to System >> Licensing.\n6. Under \"Hash Reputation\", check the boxes for \"File Reputation\" and \"Custom Whitelist/Blacklist\".\n7. Click \"Save Changes\".","ccis":["CCI-000366"]},{"vulnId":"V-285650","ruleId":"SV-285650r1273143_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must generate audit records for all security-relevant events, including successful and unsuccessful logons, account management actions, privilege usage, and configuration changes.","description":"Without comprehensive audit logging, organizations cannot establish, correlate, and investigate the events relating to a security incident or identify those responsible for unauthorized activities. If the network device fails to log critical security-relevant events—such as administrative logins, account modifications, privilege escalations, and system configuration changes—system administrators (SAs) and information system security officers (ISSOs) will lack the forensic evidence required to detect, analyze, and remediate cyber threats or insider abuses. Configuring the CAS to include all audit information ensures that a complete, DoW-compliant audit trail is generated and captured for all administrative and system-level actions.\n\nSatisfies: SRG-APP-000516-NDM-000334, SRG-APP-000026-NDM-000208, SRG-APP-000027-NDM-000209, SRG-APP-000028-NDM-000210, SRG-APP-000029-NDM-000211, SRG-APP-000091-NDM-000223, SRG-APP-000095-NDM-000225, SRG-APP-000096-NDM-000226, SRG-APP-000097-NDM-000227, SRG-APP-000098-NDM-000228, SRG-APP-000099-NDM-000229, SRG-APP-000100-NDM-000230, SRG-APP-000101-NDM-000231, SRG-APP-000319-NDM-000283, SRG-APP-000343-NDM-000289, SRG-APP-000381-NDM-000305, SRG-APP-000495-NDM-000318, SRG-APP-000499-NDM-000319, SRG-APP-000503-NDM-000320, SRG-APP-000504-NDM-000321, SRG-APP-000505-NDM-000322, SRG-APP-000506-NDM-000323","checkContent":"Verify \"logging include-audit-info\" is set to \"true\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Run the command \"show running-config logging\".\n4. Review the output for the setting \"logging include-audit-info\".\n\nIf the output is \"false\", or the setting is missing, this is a finding.","fixText":"Configure \"logging include-audit-info\" to \"true\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and enter the password.\n3. Enter \"configure terminal\".\n4. Add the command to include all audit logs by entering \"logging include-audit-info true\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-000169","CCI-000366","CCI-000018","CCI-001403","CCI-001404","CCI-001405","CCI-000172","CCI-000130","CCI-000131","CCI-000132","CCI-000133","CCI-000134","CCI-001487","CCI-000135","CCI-002130","CCI-002234","CCI-003938"]},{"vulnId":"V-285651","ruleId":"SV-285651r1274318_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must utilize a centralized authentication server via a secure, encrypted connection to authenticate all administrative users prior to granting access.","description":"Allowing administrators to rely solely on local, device-specific accounts makes it difficult to manage identities and maintain a consistent security posture across the enterprise. In a large DoW environment, managing individual accounts on every network device is labor-intensive and prone to error, such as failing to disable an account when a member leaves the organization. Furthermore, using unencrypted protocols (like plain LDAP) to transmit administrative credentials allows for the interception of passwords via packet sniffing.\n\nTo mitigate these risks, the CAS must be configured to utilize a centralized authentication server (such as Active Directory) via Secure LDAP (LDAPS). This architecture ensures that management access is centrally governed by enterprise security policies and that all authentication traffic is cryptographically protected, satisfying DoW mandates for secure, centralized identity management.\n\nSatisfies: SRG-APP-000516-NDM-000336, SRG-APP-000156-NDM-000250, SRG-APP-000400-NDM-000313, SRG-APP-000820-NDM-000170","checkContent":"Verify the CAS is configured to use Secure LDAP (LDAPS) as the centralized authentication server with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config authentication\".\n4. Verify the centralized authentication mechanism is active by checking for the setting \"authentication ldap enable\".\n5. Verify the connection to the authentication server is encrypted by checking that the URL setting begins with \"ldaps://\".\n\nIf LDAP is not enabled, or if the URL is using unencrypted \"ldap://\" instead of secure \"ldaps://\", this is a finding.","fixText":"Configure the CAS to use LDAPS for centralized administrative authentication with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and enter the password.\n3. Enter \"configure terminal\".\n4. Enable the centralized authentication mechanism by entering \"authentication ldap enable\".\n5. Enforce an encrypted connection to the authentication server by entering \"authentication ldap url ldaps://[Site URL]\". (Replace [Site URL] with the organization's LDAPS server address.)\n6. Enter \"exit\" and then \"exit\" again to leave configuration mode.","ccis":["CCI-000370","CCI-001941","CCI-002007","CCI-004046"]},{"vulnId":"V-285652","ruleId":"SV-285652r1274311_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must obtain its public key certificates from an appropriate certificate policy through an approved service provider.","description":"For user certificates, each organization obtains certificates from an approved, shared service provider, as required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority will suffice.","checkContent":"Verify the web certificate is valid and issued by a DoW Certificate Authority (CA) with the following steps:\n\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Examine the SSL/TLS certificate currently in use via the web browser’s security/lock icon.\n3. Review the \"Subject\", \"Issuer\", and \"Validity\" fields of the certificate.\n\nIf the certificate is not valid, is expired, or was not issued by a DoW CA, this is a finding.","fixText":"Configure a valid DoW-issued certificate for web management with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Download and install the DoW-issued PKCS#12 (.pfx) certificate by entering \"web-management https download-certificate url http://[URL]/[SERVER].pfx password [PASSWORD]\". (Replace [URL] with the address of the host serving the file, [SERVER] with the filename, and [PASSWORD] with the certificate's password.)\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-000366","CCI-001159"]},{"vulnId":"V-285653","ruleId":"SV-285653r1274313_rule","severity":"high","ruleTitle":"The Content Analysis System (CAS) must be configured to send log data to a central log server for the purpose of forwarding alerts to the administrators and the information system security officer (ISSO).","description":"The aggregation of log data kept on a syslog server can be used to detect attacks and trigger an alert to the appropriate security personnel. The stored log data can be used to detect weaknesses in security that enable the network IA team to find and address these weaknesses before breaches can occur. Reviewing these logs, whether before or after a security breach, are important in showing whether someone is an internal employee or an outside threat.\n\nSatisfies: SRG-APP-000516-NDM-000350, SRG-APP-000357-NDM-000293, SRG-APP-000515-NDM-000325","checkContent":"Verify a syslog server is configured with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config alerts\".\n3. Review the output for a configured syslog server under the \"syslog-alerts\" section.\n\nIf there is no configured syslog server, or if the server is not using a secure protocol (e.g., TLS), this is a finding.","fixText":"Configure a syslog server with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and enter the password.\n3. Enter \"configure terminal\".\nNote: Ensure a DNS resolver is configured to allow for FQDN verification of the syslog server certificate.\n4. Configure the DNS name server by entering \"dns name-server [IP ADDRESS]\". (Replace [IP ADDRESS] with the address of your DNS server.)\n5. Import the CA certificate for the syslog server by entering \"ssl inline fips ca-certificate [NAME OF CA] content\". (Replace [NAME OF CA] with a descriptive label for the certificate.)\n6. Paste the certificate content and press \"CTRL + D\" to save. Repeat this for each certificate in the chain.\n7. Add the remote syslog server by entering \"alerts syslog-alerts servers [HOSTNAME] facility default port 6514 protocol TLS\". (Replace [HOSTNAME] with the fully-qualified domain name of the syslog server.)\n8. Ensure all audit logs are included in the output by entering \"logging include-audit-info true\".\n9. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-001851","CCI-001849"]},{"vulnId":"V-285654","ruleId":"SV-285654r1273148_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured to verify, when users create or update passwords, the passwords are not found on the list of commonly used, expected, or compromised passwords in IA-5 (1) (a) for password-based authentication.","description":"Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor authentication. Long passwords or passphrases are preferable over shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish certain rules for password generation (e.g., minimum character length for long passwords) under certain circumstances and can enforce this requirement in IA-5(1)(h). Account recovery can occur, for example, in situations when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, repetitive or sequential characters, and default manufacturer passwords. The list includes context-specific words, such as the name of the service, username, and derivatives thereof.","checkContent":"Verify \"prohibit-common-words\" is set to \"built-in\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config authentication password-policy\".\n3. Review the output for the common words restriction setting.\n\nIf \"prohibit-common-words\" does not display \"built-in\", or the setting is missing, this is a finding.","fixText":"Configure password \"prohibit-common-words\" to \"built-in\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Enforce the built-in dictionary check by entering \"authentication password-policy prohibit-common-words built-in\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-004061"]},{"vulnId":"V-285655","ruleId":"SV-285655r1273149_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured to allow user selection of long passwords and passphrases, including spaces and all printable characters for password-based authentication.","description":"Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor authentication. Long passwords or passphrases are preferable over shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish certain rules for password generation (e.g., minimum character length for long passwords) under certain circumstances and can enforce this requirement in IA-5(1)(h). Account recovery can occur, for example, in situations when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters. The list includes context-specific words, such as the name of the service, username, and derivatives thereof.","checkContent":"Verify \"prohibit-whitespace\" is set to \"false\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"show running-config authentication password-policy\".\n3. Review the output to ensure whitespace is permitted in passwords.\n\nIf \"prohibit-whitespace\" is not set to \"false\", this is a finding.","fixText":"Configure password \"prohibit-whitespace\" to \"false\" with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"configure terminal\".\n4. Allow the use of spaces in passwords by entering \"authentication password-policy prohibit-whitespace false\".\n5. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-004064"]},{"vulnId":"V-285656","ruleId":"SV-285656r1273150_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured to implement certificate revocation checking to support path discovery and validation for public key-based authentication.","description":"Public key cryptography is a valid authentication mechanism for individuals, machines, and devices. For PKI solutions, status information for certification paths includes certificate revocation lists or certificate status protocol responses like OCSP. For PIV cards, certificate validation involves the construction and verification of a certification path to the Common Policy Root trust anchor, which includes certificate policy processing. Implementing a local cache of revocation data to support path discovery and validation also supports system availability in situations where organizations are unable to access revocation information via the network.","checkContent":"Verify the system is configured to perform revocation checking across the certificate path with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show running-config authentication\".\n4. Review the output for the setting: \"certificate-auth full-chain-revocation false\".\n\nIf \"certificate-auth full-chain-revocation\" is not set to \"false\", this is a finding.","fixText":"Configure the system to perform revocation checking across the certificate path with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and enter the password.\n3. Enter \"configure terminal\".\n4. Enter \"authentication certificate-auth full-chain-revocation false\".\n5. Enter \"exit\" and then \"exit\" again to leave configuration mode.","ccis":["CCI-004068"]},{"vulnId":"V-285657","ruleId":"SV-285657r1273151_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured to protect nonlocal maintenance sessions by separating the maintenance session from other network sessions with the system by logically separated communications paths.","description":"Nonlocal maintenance and diagnostic activities are conducted by individuals who communicate through either an external or internal network. Communications paths can be logically separated using encryption.","checkContent":"Verify ICAP secure is enabled on port 11344 and HTTPS administration is enabled on port 8082 with the following steps:\n\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to Settings >> ICAP.\n3. Locate \"Service\" and ensure \"secure\" is selected and configured for port \"11344\".\n4. Navigate to Settings >> Web Management.\n5. Locate \"Web Server\" and ensure \"Enable HTTPS Administration\" is selected and configured for port \"8082\".\n\nIf \"secure\" is not selected for ICAP, if port \"11344\" is not configured, or if \"Enable HTTPS Administration\" is not selected and configured for port \"8082\", this is a finding.","fixText":"Configure ICAP secure on port 11344 and HTTPS administration on port 8082 with the following steps:\n\n1. Log on to the CAS Web Management Console with an administrative account.\n2. Navigate to Settings >> ICAP.\n3. Locate \"Service\", select \"secure\", and enter \"11344\" for the port value.\n4. Click \"Save Changes\".\n5. Navigate to Settings >> Web Management.\n6. Locate \"Web Server\", select \"Enable HTTPS Administration\", and enter \"8082\" for the port value.\n7. Click \"Save Changes\".","ccis":["CCI-004192"]},{"vulnId":"V-285658","ruleId":"SV-285658r1274319_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured to include only approved trust anchors in trust stores or certificate stores managed by the organization.","description":"Public key infrastructure (PKI) certificates are certificates with visibility external to organizational systems and certificates related to the internal operations of systems, such as application-specific time services. In cryptographic systems with a hierarchical structure, a trust anchor is an authoritative source (i.e., a certificate authority [CA]) for which trust is assumed and not derived. A root certificate for a PKI system is an example of a trust anchor. A trust store or certificate store maintains a list of trusted root certificates.","checkContent":"Verify the \"browser-trusted-fips\" CCL contains only valid and required DoW CAs with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and enter the password.\n3. Enter \"ssl view ccl browser-trusted-fips\".\n4. Evaluate the output for the listed CAs.\n\nIf the list does not contain valid and required DoW CAs, or if the list contains any CAs that are not documented with the information system security manager (ISSM), this is a finding.","fixText":"Configure the \"browser-trusted-fips\" CCL to contain only approved DoW CA certificates with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\", and then enter the password.\n3. Enter \"configure terminal\".\n4. Import the required DoW CA certificate by entering \"ssl inline fips ca-certificate [CANAME]\" (replace [CANAME] with a descriptive name for the CA being imported) and press \"Enter\".\n5. Copy and paste the base64 PEM data into the window, then press \"Enter\" and \"CTRL + D\". \n(Repeat steps 4 and 5 for all required DoW CA certificates.)\n6. Add the newly imported CA to the CCL by entering \"ssl edit ccl browser-trusted-fips add [CANAME]\". (Replace [CANAME] with the name of the CA that was previously imported.)\n(Repeat this step for all required DoW CA certificates.)\n7. Verify the import succeeded in the CCL by entering \"ssl view ccl browser-trusted-fips\".\n\nRemove any unauthorized or commercial CAs with the following steps:\n\n1. While still in configuration mode, type \"ssl edit ccl browser-trusted-fips remove [CANAME]\". (Replace [CANAME] with the name of the unapproved CA identified during verification.)\n(Repeat this step for any unauthorized CAs.)\n2. Enter \"exit\" to return to the config context, and then enter \"exit\" again to leave configuration mode.","ccis":["CCI-004909"]},{"vulnId":"V-285659","ruleId":"SV-285659r1274317_rule","severity":"medium","ruleTitle":"The Content Analysis System (CAS) must be configured to synchronize system clocks within and between systems.","description":"The loss of connectivity to a particular authoritative time source will result in the loss of time synchronization (free-run mode) and increasingly inaccurate time stamps on audit events and other functions. \n\nMultiple time sources provide redundancy by including a secondary source. Time synchronization is usually a hierarchy; clients synchronize time to a local source while that source synchronizes time to a more accurate source. The network device must use an authoritative time server and/or be configured to use redundant authoritative time sources. This requirement is related to the comparison done in CCI-001891.\n\nDoW-approved solutions consist of a combination of a primary and secondary time source using a combination or multiple instances of the following: a time server designated for the appropriate DoW network (NIPRNet/SIPRNet); United States Naval Observatory (USNO) time servers; and/or the Global Positioning System (GPS). The secondary time source must be located in a different geographic region than the primary time source.\n\nSatisfies: SRG-APP-000920-NDM-000320, SRG-APP-000925-NDM-000330","checkContent":"Verify NTP is enabled and syncing with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\" and provide the password.\n3. Enter \"show clock\".\n4. Review the output for the NTP status.\n\nIf the line for NTP does not state \"Enabled, syncing\", or if NTP is not configured with a symmetric key, this is a finding.","fixText":"Configure NTP to be enabled and synchronize the system clock with the following steps:\n\n1. Log on to the SSH CLI with an administrative account.\n2. Enter \"enable\", enter the password, and then enter \"configure terminal\".\n3. Enable the NTP service by entering \"ntp enable\".\n4. Add the authoritative time sources by entering: \n\"ntp server [FIRSTNTPSERVER]\"\n\"ntp server [SECONDNTPSERVER]\"\n(Replace the bracketed text with the IP addresses or hostnames of primary and secondary NTP servers.)\n5. Force an immediate time synchronization by entering \"ntp update-now\".\n6. Enter \"exit\" and then \"exit\" again to leave configuration mode.","ccis":["CCI-004922","CCI-004923"]}]}