{
"stig": {
"date": "2022-09-12",
"description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.",
"findings": {
"V-239852": {
"checkid": "C-43085r665840_chk",
"checktext": "Review the ASA configuration to determine if it only permits outbound traffic using authorized ports and services.\n\nStep 1: Verify that an ingress ACL has been applied to all internal interfaces as shown in the example below.\n\n interface GigabitEthernet0/0\n nameif INSIDE\n security-level 100\n ip address 10.1.11.1 255.255.255.0\n\u2026\n\u2026\n\u2026\naccess-group INSIDE _IN in interface INSIDE \n\nStep 2: Verify that the ingress ACL only allows outbound traffic using authorized ports and services as shown in the example below.\n\naccess-list INSIDE _IN extended permit tcp any any eq www \naccess-list INSIDE _IN extended permit tcp any any eq https \naccess-list INSIDE _IN extended permit tcp any any eq \u2026\naccess-list INSIDE _IN extended deny ip any any log\n\nIf the ASA is not configured to only allow outbound traffic using authorized ports and services, this is a finding.",
"description": "Information flow control regulates where information is allowed to travel within a network and between interconnected networks. Blocking or restricting detected harmful or suspicious communications between interconnected networks enforces approved authorizations for controlling the flow of traffic.\n\nThe firewall that filters traffic outbound to interconnected networks with different security policies must be configured to permit or block traffic based on organization-defined traffic authorizations.",
"fixid": "F-43044r665841_fix",
"fixtext": "Step 1: Configure the ingress ACL similar to the example below.\n\nASA(config)# access-list INSIDE_INextended permit tcp any any eq https\nASA(config)# access-list INSIDE_INextended permit tcp any any eq http\nASA(config)# access-list INSIDE_INextended permit tcp any any eq \u2026\nASA(config)# access-list INSIDE_INextended deny ip any any log \n\nStep 2: Apply the ACL inbound on all internal interfaces as shown in the example below.\n\nASA(config)# access-group INSIDE_IN in interface INSIDE\nASA(config)# end",
"iacontrols": null,
"id": "V-239852",
"ruleID": "SV-239852r665842_rule",
"severity": "high",
"title": "The Cisco ASA must be configured to filter outbound traffic, allowing only authorized ports and services.",
"version": "CASA-FW-000010"
},
"V-239853": {
"checkid": "C-43086r665843_chk",
"checktext": "By default, when you change a rule-based policy such as access rules, the changes become effective immediately. With transactional model configured, the rules are not active until after compilation.\n\nReview the ASA configuration and verify that the following command is not configured.\n\nasp rule-engine transactional-commit access-group\n\nIf transactional-commit access-group has been configured, this is a finding.",
"description": "Information flow policies regarding dynamic information flow control include, for example, allowing or disallowing information flows based on changes to the Ports, Protocols, Services Management (PPSM) Category Assurance Levels (CAL) list, vulnerability assessments, or mission conditions. Changing conditions include changes in the threat environment and detection of potentially harmful or adverse events.",
"fixid": "F-43045r665844_fix",
"fixtext": "Remove the command asp rule-engine transactional-commit access-group\n\nASA(config)# no asp rule-engine transactional-commit access-group",
"iacontrols": null,
"id": "V-239853",
"ruleID": "SV-239853r665845_rule",
"severity": "medium",
"title": "The Cisco ASA must immediately use updates made to policy enforcement mechanisms such as firewall rules, security policies, and security zones.",
"version": "CASA-FW-000020"
},
"V-239854": {
"checkid": "C-43087r665846_chk",
"checktext": "Step 1: Verify that an ACL has been applied to the applicable VPN group policy via the vpn-filter attribute as shown in the example below.\n\ngroup-policy VPN_POLICY internal\ngroup-policy VPN_POLICY attributes\n \u2026\n \u2026\n \u2026\n vpn-filter value RESTRICT_VPN\n\nStep 2: Verify that the filter restricts traffic according to organization-defined filtering rules as shown in the example below.\n\naccess-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255.0 host 192.168.1.12 eq http \naccess-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255.0 host 192.168.1.13 eq smtp \naccess-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255.0 host 192.168.1.14 eq ftp \naccess-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255.0 host 192.168.1.14 eq ftp-data \naccess-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255.0 host 192.168.1.15 eq domain\naccess-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255.0 host 192.168.1.16 eq sqlnet\naccess-list RESTRICT_VPN extended deny ip any any log\n\nNote: In the example above, assume that the client-assigned IP address pool is 10.10.10.0/24 and the local private network is 192.168.1.0/24.\n\nIf the ASA is not configured to restrict VPN traffic according to organization-defined filtering rules, this is a finding.",
"description": "Remote access devices (such as those providing remote access to network devices and information systems) that lack automated capabilities increase risk and make remote user access management difficult at best.\n\nRemote access is access to DoD non-public information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network.\n\nAutomated monitoring of remote access sessions allows organizations to detect cyberattacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities from a variety of information system components (e.g., servers, workstations, notebook computers, smart phones, and tablets).",
"fixid": "F-43046r665847_fix",
"fixtext": "Step 1: Configure the ACL to restrict VPN traffic.\n\nASA(config)# access-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255. host 192.168.1.12 eq http\nASA(config)# access-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255. host 192.168.1.13 eq smtp\nASA(config)# access-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255. host 192.168.1.14 eq ftp\nASA(config)# access-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255. host 192.168.1.14 eq ftp-data\nASA(config)# access-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255.y host 192.168.1.15 eq domain\nASA(config)# access-list RESTRICT_VPN extended permit tcp 10.0.0.0 255.255.255. host 192.168.1.16 eq sqlnet\nASA(config)# access-list RESTRICT_VPN extended deny ip any any log\nASA(config)# exit \n\nStep 2: Apply the VPN filter to the applicable group policy as shown in the example below.\n\nASA(config)# group-policy VPN_POLICY attributes \nASA(config-group-policy)# vpn-filter value RESTRICT_VPN \nASA(config-group-policy)# end",
"iacontrols": null,
"id": "V-239854",
"ruleID": "SV-239854r665848_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to restrict VPN traffic according to organization-defined filtering rules.",
"version": "CASA-FW-000030"
},
"V-239855": {
"checkid": "C-43088r665849_chk",
"checktext": "Review the ASA configuration to determine if it is compliant with the requirement.\n\nStep 1: Verify that all ACL deny statements have the log parameter defined as shown in the example below.\n\naccess-list OUTSIDE_OUT extended deny ip any any log\n\nStep 2: Verify logging is enabled.\n\nlogging enable\n\nIf the ASA is not configured to generate traffic log entries containing information to establish what type of events occurred, this is a finding.",
"description": "Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack.\n\nAudit event content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.\n\nAssociating event types with detected events in the network element logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element.",
"fixid": "F-43047r665850_fix",
"fixtext": "Configure the ASA to generate traffic log entries containing information to establish what type of events occurred as shown in the example below.\n\nStep 1: Enable logging.\n\nASA(config)# logging enable\n\nStep 2: Include the log parameter on all deny ACL statements.\n\nASA(config)# access-list OUTSIDE_OUT extended deny ip any any log",
"iacontrols": null,
"id": "V-239855",
"ruleID": "SV-239855r665851_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to generate traffic log entries containing information to establish what type of events occurred.",
"version": "CASA-FW-000040"
},
"V-239856": {
"checkid": "C-43089r665852_chk",
"checktext": "Verify that the logging timestamp command has been configured as shown below.\n\nlogging enable\nlogging timestamp\n\nIf the ASA is not configured to generate traffic log entries containing information to establish when the events occurred, this is a finding.",
"description": "Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nIn order to compile an accurate risk assessment, and provide forensic analysis of network traffic patterns, it is essential for security personnel to know when flow control events occurred (date and time) within the infrastructure.\n\nAssociating event types with detected events in the network traffic logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element.",
"fixid": "F-43048r665853_fix",
"fixtext": "Configure the ASA to generate traffic log entries containing information to establish when the events occurred.\n\nASA(config)# logging timestamp",
"iacontrols": null,
"id": "V-239856",
"ruleID": "SV-239856r665854_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to generate traffic log entries containing information to establish when (date and time) the events occurred.",
"version": "CASA-FW-000050"
},
"V-239857": {
"checkid": "C-43090r665855_chk",
"checktext": "Review the ASA configuration and verify that logging to the buffer is enabled and that the queue size has been increased as shown in the example below.\n\nlogging enable\nlogging buffered informational\nlogging queue 8192\nlogging host NDM_INTERFACE 10.1.22.2 6/1514\n\nNote: Configuring a value of 0 for the queue size will set it to maximum size for the specific platform.\n\nIf the ASA is not configured to queue log records locally In the event that the central audit server is down or not reachable, this is a finding.",
"description": "It is critical that when the network element is at risk of failing to process traffic logs as required, it takes action to mitigate the failure. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend on the nature of the failure mode.\n\nIn accordance with DoD policy, the traffic log must be sent to a central audit server. When logging functions are lost, system processing cannot be shut down because firewall availability is an overriding concern given the role of the firewall in the enterprise. The system should either be configured to log events to an alternative server or queue log records locally. Upon restoration of the connection to the central audit server, action should be taken to synchronize the local log data with the central audit server.\n\nIf the central audit server uses User Datagram Protocol (UDP) communications instead of a connection oriented protocol such as TCP, a method for detecting a lost connection must be implemented.",
"fixid": "F-43049r665856_fix",
"fixtext": "To continue to allow new connections and queue log records in the event the syslog server is not reachable, configure logging buffered and increase the queue size as shown in the example below.\n\nASA(config)# logging buffered informational\nASA(config)# logging queue 8192",
"iacontrols": null,
"id": "V-239857",
"ruleID": "SV-239857r665857_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to queue log records locally in the event that the central audit server is down or not reachable.",
"version": "CASA-FW-000090"
},
"V-239858": {
"checkid": "C-43091r819135_chk",
"checktext": "Review the ASA configuration and verify it is configured to use TCP as shown in the example below.\n\nlogging host NDM_INTERFACE 10.1.22.2 6/1514\nlogging permit-hostdown\n\nNote: The command \"logging permit-hostdown\" must also be configured to ensure that when either the syslog server is down or the log queue is full, new connections to ASA are allowed, to prevent an unintended denial of service. However, log records can be lost if the internal queue fills before restoring the connection to the log server.\n\nIf the ASA is not configured to use TCP when sending log records to the central audit server, this is a finding.",
"description": "If the default UDP protocol is used for communication between the hosts and devices to the Central Log Server, then log records that do not reach the log server are not detected as a data loss. The use of TCP to transport log records to the log servers improves delivery reliability.",
"fixid": "F-43050r665859_fix",
"fixtext": "Configure the ASA to use TCP when sending log records to the syslog server.\n\nASA(config)# logging host NDM_INTERFACE 10.1.22.2 6/1514\nASA(config)# logging permit-hostdown",
"iacontrols": null,
"id": "V-239858",
"ruleID": "SV-239858r819136_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to use TCP when sending log records to the central audit server.",
"version": "CASA-FW-000100"
},
"V-239859": {
"checkid": "C-43092r665861_chk",
"checktext": "Features such as telnet should never be enabled, while other features should only be enabled if required for operations. In the example below, http and telnet service is enabled.\n\nhttp server enable\n\u2026\n\u2026\n\u2026\ntelnet 10.1.22.2 255.255.255.255 INSIDE\n\nNote: The command http server actually enables https and is required for ASDM.\n\nIf any unnecessary or non-secure ports, protocols, or services are enabled, this is a finding.",
"description": "Network devices are capable of providing a wide variety of functions (capabilities or processes) and services. Some of these functions and services are installed and enabled by default. The organization must determine which functions and services are required to perform the content filtering and other necessary core functionality for each component of the firewall. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.\n\nSome services may be security related but, based on the firewall\u2019s role in the architecture, must not be installed on the same hardware. For example, the device may serve as a router, VPN, or other perimeter services. However, if these functions are not part of the documented role of the firewall in the enterprise or branch architecture, the software and licenses should not be installed on the device. This mitigates the risk of exploitation of unconfigured services or services that are not kept updated with security fixes. If left unsecured, these services may provide a threat vector.\n\nSome services are not authorized for combination with the firewall and individual policy must be in place to instruct the administrator to remove these services. Examples of these services are Network Time Protocol (NTP), domain name server (DNS), email server, FTP server, web server, and Dynamic Host Configuration Protocol (DHCP). \n\nOnly remove unauthorized services. This control is not intended to restrict the use of firewalls with multiple authorized roles.",
"fixid": "F-43051r665862_fix",
"fixtext": "Disable features that should not be enabled unless required for operations.\n\nASA(config)# no http server enable\nASA(config)# no telnet 10.1.22.2 255.255.255.255 INSIDE\nASA(config)# end\n\nNote: Telnet must always be disabled.",
"iacontrols": null,
"id": "V-239859",
"ruleID": "SV-239859r665863_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to disable or remove unnecessary network services and functions that are not used as part of its role in the architecture.",
"version": "CASA-FW-000130"
},
"V-239860": {
"checkid": "C-43093r863228_chk",
"checktext": "NOTE: When operating the ASA in multi-context mode with a separate IDPS, threat detection cannot be enabled, and this check is Not Applicable.\n\nReview the ASA configuration to determine if threat detection has been enabled.\n\nthreat-detection basic-threat\n\nIf the ASA has not been configured to enable threat detection to mitigate risks of DoS attacks, this is a finding.",
"description": "A firewall experiencing a DoS attack will not be able to handle production traffic load. The high utilization and CPU caused by a DoS attack will also have an effect on control keep-alives and timers used for neighbor peering, resulting in route flapping and will eventually black-hole production traffic.\n\nThe device must be configured to contain and limit a DoS attack's effect on the device's resource utilization. The use of redundant components and load balancing are examples of mitigating \"flood-type\" DoS attacks through increased capacity.",
"fixid": "F-43052r665865_fix",
"fixtext": "Configure threat detection as shown in the example below.\n\nASA(config)# threat-detection basic-threat",
"iacontrols": null,
"id": "V-239860",
"ruleID": "SV-239860r863229_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to enable threat detection to mitigate risks of denial-of-service (DoS) attacks.",
"version": "CASA-FW-000150"
},
"V-239861": {
"checkid": "C-43094r665867_chk",
"checktext": "Review the inbound ACL to verify the ports and services allowed are in accordance with the PPSM CAL.\n\nReview the ASA configuration to determine if it only permits inbound traffic using authorized ports and services.\n\nStep 1: Verify that an ingress ACL has been applied to the external interface as shown in the example below.\n\n interface GigabitEthernet0/0\n nameif OUTSIDE\n security-level 0\n ip address x.1.11.1 255.255.255.0\n\u2026\n\u2026\n\u2026\naccess-group OUTSIDE_IN in interface OUTSIDE\n\nStep 2: Verify that the ingress ACL only allows inbound traffic in accordance with the PPSM CAL as shown in the example below.\n\naccess-list OUTSIDE_IN extended permit tcp any any eq www \naccess-list OUTSIDE_IN extended permit tcp any any eq https \naccess-list OUTSIDE_IN extended permit tcp any any eq domain \naccess-list OUTSIDE_IN extended permit tcp any any eq ftp \naccess-list OUTSIDE_IN extended permit tcp any any eq ftp-data \naccess-list OUTSIDE_IN extended permit udp any any eq sip \naccess-list OUTSIDE_IN extended deny ip any any log\n\nIf the ASA is not configured to only allow inbound traffic in accordance with the PPSM CAL, this is a finding.",
"description": "The enclave's internal network contains the servers where mission-critical data and applications reside. Malicious traffic can enter from an external boundary or originate from a compromised host internally.\n\nVulnerability assessments must be reviewed by the SA and protocols must be approved by the IA staff before entering the enclave. \n\nFirewall filters (e.g., rules, access control lists [ACLs], screens, and policies) are the first line of defense in a layered security approach. They permit authorized packets and deny unauthorized packets based on port or service type. They enhance the posture of the network by not allowing packets to even reach a potential target within the security domain. The filters provided are highly susceptible ports and services that should be blocked or limited as much as possible without adversely affecting customer requirements. Auditing packets attempting to penetrate the network but stopped by the firewall filters will allow network administrators to broaden their protective ring and more tightly define the scope of operation. \n\nIf the perimeter is in a Deny-by-Default posture and what is allowed through the filter is in accordance with the PPSM CAL and VAs for the enclave, and if the permit rule is explicitly defined with explicit ports and protocols allowed, then all requirements related to the database being blocked would be satisfied.",
"fixid": "F-43053r665868_fix",
"fixtext": "Step 1: Configure the ingress ACL similar to the example below.\n\nASA(config)# access-list OUTSIDE_IN extended permit tcp any any eq https\nASA(config)# access-list OUTSIDE_IN extended permit tcp any any eq http\nASA(config)# access-list OUTSIDE_IN extended permit tcp any any eq domain\nASA(config)# access-list OUTSIDE_IN extended permit tcp any any eq ftp \nASA(config)# access-list OUTSIDE_IN extended permit tcp any any eq ftp-data\nASA(config)# access-list OUTSIDE_IN extended permit udp any any eq sip\nASA(config)# access-list OUTSIDE_IN extended deny ip any any log \n\nStep 2: Apply the ACL inbound on the external interface as shown in the example below.\n\nASA(config)# access-group OUTSIDE_IN in interface OUTSIDE \nASA(config)# end",
"iacontrols": null,
"id": "V-239861",
"ruleID": "SV-239861r665904_rule",
"severity": "medium",
"title": "The Cisco ASA perimeter firewall must be configured to filter traffic destined to the enclave in accordance with the specific traffic that is approved and registered in the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL) and vulnerability assessments.",
"version": "CASA-FW-000170"
},
"V-239862": {
"checkid": "C-43095r665870_chk",
"checktext": "Verify that the ASA is configured to send logs to a syslog server. The configuration should look similar to the example below.\n\nlogging trap notifications\nlogging host NDM_INTERFACE 10.1.48.10/1514\n\nIf the ASA is not configured to send log data to the syslog server, this is a finding.",
"description": "Without the ability to centrally manage the content captured in the traffic log entries, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack.\n\nThe DoD requires centralized management of all network component audit record content. Network components requiring centralized traffic log management must have the ability to support centralized management. The content captured in traffic log entries must be managed from a central location (necessitating automation). Centralized management of traffic log records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. \n\nEnsure at least one syslog server is configured on the firewall.",
"fixid": "F-43054r665871_fix",
"fixtext": "Configure the ASA to send log messages to the syslog server as shown in the example below.\n\nASA(config)# logging host NDM_INTERFACE 10.1.48.10/1514\nASA(config)# logging trap notifications \nASA(config)# end",
"iacontrols": null,
"id": "V-239862",
"ruleID": "SV-239862r863248_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to send log data of denied traffic to a central audit server for analysis.",
"version": "CASA-FW-000200"
},
"V-239863": {
"checkid": "C-43096r665873_chk",
"checktext": "Review the ASA configuration to determine if it will send an email alert to organization-defined personnel and/or the firewall administrator if communication with the central audit server is lost as shown in the example below.\n\nlogging enable\nlogging host NDM_INTERFACE 10.1.22.2 6/1514\nlogging permit-hostdown\nlogging mail errors\nlogging from-address firewall@mail.mil\nlogging recipient-address OurFWadmin@mail.mil level errors\nlogging recipient-address OurISSO@mail.mil level errors\n\u2026\n\u2026\n\u2026\nsmtp-server 10.1.12.33\n\nNote: Severity level must be set at 3 (errors) or higher as the following message is seen when an ASA loses communication with the syslog server: %ASA-3-201008 or %ASA-3-414003: Disallowing new connections.\n\nIf the ASA is not configured to generate a real-time alert to organization-defined personnel and/or the firewall administrator if communication with the central audit server is lost, this is a finding.",
"description": "Without a real-time alert (less than a second), security personnel may be unaware of an impending failure of the audit functions and system operation may be adversely impacted. Alerts provide organizations with urgent messages. Automated alerts can be conveyed in a variety of ways, including via a regularly monitored console, telephonically, via electronic mail, via text message, or via websites.\n\nLog processing failures include software/hardware errors, failures in the log capturing mechanisms, and log storage capacity being reached or exceeded. Most firewalls use UDP to send audit records to the server and cannot tell if the server has received the transmission, thus the site should either implement a connection-oriented communications solution (e.g., TCP) or implement a heartbeat with the central audit server and send an alert if it is unreachable. The ISSM or ISSO may designate the firewall/system administrator or other authorized personnel to receive the alert within the specified time, validate the alert, and then forward only validated alerts to the ISSM and ISSO.",
"fixid": "F-43055r665874_fix",
"fixtext": "Configure the ASA to send an email alert to the organization-defined personnel and/or firewall administrator for syslog messages at severity level 3.\n\nASA(config)# logging mail 3 \nASA(config)# logging recipient-address OurFWadmin@mail.mil\nASA(config)# logging recipient-address OurISSO@mail.mil\nASA(config)# logging from-address firewall@mail.mil\nASA(config)# smtp-server 10.1.12.33\nASA(config)# end",
"iacontrols": null,
"id": "V-239863",
"ruleID": "SV-239863r855805_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to generate a real-time alert to organization-defined personnel and/or the firewall administrator in the event communication with the central audit server is lost.",
"version": "CASA-FW-000210"
},
"V-239864": {
"checkid": "C-43097r863230_chk",
"checktext": "NOTE: When operating the ASA in multi-context mode with a separate IDPS, threat detection cannot be enabled, and this check is Not Applicable.\n\nReview the ASA configuration to determine if scanning threat detection has been enabled.\n\nthreat-detection scanning-threat shun\n\nNOTE: The parameter 'shun' is an optional parameter, and not required, but can offer additional protection by dropping further connections from the threat.\n\nIf the ASA has not been configured to enable scanning threat detection, this is a finding.",
"description": "In a port scanning attack, an unauthorized application is used to scan the host devices for available services and open ports for subsequent use in an attack. This type of scanning can be used as a DoS attack when the probing packets are sent excessively.",
"fixid": "F-43056r665877_fix",
"fixtext": "Configure scanning threat detection as shown in the example below.\n\nASA(config)# threat-detection scanning-threat shun",
"iacontrols": null,
"id": "V-239864",
"ruleID": "SV-239864r863231_rule",
"severity": "high",
"title": "The Cisco ASA must be configured to implement scanning threat detection.",
"version": "CASA-FW-000220"
},
"V-239865": {
"checkid": "C-43098r665879_chk",
"checktext": "Review the ASA configuration to verify that it is filtering inbound traffic on all external interfaces.\n\naccess-list OUTSIDE_2_DMZ extended permit tcp any host 10.1.33.2 eq www \naccess-list OUTSIDE_2_DMZ extended permit tcp any host 10.1.33.2 eq https \naccess-list OUTSIDE_2_DMZ extended permit tcp any host 10.1.33.3 eq ftp \naccess-list OUTSIDE_2_DMZ extended permit tcp any host 10.1.33.3 eq ftp-data \naccess-list OUTSIDE_2_DMZ extended deny ip any any log\n\u2026\n\u2026\n\u2026\naccess-group OUTSIDE_2_DMZ in interface OUTSIDE\n\nIf the ASA is not configured to filter inbound traffic on all external interfaces, this is a finding.",
"description": "Unrestricted traffic to the trusted networks may contain malicious traffic that poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources.\n\nFirewall filters control the flow of network traffic, ensure the flow of traffic is only allowed from authorized sources to authorized destinations. Networks with different levels of trust (e.g., the Internet) must be kept separated.",
"fixid": "F-43057r665880_fix",
"fixtext": "Step 1: Configure the ACL to allow specific inbound traffic.\n\nASA(config)# access-list OUTSIDE_2_DMZ extended permit tcp any host 10.1.33.2 eq www \nASA(config)# access-list OUTSIDE_2_DMZ extended permit tcp any host 10.1.33.2 eq https \nASA(config)# access-list OUTSIDE_2_DMZ extended permit tcp any host 10.1.33.3 eq ftp \nASA(config)# access-list OUTSIDE_2_DMZ extended permit tcp any host 10.1.33.3 eq ftp-data \nASA(config)# access-list OUTSIDE_2_DMZ extended deny ip any any log\n\nStep 2: Apply the ACL inbound to the external interface.\n\nASA(config)# access-group OUTSIDE_2_DMZ in interface OUTSIDE",
"iacontrols": null,
"id": "V-239865",
"ruleID": "SV-239865r855807_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to filter inbound traffic on all external interfaces.",
"version": "CASA-FW-000230"
},
"V-239866": {
"checkid": "C-43099r665882_chk",
"checktext": "Step 1: Verify that an ingress ACL has been applied to the internal interface as shown in the example below.\n\n interface GigabitEthernet0/3\n nameif INSIDE\n security-level 100\n ip address 10.1.11.1 255.255.255.0\n\u2026\n\u2026\n\u2026\naccess-group INSIDE_2_OUT in interface INSIDE\n\nStep 2: Verify that the ACL only allows outbound traffic using authorized ports and services as shown in the example below.\n\naccess-list INSIDE_2_OUT extended permit tcp any any eq www \naccess-list INSIDE_2_OUT extended permit tcp any any eq https \naccess-list INSIDE_2_OUT extended permit tcp any any eq domain \naccess-list INSIDE_2_OUT extended permit tcp any any eq ftp \naccess-list INSIDE_2_OUT extended permit tcp any any eq ftp-data \naccess-list INSIDE_2_OUT extended permit tcp any host 10.1.22.3 eq ssh\naccess-list INSIDE_2_OUT extended deny ip any any log\n\nIf the ASA is not configured to filter outbound traffic on all internal interfaces, this is a finding.",
"description": "If outbound communications traffic is not filtered, hostile activity intended to harm other networks or packets from networks destined to unauthorized networks may not be detected and prevented.\n\nAccess control policies and access control lists implemented on devices, such as firewalls, that control the flow of network traffic ensure the flow of traffic is only allowed from authorized sources to authorized destinations. Networks with different levels of trust (e.g., the Internet) must be kept separated.\n\nThis requirement addresses the binding of the egress filter to the interface/zone rather than the content of the egress filter.",
"fixid": "F-43058r665883_fix",
"fixtext": "Step 1: Configure the egress ACL similar to the example below.\n\nASA(config)# access-list INSIDE_2_OUT extended permit tcp any any eq https\nASA(config)# access-list INSIDE_2_OUT extended permit tcp any any eq http\nASA(config)# access-list INSIDE_2_OUT extended permit tcp any any eq domain\nASA(config)# access-list INSIDE_2_OUT extended permit tcp any any eq ftp \nASA(config)# access-list INSIDE_2_OUT extended permit tcp any any eq ftp-data\nASA(config)# access-list INSIDE_2_OUT extended permit tcp any host 10.1.22.3 eq ssh\nASA(config)# access-list INSIDE_2_OUT extended deny ip any any log \n\nStep 2: Apply the ACL inbound on the internal interfaces as shown in the example below.\n\nASA(config)# access-group INSIDE_2_OUT in interface INSIDE \nASA(config)# end",
"iacontrols": null,
"id": "V-239866",
"ruleID": "SV-239866r855808_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to filter outbound traffic on all internal interfaces.",
"version": "CASA-FW-000240"
},
"V-239867": {
"checkid": "C-43100r665885_chk",
"checktext": "Review the ASA configuration to determine if it blocks outbound management traffic.\n\nStep 1: Verify that an ingress ACL has been applied to all internal interfaces as shown in the example below.\n\n interface GigabitEthernet0/0\n nameif INSIDE\n security-level 100\n ip address x.1.11.1 255.255.255.0\n\u2026\n\u2026\n\u2026\naccess-group INSIDE_IN out interface INSIDE\n\nStep 2: Verify that the ingress ACL blocks outbound management traffic as shown in the example below.\n\naccess-list INSIDE_IN extended deny udp any any eq snmp \naccess-list INSIDE_IN extended deny udp any any eq snmptrap\naccess-list INSIDE_IN extended deny udp any any eq ntp \naccess-list INSIDE_IN extended deny udp any any eq syslog\naccess-list INSIDE_IN extended deny tcp any any eq 22 \naccess-list INSIDE_IN extended deny tcp any any eq tacacs\naccess-list INSIDE_IN extended permit ip any any \n\nNote: An exception would be allowing management traffic destined to perimeter devices. In those cases, configure permit statements for that traffic before the deny statements in the example above.\n\nIf the ASA is not configured to block outbound management traffic, this is a finding.",
"description": "The management network must still have its own subnet in order to enforce control and access boundaries provided by Layer 3 network nodes such as routers and firewalls. Management traffic between the managed network elements and the management network is routed via the same links and nodes as that used for production or operational traffic. \n\nSafeguards must be implemented to ensure that the management traffic does not leak past the managed network's premise equipment. If a firewall is located behind the premise router, all management traffic must be blocked at that point, with the exception of management traffic destined to premise equipment.",
"fixid": "F-43059r665886_fix",
"fixtext": "Step 1: Configure the ingress ACL similar to the example below.\n\nASA(config)# access-list INSIDE_IN extended deny udp any any eq snmp \nASA(config)# access-list INSIDE_IN extended deny udp any any eq snmptrap\nASA(config)# access-list INSIDE_IN extended deny udp any any eq ntp \nASA(config)# access-list INSIDE_IN extended deny udp any any eq syslog\nASA(config)# access-list INSIDE_IN extended deny tcp any any eq 22 \nASA(config)# access-list INSIDE_IN extended deny tcp any any eq tacacs\nASA(config)# access-list INSIDE_IN extended permit ip any any \n\nStep 2: Apply the ACL inbound on the einternal interfaces as shown in the example below.\n\nASA(config)# access-group INSIDE_IN out interface INSIDE \nASA(config)# end",
"iacontrols": null,
"id": "V-239867",
"ruleID": "SV-239867r855809_rule",
"severity": "medium",
"title": "The Cisco ASA perimeter firewall must be configured to block all outbound management traffic.",
"version": "CASA-FW-000250"
},
"V-239868": {
"checkid": "C-43101r665888_chk",
"checktext": "Step 1: Verify that an IPsec crypto map has been configured and bound to the outside interface as shown in the example below.\n\ncrypto ipsec ikev1 transform-set IPSEC_TRANSFORM esp-aes-192 esp-sha-hmac \ncrypto map IPSEC_CRYPTO_MAP 1 match address MANAGEMENT_TRAFFIC\ncrypto map IPSEC_CRYPTO_MAP 1 set peer 10.3.1.1 \ncrypto map IPSEC_CRYPTO_MAP 1 set ikev1 transform-set IPSEC_TRANSFORM\ncrypto map IPSEC_CRYPTO_MAP 1 set security-association lifetime seconds 3600\ncrypto map IPSEC_CRYPTO_MAP interface OUTSIDE\n\nStep 2: Verify the there is a tunnel group configured for the peer defined in the crypto map as shown in the example below.\n\ntunnel-group 10.3.1.1 type ipsec-l2l\ntunnel-group 10.3.1.1 ipsec-attributes\n ikev1 pre-shared-key *****\n\nStep 3: Verify that an ISAKMP policy for IKE connections has been configured and bound to the outside interface as shown in the example.\n\ncrypto isakmp identity address \ncrypto ikev1 enable OUTSIDE\ncrypto ikev1 policy 10\n authentication pre-share\n encryption aes-256\n hash sha\n group 5\n lifetime 3600\n\nStep 4: Verify that the ACL referenced in the IPsec crypto map includes all applicable management traffic.\n\naccess-list MANAGEMENT_TRAFFIC extended permit udp any eq snmp 10.2.2.0 255.255.255.0 \naccess-list MANAGEMENT_TRAFFIC extended permit udp any eq 10.2.2.0 255.255.255.0 snmptrap\naccess-list MANAGEMENT_TRAFFIC extended permit udp any eq syslog 10.2.2.0 255.255.255.0 \naccess-list MANAGEMENT_TRAFFIC extended permit tcp any eq ssh 10.2.2.0 255.255.255.0 \n\nNote: Exception would be allowed for management traffic to and from managed perimeter devices.\n\nIf the ASA is not configured to forward management traffic to the Network Operations Center (NOC) via an IPsec tunnel, this is a finding.",
"description": "When the production network is managed in-band, the management network could be housed at a NOC that is located remotely at single or multiple interconnected sites. NOC interconnectivity, as well as connectivity between the NOC and the managed network, must be enabled using IPsec tunnels to provide the separation and integrity of the managed traffic.",
"fixid": "F-43060r665889_fix",
"fixtext": "Step 1: Configure an ISAKMP policy for IKE connection as shown in the example.\n\nASA1(config)# crypto ikev1 policy 10\nASA1(config-ikev1-policy)# authentication pre-share\nASA1(config-ikev1-policy)# encryption aes-256\nASA1(config-ikev1-policy)# hash sha\nASA1(config-ikev1-policy)# group 5\nASA1(config-ikev1-policy)# lifetime 3600\nASA1(config-ikev1-policy)# exit\n\nStep 2: Enable the IKEv1 policy on the outside interface and identify itself with its IP address.\n\nASA1(config)# crypto ikev1 enable OUTSIDE\nASA1(config)# crypto isakmp identity address\n\nStep 3: Configure the tunnel group as shown in the example below.\n\nASA2(config)# tunnel-group 10.10.10.1 ipsec-attributes\nASA2(config-tunnel-ipsec)# ikev1 pre-shared-key xxxxxxxxxxxxx \n\nStep 4: Configure a transform set for encryption and authentication.\n\ncrypto ipsec ikev1 transform-set IPSEC_TRANSFORM esp-aes-192 esp-sha-hmac\n\nStep 5: Configure the ACL to define the management traffic that will traverse the tunnel.\n\nASA1(config)# access-list MANAGEMENT_TRAFFIC extended permit udp any eq snmp 10.2.2.0 255.255.255.0 \nASA1(config)# access-list MANAGEMENT_TRAFFIC extended permit udp any eq 10.2.2.0 255.255.255.0 snmptrap\nASA1(config)# access-list MANAGEMENT_TRAFFIC extended permit udp any eq syslog 10.2.2.0 255.255.255.0 \nASA1(config)# access-list MANAGEMENT_TRAFFIC extended permit tcp any eq ssh 10.2.2.0 255.255.255.0 \n\nStep 6: Configure crypto map and bind to the outside interface as shown in the example below.\n\nASA1(config)# crypto map IPSEC_CRYPTO_MAP 1 match address MANAGEMENT_TRAFFIC\nASA1(config)# crypto map IPSEC_CRYPTO_MAP 1 set peer 10.10.10.2\nASA1(config)# crypto map IPSEC_CRYPTO_MAP 1 set ikev1 transform-set MY_TRANSFORM_SET\nASA1(config)# crypto map IPSEC_CRYPTO_MAP 1 set security-association lifetime seconds 3600\nASA1(config)# crypto map IPSEC_CRYPTO_MAP interface OUTSIDE",
"iacontrols": null,
"id": "V-239868",
"ruleID": "SV-239868r855810_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to forward management traffic to the Network Operations Center (NOC) via an IPsec tunnel.",
"version": "CASA-FW-000260"
},
"V-239869": {
"checkid": "C-43102r665891_chk",
"checktext": "Review the firewall configuration to verify that inspection for applications deployed within the network is being performed on all interfaces. The following command should be configured: service-policy global_policy global \n\nIf the firewall is not configured to inspect all inbound and outbound traffic at the application layer, this is a finding.",
"description": "Application inspection enables the firewall to control traffic based on different parameters that exist within the packets such as enforcing application-specific message and field length. Inspection provides improved protection against application-based attacks by restricting the types of commands allowed for the applications. Application inspection all enforces conformance against published RFCs.\n\nSome applications embed an IP address in the packet that needs to match the source address that is normally translated when it goes through the firewall. Enabling application inspection for a service that embeds IP addresses, the firewall translates embedded addresses and updates any checksum or other fields that are affected by the translation. Enabling application inspection for a service that uses dynamically assigned ports, the firewall monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.",
"fixid": "F-43061r665892_fix",
"fixtext": "Configure the firewall to inspect all inbound and outbound traffic at the application layer.\n\nASA(config)# service-policy global_policy global \nASA(config)# end",
"iacontrols": null,
"id": "V-239869",
"ruleID": "SV-239869r665893_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to inspect all inbound and outbound traffic at the application layer.",
"version": "CASA-FW-000270"
},
"V-239870": {
"checkid": "C-43103r665894_chk",
"checktext": "Review the firewall configuration to verify that IPv6 inspection is being performed on all interfaces.\n\nStep 1: Verify that the inspect ipv6 command is configured under the global policy map as shown in the example below.\n\npolicy-map global_policy\n class inspection_default\n \u2026\n \u2026\n \u2026\n inspect ipv6 IPV6_MAP\n\nStep 2: If a policy map is specified for the inspect ipv6 command, verify the parameters command has been configured. Also verify that the \u201cno verify-header order\u201d and \u201cno verify-header type\u201d sub-command are not configured under the parameters command.\n\npolicy-map type inspect ipv6 IPV6_MAP\n parameters\n match header hop-by-hop\n drop log\nmatch header routing-type eq 0\n drop log\nmatch header routing-type eq 1\n drop log\nmatch header routing-type range 3 255\n drop log\n match header destination-option\n drop log\n\nNote: If policy map is not specified for the inspect ipv6 command, the default IPv6 inspection policy map is used and the following actions are taken:\n\n1. Allows only known IPv6 extension headers. Non-conforming packets are dropped and logged.\n2. Enforces the order of IPv6 extension headers as defined in the RFC 2460 specification. Non-conforming packets are dropped and logged.\n3. Drops any packet with a routing type header.\n\nNote: This requirement is not applicable if IPv6 is not enabled on any interfaces.\n\nIf the firewall is not configured to inspect all inbound and outbound IPv6 traffic for unknown or out-of-order extension headers, this is a finding.",
"description": "IPv6 packets with unknown extension headers as well as out-of-order headers can create Denial-of-Service attacks for other networking components as well as host devices. IPv6 inspection can check conformance to RFC 2460 enforcing the order extension headers. While routers only need to examine the IPv6 destination address and the Hop-by-Hop Options header, firewalls must recognize and parse through all existing extension headers since the upper-layer protocol information resides in the last header. An attacker is able to chain many extension headers in order to pass firewall and intrusion detections. An attacker can cause a denial of service if an intermediary device or destination host is not capable of processing an extensive or out-of-order chain of extension headers. Hence, it is imperative the firewall is configured to drop packets with unknown or out-of-order headers.",
"fixid": "F-43062r665895_fix",
"fixtext": "Configure the firewall to inspect all inbound and outbound IPv6 traffic for unknown or out-of-order extension headers.\n\nStep 1 (optional): Configure an IPv6 inspect policy map.\n\nASA(config)# policy-map type inspect ipv6 IPV6_MAP \nASA(config-pmap)# parameters\nASA(config-pmap-p)# verify-header type \nASA(config-pmap-p)# verify-header order\nASA(config-pmap-p)# exit\nASA(config-pmap)# match header hop-by-hop \nASA(config-pmap-c)# drop log \nASA(config-pmap-c)# exit \nASA(config-pmap)# match header routing-type eq 0\nASA(config-pmap-c)# drop log \nASA(config-pmap-c)# exit\nASA(config-pmap)# match header routing-type eq 1\nASA(config-pmap-c)# drop log \nASA(config-pmap-c)# exit\nASA(config-pmap)# match header routing-type range 3 255\nASA(config-pmap-c)# drop log \nASA(config-pmap-c)# exit\n\nNote: The verify-header type and verify-header order are enabled by default when the parameters command is configured.\n\nStep 2: Include the inspect ipv6 command in the global policy-map as shown in the example below.\n\nASA(config)# policy-map global_policy\nASA(config-pmap)# class inspection_default\nASA(config-pmap-c)# inspect ipv6\nASA(config-pmap-c)# end",
"iacontrols": null,
"id": "V-239870",
"ruleID": "SV-239870r665896_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to inspect all inbound and outbound IPv6 traffic for unknown or out-of-order extension headers.",
"version": "CASA-FW-000280"
},
"V-239871": {
"checkid": "C-43104r665897_chk",
"checktext": "Review the firewall configuration to verify uRPF or an egress filter has been configured on all internal interfaces to restrict the firewall from accepting outbound packets that contain an illegitimate address in the source address field.\n\nURF Example:\n\nip verify reverse-path interface INSIDE\n\nACL Example:\n\nStep 1: Verify that an ACL has been applied inbound on the inside interfaces as shown in the example below.\n\naccess-group INSIDE_IN in interface INSIDE\n\nStep 2: Verify that the ACL only allows packets from legitimate internal source addresses.\n\nobject-group network LAN_SUBNETS\n network-object 10.1.10.0 255.255.255.0\n network-object 10.1.12.0 255.255.255.0\n network-object 10.1.13.0 255.255.255.0\n network-object 10.1.22.0 255.255.255.0\n\u2026\n\u2026\n\u2026\naccess-list INSIDE_IN extended permit ip object-group LAN_SUBNETS any \naccess-list INSIDE_IN extended deny ip any any\n\nNote: Traffic that is permitted must be in compliance with the PPSM.\n\nIf uRPF or an egress ACL to restrict the firewall from accepting outbound IP packets that contain an illegitimate address in the source address field has not been configured on all internal interfaces, this is a finding.",
"description": "A compromised host in an enclave can be used by a malicious platform to launch cyberattacks on third parties. This is a common practice in \"botnets\", which are a collection of compromised computers using malware to attack other computers or networks. Denial-of-Service attacks frequently leverage IP source address spoofing to send packets to multiple hosts that, in turn, will then send return traffic to the hosts with the IP addresses that were forged. This can generate significant amounts of traffic. Therefore, protection measures to counteract IP source address spoofing must be taken. When uRPF is enabled in strict mode, the packet must be received on the interface that the device would use to forward the return packet, thereby mitigating IP source address spoofing.",
"fixid": "F-43063r665898_fix",
"fixtext": "Configure the firewall with an egress filter or uRPF on all internal interfaces to restrict the firewall from accepting any outbound packet that contains an illegitimate address in the source field.\n\nURF Example:\n\nip verify reverse-path interface INSIDE\n\nACL Example:\n\nStep 1: Configure an object group containing the allowed subnets as shown in the example below.\n\nASA(config)# object-group network LAN_SUBNETS\nASA(config-network-object-group)# network-object 10.1.10.0 255.255.255.0\nASA(config-network-object-group)# network-object 10.1.12.0 255.255.255.0\nASA(config-network-object-group)# network-object 10.1.13.0 255.255.255.0\nASA(config-network-object-group)# network-object 10.1.22.0 255.255.255.0\nASA(config-network-object-group)# exit\n\nStep 2: Configure the ACL.\n\nASA(config)# access-list INSIDE_IN permit ip object-group LAN_SUBNETS any\nASA(config)# access-list INSIDE_IN deny ip any any \n\nNote: Traffic that is permitted must be in compliance with the PPSM. \n\nStep 3: Apply the ACL inbound on the inside interface.\n\nASA(config)# access-group INSIDE_IN in interface INSIDE",
"iacontrols": null,
"id": "V-239871",
"ruleID": "SV-239871r665899_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to restrict it from accepting outbound packets that contain an illegitimate address in the source address field via an egress filter or by enabling Unicast Reverse Path Forwarding (uRPF).",
"version": "CASA-FW-000290"
},
"V-239872": {
"checkid": "C-43105r863232_chk",
"checktext": "NOTE: When operating the ASA in multi-context mode with a separate IDPS, threat detection cannot be enabled, and this check is Not Applicable.\n\nStep 1: Verify that basic and scanning threat detection has been configured as shown below.\n\nthreat-detection basic-threat\nthreat-detection scanning-threat\n\nStep 2: Configure the ASA to send an email to organization-defined personnel and/or the firewall administrator for syslog messages at severity level 4 (warnings) as shown in the example below.\n\nlogging mail warnings\nlogging from-address firewall@mail.mil\nlogging recipient-address OurFWadmin@mail.mil level warnings\nlogging recipient-address OurISSO@mail.mil level warnings\n\u2026\n\u2026\n\u2026\nsmtp-server 10.1.12.33\n\nNote: When a basic threat is detected, the ASA generates syslog message %ASA-4-733100. When scanning threat is detected, the ASA generates syslog message %ASA-4-733101. As an alternative to sending email alerts, SNMP traps could be sent to an SIEM that is monitored.\n\nIf the ASA is not configured to generate an alert that can be forwarded to the organization-defined personnel and/or firewall administrator when a threat has been detected, this is a finding.",
"description": "Without an alert, security personnel may be unaware of major detection incidents that require immediate action, and this delay may result in the loss or compromise of information.\n\nThe firewall generates an alert that notifies designated personnel of the Indicators of Compromise (IOCs), which require real-time alerts. These messages should include a severity level indicator or code as an indicator of the criticality of the incident. These indicators reflect the occurrence of a compromise or a potential compromise.\n\nSince these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.\n\nCJCSM 6510.01B, \"Cyber Incident Handling Program\", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category 1, 2, 4, or 7 detection events) will require an alert when an event is detected.\n\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The firewall must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The ISSM or ISSO may designate the firewall/system administrator or other authorized personnel to receive the alert within the specified time, validate the alert, and then forward only validated alerts to the ISSM and ISSO.",
"fixid": "F-43064r665901_fix",
"fixtext": "Step 1: Configure basic and scanning threat detection as shown below.\n\nASA(config)# threat-detection basic-threat\nASA(config)# threat-detection scanning-threat\n\nStep 2: Configure the ASA to send an email alert to the organization-defined personnel and/or firewall administrator for syslog messages at severity level 4.\n\nASA(config)# logging mail 4 \nASA(config)# logging recipient-address OurFWadmin@mail.mil\nASA(config)# logging recipient-address OurISSO@mail.mil\nASA(config)# logging from-address firewall@mail.mil\nASA(config)# smtp-server 10.1.12.33\nASA(config)# end\n\nNote: As an alternative to sending email alerts, SNMP traps could be sent to an SIEM that is monitored.",
"iacontrols": null,
"id": "V-239872",
"ruleID": "SV-239872r863233_rule",
"severity": "medium",
"title": "The Cisco ASA must be configured to generate an alert that can be forwarded to organization-defined personnel and/or the firewall administrator when denial-of-service (DoS) incidents are detected.",
"version": "CASA-FW-000300"
}
},
"profiles": {
"MAC-1_Classified": {
"description": "",
"findings": {
"V-239852": "true",
"V-239853": "true",
"V-239854": "true",
"V-239855": "true",
"V-239856": "true",
"V-239857": "true",
"V-239858": "true",
"V-239859": "true",
"V-239860": "true",
"V-239861": "true",
"V-239862": "true",
"V-239863": "true",
"V-239864": "true",
"V-239865": "true",
"V-239866": "true",
"V-239867": "true",
"V-239868": "true",
"V-239869": "true",
"V-239870": "true",
"V-239871": "true",
"V-239872": "true"
},
"id": "MAC-1_Classified",
"title": "I - Mission Critical Classified"
},
"MAC-1_Public": {
"description": "",
"findings": {
"V-239852": "true",
"V-239853": "true",
"V-239854": "true",
"V-239855": "true",
"V-239856": "true",
"V-239857": "true",
"V-239858": "true",
"V-239859": "true",
"V-239860": "true",
"V-239861": "true",
"V-239862": "true",
"V-239863": "true",
"V-239864": "true",
"V-239865": "true",
"V-239866": "true",
"V-239867": "true",
"V-239868": "true",
"V-239869": "true",
"V-239870": "true",
"V-239871": "true",
"V-239872": "true"
},
"id": "MAC-1_Public",
"title": "I - Mission Critical Public"
},
"MAC-1_Sensitive": {
"description": "",
"findings": {
"V-239852": "true",
"V-239853": "true",
"V-239854": "true",
"V-239855": "true",
"V-239856": "true",
"V-239857": "true",
"V-239858": "true",
"V-239859": "true",
"V-239860": "true",
"V-239861": "true",
"V-239862": "true",
"V-239863": "true",
"V-239864": "true",
"V-239865": "true",
"V-239866": "true",
"V-239867": "true",
"V-239868": "true",
"V-239869": "true",
"V-239870": "true",
"V-239871": "true",
"V-239872": "true"
},
"id": "MAC-1_Sensitive",
"title": "I - Mission Critical Sensitive"
},
"MAC-2_Classified": {
"description": "",
"findings": {
"V-239852": "true",
"V-239853": "true",
"V-239854": "true",
"V-239855": "true",
"V-239856": "true",
"V-239857": "true",
"V-239858": "true",
"V-239859": "true",
"V-239860": "true",
"V-239861": "true",
"V-239862": "true",
"V-239863": "true",
"V-239864": "true",
"V-239865": "true",
"V-239866": "true",
"V-239867": "true",
"V-239868": "true",
"V-239869": "true",
"V-239870": "true",
"V-239871": "true",
"V-239872": "true"
},
"id": "MAC-2_Classified",
"title": "II - Mission Support Classified"
},
"MAC-2_Public": {
"description": "",
"findings": {
"V-239852": "true",
"V-239853": "true",
"V-239854": "true",
"V-239855": "true",
"V-239856": "true",
"V-239857": "true",
"V-239858": "true",
"V-239859": "true",
"V-239860": "true",
"V-239861": "true",
"V-239862": "true",
"V-239863": "true",
"V-239864": "true",
"V-239865": "true",
"V-239866": "true",
"V-239867": "true",
"V-239868": "true",
"V-239869": "true",
"V-239870": "true",
"V-239871": "true",
"V-239872": "true"
},
"id": "MAC-2_Public",
"title": "II - Mission Support Public"
},
"MAC-2_Sensitive": {
"description": "",
"findings": {
"V-239852": "true",
"V-239853": "true",
"V-239854": "true",
"V-239855": "true",
"V-239856": "true",
"V-239857": "true",
"V-239858": "true",
"V-239859": "true",
"V-239860": "true",
"V-239861": "true",
"V-239862": "true",
"V-239863": "true",
"V-239864": "true",
"V-239865": "true",
"V-239866": "true",
"V-239867": "true",
"V-239868": "true",
"V-239869": "true",
"V-239870": "true",
"V-239871": "true",
"V-239872": "true"
},
"id": "MAC-2_Sensitive",
"title": "II - Mission Support Sensitive"
},
"MAC-3_Classified": {
"description": "",
"findings": {
"V-239852": "true",
"V-239853": "true",
"V-239854": "true",
"V-239855": "true",
"V-239856": "true",
"V-239857": "true",
"V-239858": "true",
"V-239859": "true",
"V-239860": "true",
"V-239861": "true",
"V-239862": "true",
"V-239863": "true",
"V-239864": "true",
"V-239865": "true",
"V-239866": "true",
"V-239867": "true",
"V-239868": "true",
"V-239869": "true",
"V-239870": "true",
"V-239871": "true",
"V-239872": "true"
},
"id": "MAC-3_Classified",
"title": "III - Administrative Classified"
},
"MAC-3_Public": {
"description": "",
"findings": {
"V-239852": "true",
"V-239853": "true",
"V-239854": "true",
"V-239855": "true",
"V-239856": "true",
"V-239857": "true",
"V-239858": "true",
"V-239859": "true",
"V-239860": "true",
"V-239861": "true",
"V-239862": "true",
"V-239863": "true",
"V-239864": "true",
"V-239865": "true",
"V-239866": "true",
"V-239867": "true",
"V-239868": "true",
"V-239869": "true",
"V-239870": "true",
"V-239871": "true",
"V-239872": "true"
},
"id": "MAC-3_Public",
"title": "III - Administrative Public"
},
"MAC-3_Sensitive": {
"description": "",
"findings": {
"V-239852": "true",
"V-239853": "true",
"V-239854": "true",
"V-239855": "true",
"V-239856": "true",
"V-239857": "true",
"V-239858": "true",
"V-239859": "true",
"V-239860": "true",
"V-239861": "true",
"V-239862": "true",
"V-239863": "true",
"V-239864": "true",
"V-239865": "true",
"V-239866": "true",
"V-239867": "true",
"V-239868": "true",
"V-239869": "true",
"V-239870": "true",
"V-239871": "true",
"V-239872": "true"
},
"id": "MAC-3_Sensitive",
"title": "III - Administrative Sensitive"
}
},
"slug": "cisco_asa_firewall",
"title": "Cisco ASA Firewall Security Technical Implementation Guide",
"version": "1"
}
}