acceptedCisco ASA IPS Security Technical Implementation GuideThis 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.DISASTIG.DOD.MILRelease: 1 Benchmark Date: 15 Jul 20213.2.2.360791.10.01I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>SRG-NET-000074-IDPS-00059<GroupDescription></GroupDescription>CASA-IP-000040The Cisco ASA must be configured to produce audit records containing sufficient information to establish what type of event occurred.<VulnDiscussion>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. Associating an event type with each event log entry provides a means of investigating an attack or identifying an improperly configured IDPS.
While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-000130Enable logging for connection events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to configure. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to edit. Select a logging option either log at Beginning and End of Connection or log at End of Connection. Select the Syslog check box.
Step 4: Click Save.
---------------------------------------------------
Enable logging for Intrusion events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Setting. The Advanced Settings page appears.
Step 3: If Syslog Alerting under External Responses is enabled, click Edit. If the configuration is disabled, click Enabled, then click Edit. The Syslog Alerting page appears.
Step 4: In the Logging Hosts field, enter the remote access IP address you want to specify as logging host.
Step 5: Click Save.Verify logging for connection events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to view. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to view. Verify that a logging option has been selected. Verify that the Syslog check box has been selected.
---------------------------------------------------
Verify logging for Intrusion events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Setting. The Advanced Settings page appears.
Step 3: Verify that Syslog Alerting under External Responses is enabled.
If the Cisco ASA is not configured to produce log records containing information to establish what type of event occurred, this is a finding.SRG-NET-000075-IDPS-00060<GroupDescription></GroupDescription>CASA-IP-000050The Cisco ASA must be configured to produce audit records containing information to establish when the events occurred.<VulnDiscussion>Without establishing the time (date/time) an event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Associating the date and time the event occurred with each event log entry provides a means of investigating an attack or identifying an improperly configured IDPS.
While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-000131Enable logging for connection events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to configure. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to edit. Select a logging option either log at Beginning and End of Connection or log at End of Connection. Select the Syslog check box.
Step 4: Click Save.
---------------------------------------------------
Enable logging for Intrusion events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Setting. The Advanced Settings page appears.
Step 3: If Syslog Alerting under External Responses is enabled, click Edit. If the configuration is disabled, click Enabled, then click Edit. The Syslog Alerting page appears.
Step 4: In the Logging Hosts field, enter the remote access IP address you want to specify as logging host.
Step 5: Click Save.Verify logging for connection events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to view. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to view. Verify a logging option has been selected, Verify the Syslog check box has been selected.
---------------------------------------------------
Verify logging for Intrusion events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Setting. The Advanced Settings page appears.
Step 3: Verify that Syslog Alerting under External Responses is enabled.
If the Cisco ASA is not configured to produce log records containing information to establish when the events occurred, this is a finding.SRG-NET-000076-IDPS-00061<GroupDescription></GroupDescription>CASA-IP-000060The Cisco ASA must be configured to produce audit records containing information to establish where the event was detected.<VulnDiscussion>Associating where the event was detected with the event log entries provides a means of investigating an attack or identifying an improperly configured IDPS. This information can be used to determine what systems may have been affected.
While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-000132Enable logging for connection events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to configure. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to edit. Select a logging option either log at Beginning and End of Connection or log at End of Connection. Select the Syslog check box.
Step 4: Click Save.
---------------------------------------------------
Enable logging for Intrusion events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Setting. The Advanced Settings page appears.
Step 3: If Syslog Alerting under External Responses is enabled, click Edit. If the configuration is disabled, click Enabled, then click Edit. The Syslog Alerting page appears.
Step 4: In the Logging Hosts field, enter the remote access IP address you want to specify as logging host.
Step 5: Click Save.Verify logging for connection events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to view. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to view. Verify that a logging option has been selected. Verify that the Syslog check box has been selected.
---------------------------------------------------
Verify logging for Intrusion events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Setting. The Advanced Settings page appears.
Step 3: Verify that Syslog Alerting under External Responses is enabled.
If the Cisco ASA is not configured to produce log records containing information to establish where the event was detected, this is a finding.SRG-NET-000077-IDPS-00062<GroupDescription></GroupDescription>CASA-IP-000070The Cisco ASA must be configured to produce audit records containing information to establish the source of the event.<VulnDiscussion>Associating the source of the event with detected events in the logs provides a means of investigating an attack or suspected attack.
While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-000133Enable logging for connection events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to configure. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to edit. Select a logging option either log at Beginning and End of Connection or log at End of Connection. Select the Syslog check box.
Step 4: Click Save.
---------------------------------------------------
Enable logging for Intrusion events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Setting. The Advanced Settings page appears.
Step 3: If Syslog Alerting under External Responses is enabled, click Edit. If the configuration is disabled, click Enabled, then click Edit. The Syslog Alerting page appears.
Step 4: in the Logging Hosts field, enter the remote access IP address you want to specify as logging host.
Step 5: Click Save.Verify logging for connection events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to view. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to view. Verify that a logging option has been selected. Verify that the Syslog check box has been selected.
---------------------------------------------------
Verify logging for Intrusion events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Setting. The Advanced Settings page appears.
Step 3: Verify that Syslog Alerting under External Responses is enabled.
If the Cisco ASA Firepower is not configured to produce log records containing information to establish the source of the event, this is a finding.SRG-NET-000078-IDPS-00063<GroupDescription></GroupDescription>CASA-IP-000080The Cisco ASA must be configured to produce audit records containing information to establish the outcome of events associated with detected harmful or potentially harmful traffic.<VulnDiscussion>Associating event outcome with detected events in the log provides a means of investigating an attack or suspected attack.
While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.
The logs should identify what servers, destination addresses, applications, or databases were potentially attacked by logging communications traffic between the target and the attacker. All commands that were entered by the attacker (such as account creations, changes in permissions, files accessed, etc.) during the session should also be logged.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-000134Enable logging for connection events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to configure. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to edit. Select a logging option either log at Beginning and End of Connection or log at End of Connection. Select the Syslog check box.
Step 4: Click Save.
---------------------------------------------------
Enable logging for Intrusion events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Setting. The Advanced Settings page appears.
Step 3: If Syslog Alerting under External Responses is enabled, click Edit. If the configuration is disabled, click Enabled, then click Edit. The Syslog Alerting page appears.
Step 4: In the Logging Hosts field, enter the remote access IP address you want to specify as logging host.
Step 5: Click Save.Verify logging for connection events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to view. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to view. Verify that a logging option has been selected. Verify that the Syslog check box has been selected.
---------------------------------------------------
Verify logging for Intrusion events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies > Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Setting. The Advanced Settings page appears.
Step 3: Verify that Syslog Alerting under External Responses is enabled.
If the Cisco ASA is not configured to produce log records containing information to establish the outcome of events associated with detected harmful or potentially harmful traffic, this is a finding.SRG-NET-000113-IDPS-00013<GroupDescription></GroupDescription>CASA-IP-000090The Cisco ASA must be configured to log events based on policy access control rules, signatures, and anomaly analysis.<VulnDiscussion>Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.
While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.
The IDPS must have the capability to capture and log detected security violations and potential security violations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-000169Deploy a Network Analysis policy.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to edit. The access control policy editor appears.
Step 3: Click Advanced Settings. The access control policy advanced settings page appears.
Step 4: Click the edit icon next to Network Analysis and Intrusion Policies. The Network Analysis and Intrusion Policies pop-up window appears.
Step 5: Enable the Balanced Security and Connectivity or a site-customized policy.
-------------------------------------------------
Enable logging for connection events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to configure. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to edit. Select a logging option either log at Beginning and End of Connection or log at End of Connection. Select the Syslog check box.
Step 4: Click Save.
---------------------------------------
Enable logging for Intrusion events.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Settings. The Advanced Settings page appears.
Step 3: If Syslog Alerting under External Responses is enabled, click Edit. If the configuration is disabled, click Enabled, then click Edit. The Syslog Alerting page appears.
Step 4: in the Logging Hosts field, enter the remote access IP address you want to specify as logging host.
Step 5: Click Save.Verify that a Network Analysis policy exists.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to view. The access control policy editor appears.
Step 3: Click Advanced Settings. The access control policy advanced settings page appears.
Step 4: Click the edit icon next to Network Analysis and Intrusion Policies. The Network Analysis and Intrusion Policies pop-up window appears.
Step 5: Click Network Analysis Policy List. The Network Analysis Policy List pop-up window appears.
Verify that a policy exists. By default, the system uses the Balanced Security and Connectivity network analysis policy.
Note: A network analysis policy governs how traffic is decoded and preprocessed so that it can be further evaluated for anomalous traffic that might signal an intrusion attempt. An intrusion policy uses intrusion and preprocessor rules (sometimes referred to collectively as intrusion rules) to examine the decoded packets for attacks based on patterns. Both network analysis and intrusion policies are invoked by a parent access control policy. As the system analyzes traffic, the network analysis phase occurs before and separately from the intrusion prevention phase.
-------------------------------------------------
Verify logging for connection events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy you want to view. The access control policy editor appears.
Step 3: Click the edit icon next to a rule to view. Verify that a logging option has been selected. Verify that the Syslog check box has been selected.
---------------------------------------------------
Verify logging for Intrusion events is enabled.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Intrusion Policy >> Intrusion Policy. The Intrusion Policy page appears.
Step 2: Click Advanced Settings. The Advanced Settings page appears.
Step 3: Verify that Syslog Alerting under External Responses is enabled.
If the Cisco ASA is not configured to log events based on policy access control rules, signatures, and anomaly analysis, this is a finding.SRG-NET-000334-IDPS-00191<GroupDescription></GroupDescription>CASA-IP-000110The Cisco ASA must be configured to off-load log records to a centralized log server.<VulnDiscussion>Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading ensures audit information does not get overwritten if the limited audit storage capacity is reached and also protects the audit record in case the system/component being audited is compromised.
This also prevents the log records from being lost if the logs stored locally are accidentally or intentionally deleted, altered, or corrupted.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-001851Configure Firepower to send log records to a syslog server as shown in the following steps:
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Actions Alerts.
Step 2: Click the Create Alert drop-down menu and choose option Create Syslog Alert.
Step 3: Enter the following values for the Syslog server:
Host: Specify the IP address/hostname of Syslog server.
Port: Specify the port number of Syslog server.
Step 4: Click Store ASA FirePOWER Changes.Verify that a syslog server has been defined.
Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies > Actions Alerts. The Alerts page appears.
Step 2: Verify the IP address and port number of the syslog server.
If the Cisco ASA is not configured to send log records to a centralized log server, this is a finding.SRG-NET-000113-IDPS-00189<GroupDescription></GroupDescription>CASA-IP-000120The Cisco ASA must be configured to send log records to the syslog server for specific facility and severity level.<VulnDiscussion>Without the capability to generate audit records with a severity code it is difficult to track and handle detection events.
While auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.
The IDPS must have the capability to collect and log the severity associated with the policy, rule, or signature. IDPS products often have either pre-configured and/or a configurable method for associating an impact indicator or severity code with signatures and rules, at a minimum.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-000169Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Actions Alerts.
Step 2: Click the Create Alert drop-down menu and choose option Create Syslog Alert.
Step 3: Enter the following values for the Syslog server:
Facility: Select any facility that is configured on your Syslog server.
Severity: Select any severity that is configured on your Syslog server.
Step 4: Click Store ASA FirePOWER Changes.Step 1: Navigate to Configuration >> ASA Firepower Configuration >> Policies >> Actions Alerts. The Alerts page appears.
Step 2: Verify a facility has been selected for the syslog server.
If the Cisco ASA Firepower is not configured to send log records to the syslog server for specific facility and severity level, this is a finding.SRG-NET-000089-IDPS-00010<GroupDescription></GroupDescription>CASA-IP-000130The Cisco ASA must be configured to queue log records locally In the event that the central audit server is down or not reachable.<VulnDiscussion>It is critical that when the IDPS is at risk of failing to process audit logs as required, it take 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 upon the nature of the failure.
The IDPS performs a critical security function, so its continued operation is imperative. Since availability of the IDPS is an overriding concern, shutting down the system in the event of an audit failure should be avoided, except as a last resort. The SYSLOG protocol does not support automated synchronization, however this functionality may be provided by Network Management Systems (NMSs) which are not within the scope of this SRG.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-000140Step 1: Navigate to Devices >> Platform Settings >> Syslog Servers.
Step 2: Click on the pencil icon to edit the applicable server.
Step 3: Select the TCP option.
Step 4: Click OK and Save.Verify that TCP is being used to send log data to the syslog server.
Step 1: Navigate to Devices >> Platform Settings >> Syslog Servers.
Step 2: Verify that TCP is listed under the Protocol tab has been selected.
If the Cisco ASA is not configured to use TCP to send log data to the syslog server, this is a finding.SRG-NET-000192-IDPS-00140<GroupDescription></GroupDescription>CASA-IP-000180The Cisco ASA must be configured to block outbound traffic containing DoS attacks by ensuring an intrusion prevention policy has been applied to outbound communications traffic.<VulnDiscussion>The IDPS must include protection against DoS attacks that originate from inside the enclave which can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave.
Installation of IDPS detection and prevention components (i.e., sensors) at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type.
To comply with this requirement, the IDPS must inspect outbound traffic for indications of known and unknown DoS attacks. Sensor log capacity management, along with techniques that prevent the logging of redundant information during an attack, also guards against DoS attacks. This requirement is used in conjunction with other requirements which require configuration of security policies, signatures, rules, and anomaly detection techniques and are applicable to both inbound and outbound traffic.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-001095Configure access control rules to block non-compliant traffic.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy configured for intrusion inspection using access control rules.
Step 3: Click the edit icon next to the rule you want to edit. The access control rule editor appears.
Step 4: Set the rule action Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Select a system-provided or custom intrusion policy.
Step 7: Click Save to save the rule.
---------------------------------------------------
Configure the ASA to redirect all traffic to the FirePOWER module in inline mode as shown in the example below.
Step 1: Configure access list for all traffic.
ASA1(config)# access-list FIREPOWER_REDIRECT extended permit ip any any
Step 2: Create a class-map in order to match the traffic on an access list.
ASA1(config)# class-map FIREPOWER_SFR
ASA1(config-cmap)# match access-list FIREPOWER_REDIRECT
Step 3: Configure deployment mode as inline.
ASA1(config)# policy-map global_policy
ASA1(config-pmap)# class FIREPOWER_SFR
ASA1(config-pmap-c)# sfr fail-openVerify that an intrusion policy has been applied to access control rules.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy configured for intrusion inspection using access control rules.
Step 3: Click the edit icon next to the rule you want to view. The access control rule editor appears.
Step 4: Verify that the rule action is set to Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Verify that a system-provided or custom intrusion policy has been selected.
Note: An access control policy can have multiple access control rules associated with intrusion policies.
---------------------------------------------------
Verify that the ASA is configured to redirect all traffic to the FirePOWER service module.
Step 1: Verify that the FirePOWER service module has been deployed in inline mode as shown in the example below.
policy-map global_policy
class FIREPOWER_SFR
sfr fail-open
Step 2: Verify that all traffic is redirected.
access-list FIREPOWER_REDIRECT extended permit ip any any
…
…
…
class-map FIREPOWER_SFR
match access-list FIREPOWER_REDIRECT
Note: Inbound and outbound traffic that is allowed by the ASA firewall is forwarded to the FirePOWER module. If the Cisco ASA FirePOWER module is configured in inline mode, the packet is inspected and dropped if it does not conform to access control policies. If the packet is compliant with access control policies, it is sent back to the ASA firewall for processing.
If the ASA is not configured to block outbound traffic containing DoS attacks by ensuring an intrusion prevention policy has been applied to outbound communications traffic, this is a finding.SRG-NET-000228-IDPS-00196<GroupDescription></GroupDescription>CASA-IP-000190The Cisco ASA must be configured to use Advanced Malware Protection (AMP) features to detect and block the transmission of malicious software and malware.<VulnDiscussion>Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an e-mail attachment or embedded in other file formats not traditionally associated with executable code.
While the IDPS cannot replace the anti-virus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented, which provide preemptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by anti-virus or malicious code solution vendors.
To monitor for and detect known prohibited mobile code or approved mobile code that violates permitted usage requirements, the IDPS must implement policy filters, rules, signatures, and anomaly analysis.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-001166Step 1: Select Configuration >> ASA FirePOWER Configuration >> Policies >> Files. The File Policies page appears.
Step 2: Enter a Name and optional Description for your new policy, then click Save. The File Policy Rules tab appears.
Step 3: Click Add File Rule. The Add File Rule dialog box appears.
Step 4: Select an Application Protocol from the drop-down list.
Note: Any detects files in HTTP, SMTP, IMAP, POP3, FTP, and NetBIOS-ssn (SMB) traffic.
Step 5: Select rule action Block Malware.
Step 6: Select one or more File Types.
Step 7: Add the selected file types (i.e. multimedia, executables, etc.) to the Selected Files Categories and Types list by clicking Add to add selected file types to the rule, then drag-and-drop one or more file types into the Selected Files Categories and Types list.
Step 8: Click Store ASA FirePOWER Changes.
---------------------------------------------------------------
Apply the file policy to an access control policy.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy where you want to configure AMP or file control using access control rules.
Step 3: Create or the edit icon next to the rule you want to edit. The access control rule editor appears.
Step 4: Set the rule action Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Select the configured file policy to inspect traffic.
Step 7: Click Add to save the rule.Verify that a file policy is applied to an access control policy.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies > Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy enabled for AMP or file control.
Step 3: Click the edit icon next to the rule you want to edit. The access control rule editor appears.
Step 4: Verify that the rule action is Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Verify that a file policy has been selected to inspect traffic.
-------------------------------------------------
Verify that the file policy blocks malware.
Step 1: Select Configuration >> ASA FirePOWER Configuration >> Policies >> Files. The File Policies page appears.
Step 2: Click the edit icon next to the file policy for malware. The File Policy Rules tab appears.
Step 3: Verify that application protocols have been selected or any.
Note: Any detects files in HTTP, SMTP, IMAP, POP3, FTP, and NetBIOS-ssn (SMB) traffic.
Step 4: Verify that the rule action is Block Malware.
If the ASA is not configured to use AMP features to detect and block the transmission of malicious software and malware, this is a finding.SRG-NET-000229-IDPS-00163<GroupDescription></GroupDescription>CASA-IP-000200The Cisco ASA must block any prohibited mobile code at the enclave boundary when it is detected.<VulnDiscussion>Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an e-mail attachment or embedded in other file formats not traditionally associated with executable code.
While the IDPS cannot replace the anti-virus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented, which provide preemptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by anti-virus or malicious code solution vendors.
To block known prohibited mobile code or approved mobile code that violates permitted usage requirements, the IDPS must implement policy filters, rules, signatures, and anomaly analysis.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-001662Create a file policy.
Step 1: Select Configuration >> ASA FirePOWER Configuration> > Policies >> Files. The File Policies page appears.
Step 2: Enter a Name and optional Description for your new policy, then click Save. The File Policy Rules tab appears.
Step 3: Click Add File Rule. The Add File Rule dialog box appears.
Step 4: Select an Application Protocol from the drop-down list.
Note: Any detects files in HTTP, SMTP, IMAP, POP3, FTP, and NetBIOS-ssn (SMB) traffic.
Step 5: Select rule action Block Malware.
Step 6: Select one or more File Types.
Step 7: Add the selected file types (e.g., multimedia, executables, etc.) to the Selected Files Categories and Types list by clicking Add to add selected file types to the rule. Drag and drop one or more file types into the Selected Files Categories and Types list.
Step 8: Click Store ASA FirePOWER Changes.
---------------------------------------------------------------
Apply the file policy to an access control policy.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy where you want to configure AMP or file control using access control rules.
Step 3: Create or the edit icon next to the rule you want to edit. The access control rule editor appears.
Step 4: Set the rule action Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Select the configured file policy to inspect traffic.
Step 7: Click Add to save the rule.Verify that a file policy is applied to an access control policy.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy enabled for AMP or file control.
Step 3: Click the edit icon next to the rule you want to edit. The access control rule editor appears.
Step 4: Verify that the rule action is Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Verify that a file policy has been selected to inspect traffic.
-------------------------------------------------
Verify that the file policy blocks malware.
Step 1: Select Configuration >> ASA FirePOWER Configuration >> Policies >> Files. The File Policies page appears.
Step 2: Click the edit icon next to the file policy for malware. The File Policy Rules tab appears.
Step 3: Verify that application protocols have been selected or any.
Note: Any detects files in HTTP, SMTP, IMAP, POP3, FTP, and NetBIOS-ssn (SMB) traffic.
Step 4: Verify that the rule action is Block Malware.
If the ASA is not configured to block any prohibited mobile code at the enclave boundary, this is a finding.SRG-NET-000246-IDPS-00205<GroupDescription></GroupDescription>CASA-IP-000240The Cisco ASA must be configured to install updates for signature definitions and vendor-provided rules.<VulnDiscussion>Failing to update malicious code protection mechanisms, including application software files, signature definitions, and vendor-provided rules, leaves the system vulnerable to exploitation by recently developed attack methods and programs.
The IDPS is a key malicious code protection mechanism in the enclave infrastructure. To ensure this protection is responsive to changes in malicious code threats, IDPS components must be updated, including application software files, anti-virus signatures, detection heuristics, vendor-provided rules, and vendor-provided signatures.
Updates must be installed in accordance with the CCB procedures for the local organization. However, at a minimum:
1. Updates designated as critical security updates by the vendor must be installed immediately.
2. Updates for signature definitions, detection heuristics, and vendor-provided rules must be installed immediately.
3. Updates for application software are installed in accordance with the CCB procedures.
4. Prior to automatically installing updates, either manual or automated integrity and authentication checking is required, at a minimum, for application software updates.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-001240Apply Cisco Vulnerability Database (VDB) updates.
Step 1: Select Configuration >> ASA FirePOWER Configuration >> Updates. The Product Updates page appears.
Step 2: Click Download Updates to check for the latest updates on either of the following Support Sites:
- Sourcefire: https://support.sourcefire.com/
- Cisco: http://www.cisco.com/cisco/web/support/index.html
Step 3: Click the install icon next to the VDB update. The Install Update page appears.
Step 4: Click Install.
----------------------------------------------
Install Rule Updates Automatically.
Step 1: Select Configuration >> ASA FirePOWER Configuration >> Updates.
Step 2: Select the Rule Updates tab. The Rule Updates page appears.
Step 3: Select Enable Recurring Rule Update Imports.
Step 4: In the Import Frequency field, select Daily, Weekly, or Monthly from the drop-down list.
Step 5: Reapply policies after the update completes. Select Reapply intrusion policies after the rule update import completes. Select Reapply access control policies after the rule update import completes.
Step 6: Click Save.Step 1: Select Configuration >> ASA FirePOWER Configuration >> Updates.
Step 2: Select the Rule Updates tab. The Rule Updates page appears.
Step 3: Verify that Enable Recurring Rule Update Imports has been selected.
Step 4: Verify that Daily, Weekly, or Monthly has been selected in the Import Frequency field.
Step 5: Verify that the following have been selected:
- Reapply intrusion policies after the rule update import completes
- Reapply access control policies after the rule update import completes
Note: The Cisco Vulnerability Database (VDB) is a database of known vulnerabilities to which hosts may be susceptible. The Cisco Vulnerability Research Team (VRT) issues periodic updates to the VDB. Verify with the ASA administrator that product updates are installed on a regular basis.
If the ASA is not configured to install updates for signature definitions and vendor-provided rules, this is a finding.SRG-NET-000249-IDPS-00176<GroupDescription></GroupDescription>CASA-IP-000260The Cisco ASA must be configured to block malicious code.<VulnDiscussion>Configuring the IDPS to delete and/or quarantine based on local organizational incident handling procedures minimizes the impact of this code on the network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-001243Create a file policy.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Files. The File Policies page appears.
Step 2: Enter a Name and optional Description for your new policy, then click Save. The File Policy Rules tab appears.
Step 3: Click Add File Rule. The Add File Rule dialog box appears.
Step 4: Select an Application Protocol from the drop-down list.
Note: Any detects files in HTTP, SMTP, IMAP, POP3, FTP, and NetBIOS-ssn (SMB) traffic.
Step 5: Select rule action Block Malware.
Step 6: Select one or more File Types.
Step 7: Add the selected file types (e.g., multimedia, executables, etc.) to the Selected Files Categories and Types list by clicking Add to add selected file types to the rule. Drag and drop one or more file types into the Selected Files Categories and Types list.
Step 8: Click Store ASA FirePOWER Changes.
---------------------------------------------------------------
Apply the file policy to an access control policy.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies > Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy where you want to configure AMP or file control using access control rules.
Step 3: Create or the edit icon next to the rule you want to edit. The access control rule editor appears.
Step 4: Set the rule action Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Select the configured file policy to inspect traffic.
Step 7: Click Add to save the rule.Verify that a file policy is applied to an access control policy.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy enabled for AMP or file control.
Step 3: Click the edit icon next to the rule you want to edit. The access control rule editor appears.
Step 4: Verify that the rule action is Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Verify that a file policy has been selected to inspect traffic.
-------------------------------------------------
Verify that the file policy blocks malware.
Step 1: Select Configuration >> ASA FirePOWER Configuration >> Policies >> Files. The File Policies page appears.
Step 2: Click the edit icon next to the file policy for malware. The File Policy Rules tab appears.
Step 3: Verify that application protocols have been selected or any.
Note: Any detects files in HTTP, SMTP, IMAP, POP3, FTP, and NetBIOS-ssn (SMB) traffic.
Step 4: Verify that the rule action is Block Malware.
If the ASA is not configured to block malicious code, this is a finding.SRG-NET-000249-IDPS-00221<GroupDescription></GroupDescription>CASA-IP-000270The Cisco ASA must be configured to block traffic from IP addresses that have a known bad reputation based on the latest reputation intelligence.<VulnDiscussion>Configuring the network element to delete and/or quarantine based on local organizational incident handling procedures minimizes the impact of this code on the network.
Malicious code includes, but is not limited to, viruses, worms, trojan horses, and spyware. The code provides the ability for a malicious user to read from and write to files and folders on a computer's hard drive. Malicious code may also be able to run and attach programs, which may allow the unauthorized distribution of malicious mobile code.
Sometimes it is necessary to generate a log event and then automatically delete the malicious code; however, for critical attacks or where forensic evidence is deemed necessary, the preferred action is for the file to be quarantined for further investigation.
This requirement is limited to network elements that perform security functions, such as ALG and IDPS.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-001243Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Object Management.
Step 2: Click the Security Intelligence tab.
Step 3: Next to the Intelligence Feed, click the edit icon.
Step 4: Edit the Update Frequency. Choose various intervals from two hours to one week. The user can also disable feed updates.
Step 5: Click Store ASA FirePOWER Changes.Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Object Management.
Step 2: Click the Security Intelligence tab.
Step 3: Next to the Intelligence Feed, click the edit icon.
Step 4: Verify that a frequency has been selected and not disabled.
Note: The Security Intelligence block listing feature is the easiest method to maintain a blacklist. Security Intelligence uses reputation intelligence to quickly block connections to or from IP addresses, URLs, and domain names. The Intelligence Feed, which tracks IP addresses representing security threats such as malware, spam, botnets, and phishing. Because the Intelligence Feed is regularly updated, using it ensures that the system uses up-to-date information to filter malicious network traffic.
If the ASA is not configured to block traffic from IP addresses that have a known bad reputation based on the latest reputation intelligence, this is a finding.SRG-NET-000249-IDPS-00222<GroupDescription></GroupDescription>CASA-IP-000280The Cisco ASA must be configured to send an alert to organization-defined personnel and/or the firewall administrator when malicious code is detected.<VulnDiscussion>Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded.
The IDPS generates an immediate (within seconds) alert which notifies designated personnel of the incident. Sending a message to an unattended log or console does not meet this requirement since that will not be seen immediately. These messages should include a severity level indicator or code as an indicator of the criticality of the incident. The ISSM or ISSO may designate the firewall administrator and/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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-001243Configure email server and email addresses to send alerts to organization-defined personnel and/or the firewall administrator.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: From the Create Alert drop-down menu, choose Create Email Alert.
Step 3: Enter a Name for the alert response. In the To field, enter the email addresses where you want to send alerts, separated by commas. In the From field, enter the email address that you want to appear as the sender of the alert. Next to Relay Host, click edit to enter mail server.
Step 4: Click Save.
----------------------------------------------
Configure Advanced Malware Protection to send alerts when malware is detected.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: Click the Advanced Malware Protections Alerts tab.
Step 3: In the Alerts section, choose the alert response for an email alert.
Step 4: Click Save.Verify email server and email addresses have been defined.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: From the Create Alert drop-down menu, choose Create Email Alert.
Step 3: Verify the email address is that of the system administrator.
----------------------------------------
Verify that Advanced Malware Protection is configured to generate alerts.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: Click the Advanced Malware Protections Alerts tab.
Step 3: In the Alerts section, verify that an email alert has been selected.
Note: The above example is using the Firepower Management Center.
If the ASA is not configured to send an alert to organization-defined personnel and/or the firewall administrator when malicious code is detected, this is a finding.SRG-NET-000251-IDPS-00178<GroupDescription></GroupDescription>CASA-IP-000290The Cisco ASA must be configured to automatically install updates to signature definitions and vendor-provided rules.<VulnDiscussion>Failing to automatically update malicious code protection mechanisms, including application software files, signature definitions, and vendor-provided rules, leaves the system vulnerable to exploitation by recently developed attack methods and programs. An automatic update process ensures this important task is performed without the need for system administrator intervention.
The IDPS is a key malicious code protection mechanism in the enclave infrastructure. To ensure this protection is responsive to changes in malicious code threats, IDPS components must be automatically updated, including anti-virus signatures, detection heuristics, vendor-provided rules, and vendor-provided signatures.
If a DoD patch management server or update repository having the tested/verified updates is available for the IDPS component, the components must be configured to automatically check this server/site for updates and install new updates.
If a DoD server/site is not available, the component must be configured to automatically check a trusted vendor site for updates. A trusted vendor is either commonly used by DoD, specifically approved by DoD, the vendor from which the equipment was purchased, or approved by the local program's CCB.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-001247Apply Cisco Vulnerability Database (VDB) updates.
Step 1: Select Configuration >> ASA FirePOWER Configuration >> Updates. The Product Updates page appears.
Step 2: Click Download Updates to check for the latest updates on either of the following Support Sites:
- Sourcefire: https://support.sourcefire.com/
- Cisco: http://www.cisco.com/cisco/web/support/index.html
Step 3: Click the install icon next to the VDB update. The Install Update page appears.
Step 4: Click Install.
----------------------------------------------
Install Rule Updates Automatically.
Step 1: Select Configuration >> ASA FirePOWER Configuration >> Updates.
Step 2: Select the Rule Updates tab. The Rule Updates page appears.
Step 3: Select Enable Recurring Rule Update Imports.
Step 4: In the Import Frequency field, select Daily, Weekly, or Monthly from the drop-down list.
Step 5: Reapply policies after the update completes. Select Reapply intrusion policies after the rule update import completes. Select Reapply access control policies after the rule update import completes.
Step 6: Click Save.Step 1: Select Configuration >> ASA FirePOWER Configuration >> Updates.
Step 2: Select the Rule Updates tab. The Rule Updates page appears.
Step 3: Verify that Enable Recurring Rule Update Imports has been selected.
Step 4: Verify that Daily, Weekly, or Monthly has been selected in the Import Frequency field.
Step 5: Verify that the following have been selected:
- Reapply intrusion policies after the rule update import completes
- Reapply access control policies after the rule update import completes
Note: The Cisco Vulnerability Database (VDB) is a database of known vulnerabilities to which hosts may be susceptible. The Cisco Vulnerability Research Team (VRT) issues periodic updates to the VDB. Verify with the ASA administrator that product updates are installed on a regular basis.
If the ASA is not configured to install updates for signature definitions and vendor-provided rules, this is a finding.SRG-NET-000390-IDPS-00212<GroupDescription></GroupDescription>CASA-IP-000500The Cisco ASA must be configured to block inbound traffic containing unauthorized activities or conditions.<VulnDiscussion>If inbound communications traffic is not continuously monitored for unusual/unauthorized activities or conditions, there will be times when hostile activity may not be noticed and defended against.
Although some of the components in the site's content scanning solution may be used for periodic scanning assessment, the IDPS sensors and other components must provide continuous, 24 hours a day, 7 days a week monitoring.
Unusual/unauthorized activities or conditions related to information system inbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, use of unusual protocols and ports, and communications with suspected or known malicious external entities.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-002661Configure access control rules to block non-compliant traffic.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy configured for intrusion inspection using access control rules.
Step 3: Click the edit icon next to the rule you want to edit. The access control rule editor appears.
Step 4: Set the rule action to Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Select a system-provided or custom intrusion policy.
Step 7: Click Save to save the rule.
---------------------------------------------------
Configure the ASA to redirect all traffic to the FirePOWER module in inline mode as shown in the example below.
Step 1: Configure access list for all traffic.
ASA1(config)# access-list FIREPOWER_REDIRECT extended permit ip any any
Step 2: Create a class-map in order to match the traffic on an access list.
ASA1(config)# class-map FIREPOWER_SFR
ASA1(config-cmap)# match access-list FIREPOWER_REDIRECT
Step 3: Configure deployment mode as inline.
ASA1(config)# policy-map global_policy
ASA1(config-pmap)# class FIREPOWER_SFR
ASA1(config-pmap-c)# sfr fail-openVerify that an intrusion policy has been applied to access control rules.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy configured for intrusion inspection using access control rules.
Step 3: Click the edit icon next to the rule you want to view. The access control rule editor appears.
Step 4: Verify that the rule action is set to Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Verify that a system-provided or custom intrusion policy has been selected.
Note: An access control policy can have multiple access control rules associated with intrusion policies.
---------------------------------------------------
Verify that the ASA is configured to redirect all traffic to the FirePOWER service module.
Step 1: Verify that the FirePOWER service module has been deployed in inline mode as shown in the example below.
policy-map global_policy
class FIREPOWER_SFR
sfr fail-open
Step 2: Verify that all traffic is redirected.
access-list FIREPOWER_REDIRECT extended permit ip any any
…
…
…
class-map FIREPOWER_SFR
match access-list FIREPOWER_REDIRECT
Note: Inbound and outbound traffic that is allowed by the ASA firewall is forwarded to the FirePOWER module. If the Cisco ASA FirePOWER module is configured in inline mode, the packet is inspected and dropped if it does not conform to access control policies. If the packet is compliant with access control policies, it is sent back to the ASA firewall for processing.
If the ASA is not configured to block inbound traffic containing unauthorized activities or conditions, this is a finding.SRG-NET-000391-IDPS-00213<GroupDescription></GroupDescription>CASA-IP-000510The Cisco ASA must be configured to block outbound traffic containing unauthorized activities or conditions.<VulnDiscussion>If outbound communications traffic is not continuously monitored for unusual/unauthorized activities or conditions, there will be times when hostile activity may not be noticed and defended against.
Although some of the components in the site's content scanning solution may be used for periodic scanning assessment, the IDPS sensors and other components must provide continuous, 24 hours a day, 7 days a week monitoring.
Unusual/unauthorized activities or conditions related to information system outbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, use of unusual protocols and ports, and communications with suspected or known malicious external entities.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-002662Configure access control rules to block non-compliant traffic.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy configured for intrusion inspection using access control rules.
Step 3: Click the edit icon next to the rule you want to edit. The access control rule editor appears.
Step 4: Set the rule action to Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Select a system-provided or custom intrusion policy.
Step 7: Click Save to save the rule.
---------------------------------------------------
Configure the ASA to redirect all traffic to the FirePOWER module in inline mode as shown in the example below.
Step 1: Configure access list for all traffic.
ASA1(config)# access-list FIREPOWER_REDIRECT extended permit ip any any
Step 2: Create a class-map in order to match the traffic on an access list.
ASA1(config)# class-map FIREPOWER_SFR
ASA1(config-cmap)# match access-list FIREPOWER_REDIRECT
Step 3: Configure deployment mode as inline.
ASA1(config)# policy-map global_policy
ASA1(config-pmap)# class FIREPOWER_SFR
ASA1(config-pmap-c)# sfr fail-openVerify that an intrusion policy has been applied to access control rules.
Step 1: Navigate to Configuration >> ASA FirePOWER Configuration >> Policies >> Access Control Policy. The Access Control Policy page appears.
Step 2: Click the edit icon next to the access control policy configured for intrusion inspection using access control rules.
Step 3: Click the edit icon next to the rule you want to view. The access control rule editor appears.
Step 4: Verify that the rule action is set to Interactive Block or Interactive Block with reset.
Step 5: Select the Inspection tab. The Inspection tab appears.
Step 6: Verify that a system-provided or custom intrusion policy has been selected.
Note: An access control policy can have multiple access control rules associated with intrusion policies.
---------------------------------------------------
Verify that the ASA is configured to redirect all traffic to the FirePOWER service module.
Step 1: Verify the FirePOWER service module has been deployed in inline mode as shown in the example below.
policy-map global_policy
class FIREPOWER_SFR
sfr fail-open
Step 2: Verify all traffic is redirected.
access-list FIREPOWER_REDIRECT extended permit ip any any
…
…
…
class-map FIREPOWER_SFR
match access-list FIREPOWER_REDIRECT
Note: Inbound and outbound traffic that is allowed by the ASA firewall is forwarded to the FirePOWER module. If the Cisco ASA FirePOWER module is configured in inline mode, the packet is inspected and dropped if it does not conform to access control policies. If the packet is compliant with access control policies, it is sent back to the ASA firewall for processing.
If the ASA is not configured to block outbound traffic containing unauthorized activities or conditions, this is a finding.SRG-NET-000392-IDPS-00214<GroupDescription></GroupDescription>CASA-IP-000520The Cisco ASA must be configured to send an alert to organization-defined personnel and/or the firewall administrator when intrusion events are detected.<VulnDiscussion>Without an alert, security personnel may be unaware of intrusion detection incidents that require immediate action and this delay may result in the loss or compromise of information.
In accordance with CCI-001242, the IDPS is a real-time intrusion detection system. These systems must generate an alert when detection events from real-time monitoring occur. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS 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 administrator and/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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-002664Configure email server and email addresses to send alerts to organization-defined personnel and/or the firewall administrator.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: From the Create Alert drop-down menu, choose Create Email Alert.
Step 3: Enter a Name for the alert response. In the To field, enter the email addresses where you want to send alerts, separated by commas. In the From field, enter the email address that you want to appear as the sender of the alert. Next to Relay Host, click Edit to enter mail server.
Step 4: Click Save.Verify email server and email addresses have been defined.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: From the Create Alert drop-down menu, choose Create Email Alert.
Step 3: Verify that the email address is that of organization-defined personnel and/or the firewall administrator.
If the Cisco ASA is not configured to send an alert to organization-defined personnel and/or the firewall administrator when intrusion events are detected, this is a finding.SRG-NET-000392-IDPS-00215<GroupDescription></GroupDescription>CASA-IP-000530The Cisco ASA must be configured to send an alert to organization-defined personnel and/or the firewall administrator when threats are detected.<VulnDiscussion>Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded.
Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS 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 administrator and/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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-002664Configure email server and email addresses to send alerts to organization-defined personnel and/or the firewall administrator.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: From the Create Alert drop-down menu, choose Create Email Alert.
Step 3: Enter a Name for the alert response. In the To field, enter the email addresses where you want to send alerts, separated by commas. In the From field, enter the email address that you want to appear as the sender of the alert. Next to Relay Host, click edit to enter mail server.
Step 4: Click Save.Verify email server and email addresses have been defined.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: From the Create Alert drop-down menu, choose Create Email Alert.
Step 3: Verify that the email address is that of organization-defined personnel and/or the firewall administrator.
If the Cisco ASA is not configured to send an alert to organization-defined personnel and/or firewall administrator when threats are detected, this is a finding.SRG-NET-000392-IDPS-00218<GroupDescription></GroupDescription>CASA-IP-000560The Cisco ASA must be configured to send an alert to organization-defined personnel and/or the firewall administrator when DoS incidents are detected.<VulnDiscussion>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.
CJCSM 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 I, II, IV, and VII detection events) will require an alert when an event is detected.
Alerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.
Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS 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 administrator and/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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-002664Configure email server and email addresses to send alerts to organization-defined personnel and/or the firewall administrator.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: From the Create Alert drop-down menu, choose Create Email Alert.
Step 3: Enter a Name for the alert response. In the To field, enter the email addresses where you want to send alerts, separated by commas. In the From field, enter the email address that you want to appear as the sender of the alert. Next to Relay Host, click edit to enter mail server.
Step 4: Click Save.Verify email server and email addresses have been defined.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: From the Create Alert drop-down menu, choose Create Email Alert.
Step 3: Verify that the email address is that of organization-defined personnel and/or the firewall administrator.
If the Cisco ASA is not configured to send an alert to organization-defined personnel and/or the firewall administrator when DoS incidents are detected, this is a finding.SRG-NET-000392-IDPS-00219<GroupDescription></GroupDescription>CASA-IP-000570The Cisco ASA must generate an alert to organization-defined personnel and/or the firewall administrator when active propagation of malware or malicious code is detected.<VulnDiscussion>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.
CJCSM 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 I, II, IV, and VII detection events) will require an alert when an event is detected.
Alerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.
Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Cisco ASA IPSDISADPMS TargetCisco ASA IPS5341CCI-002664Configure email server and email addresses to send alerts to organization-defined personnel and/or the firewall administrator.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: From the Create Alert drop-down menu, choose Create Email Alert.
Step 3: Enter a Name for the alert response. In the To field, enter the email addresses where you want to send alerts, separated by commas. In the From field, enter the email address that you want to appear as the sender of the alert. Next to Relay Host, click edit to enter mail server.
Step 4: Click Save.Verify email server and email addresses have been defined.
Step 1: Navigate to Policies >> Actions >> Alerts.
Step 2: From the Create Alert drop-down menu, choose Create Email Alert.
Step 3: Verify that the email address is that of organization-defined personnel and/or the firewall administrator.
If the Cisco ASA is not configured to send an alert to organization-defined personnel and/or the firewall administrator when active propagation of malware or malicious code is detected, this is a finding.