This procedure describes how to add a Cisco device managed by a Cisco CSM. You must add each Cisco device or security context that is managed by a Cisco CSM separately, even if they are managed by the same CSM.
Note: To perform this procedure, you must have a Cisco API license for the CSM device.
Select the baseline compliance profile to use, in order to enable generation of Baseline Compliance Reports for this device.
The drop-down list includes all baseline compliance profiles in the system. For more information on baseline compliance profiles and instructions for adding new baseline compliance profiles, see Customize baseline configuration profiles
Select None to disable Baseline Compliance Report generation for this device.
Specify how AFA should acquire the device's routing information:
Automatic. AFA will automatically generate the device's routing information upon analysis or monitoring.
Static Routing Table (URT). AFA will take the device's routing information from a static file you provide. For more information, see Specify routing data manually.
Specify the log collection method that AFA should use when collecting traffic logs for the Cisco device, by selecting one of the following:
Hit-counters: Only use hit-counter data. The Change History report page will be based on "last modified" timestamps, and Intelligent Policy Tuner is disabled.
Standard: Use hit-counter data for rule usage, and Syslog data for the Change History report page. Intelligent Policy Tuner is disabled.
Extensive: Combine data from both hit-counters and Syslog. Intelligent Policy Tuner is enabled.
The default value is Extensive.
Note: The Extensive method is only available when the ADSM is selected in the Rules view area.
Syslog-ng server
If you selected Standard or Extensive in the Log collection method field, you must specify the syslog-ng server. For details, see Specify a Syslog-ng server.
Additional firewall identifiers
Type any additional IP addresses or host names that identify the device. When adding multiple entries, separate values by a ':'. For example: "1.1.1.1:2.2.2.2:ServerName".
This is relevant when the device is represented by multiple or non-standard device identifiers in the logs, for example, in cases of firewall clusters or non-standard logging settings. If AFA receives logs with an identifier it does not recognize, the logs will not be processed.
Note: This field is only relevant for the parent device. In order to specify additional identifiers for sub-systems (Juniper VSYS/LSYS, Fortinet VDOM, Cisco security context, etc.), see Add additional device identifiers for sub-systems.
Log collection frequency (minutes)
Type the interval of time in minutes, at which AFA should collect logs for the device.
Select this option to include risk analysis and policy optimization analysis in the device's reports.
When this is not selected, AFA produces condensed router reports which run as if there is no license for risks, optimization or regulatory compliance. Reports still include policy changes and baseline compliance.
This option is disabled by default.
Note: Selecting this option will increase the analysis time for this router significantly and might result in performance degradation.
Automatically add/remove VRF instances upon detection (Applies for all Cisco Routers)
Select this option to enable automatic updating of VRF instances for all Cisco routers defined in AFA.
The updates will be reflected in the device tree and graphic network map, and the updates will affect the device license usage.
To specify a custom port, select this option and type the port.
This option is only relevant when SSH is selected.
Number of allowed encryption keys
Enter the permitted number of different RSA keys received from this device's IP address.
Different RSA keys may be sent from the same IP address in cases of cluster fail-over, device operating system upgrades, etc. For example, if a cluster fail-over occurs, the secondary node will send a new RSA key from the same IP address to AFA. If this number is set to 1, the connection to the node will fail, resulting in a failed analysis.
Specify how AFA should acquire the device's routing information:
Automatic. AFA will automatically generate the device's routing information upon analysis or monitoring.
Static Routing Table (URT). AFA will take the device's routing information from a static file you provide. For details, see Specify routing data manually.
Select this option to enable FireFlow to generate CLI recommendations and push them to the device.
Checking this box will enable ActiveChange for all the supported Cisco firewalls, Cisco IOS routers, and Juniper SRX firewalls (not only for this device).
Select this option to include risk analysis and policy optimization analysis in the device's reports.
When this is not selected, AFA produces condensed router reports which run as if there is no license for risks, optimization or regulatory compliance. Reports still include policy changes and baseline compliance.
This option is disabled by default.
Note: Selecting this option will increase the analysis time for this router significantly and might result in performance degradation.
Automatically add/remove VRF instances upon detection (Applies for all Cisco Routers)
Select this option to enable automatic updating of VRF instances for all Cisco routers defined in AFA.
The updates will be reflected in the device tree and graphic network map, and the updates will affect the device license usage.
Specify how AFA should acquire the device's routing information:
Automatic. AFA will automatically generate the device's routing information upon analysis or monitoring.
Static Routing Table (URT). AFA will take the device's routing information from a static file you provide. For more details, see Specify routing data manually.
Note: All references in the ASMSTech Docs to Cisco ASA devices also refer to legacy PIX and FWSM devices. To add a new PIX or FWSM device to AFA, select ASA options.
When ActiveChange is enabled, ASMS requires a user with read-write permissions and is able to enter privileged mode, using enable credentials (security level 15).
ASMS supports the ability to collect logs either by receiving Syslog messages from the device, or by collecting Syslog messages from a remote Syslog-ng server.
In either case, make sure that your Cisco ASA device is configured to send CISCO 106100 SYSLOG events to ASMS.
For example:
%FWSM-6-106100: access-list acl_ID {permitted | denied | est-allowed} protocol interface_name/source_address(source_port) -> interface_name/dest_address(dest_port) hit-cnt number ({first hit | number-second interval})
These messages are logged when packets match an ACL statement, if you have the log option for the access-list command configured. The message level depends on the level defined for the access-list command. By default, this level 6.
Note: Intelligent Policy Tuner analysis is supported for Cisco ASA versions 7.1 and higher.
To use this feature, the device must send correct log messages, in type 106100, and the device's ACLs must contain the keyword log.
Enter the user name to use for SSH access to the device.
Note: AFA partially supports user awareness for Cisco ASA devices. The network user appears as a field for each rule in the Policy tab, but is not used in traffic simulation queries.
Password
Enter the password to use for SSH access to the device.
Note: For Cisco ASA devices enabled for CyberArk, the Password and Enable User Password must be the same.
Enable User Password
Enter the enable user password to use:
noenable. Skip running the enable command.
Algosec_no_passwd. The enable password is empty.
Leave the field empty. AFA will issue a login command instead of the enable command, using the same password provided for the SSH connection.
Note: For Cisco ASA devices enabled for CyberArk, the Password and Enable User Password must be the same.
Retrieve credentials from CyberArk vault
Select to authenticate the device with a CyberArk Vault instead of saving the device credentials on the AlgoSec server.
When selected, also enter the following CyberArk details for the device being authenticated:
Platform (Policy ID)
Safe
Folder
Object
Note: These options only appear when CyberArk is configured in AFA. For details, see Integrate AFA and CyberArk.
Select the remote agent that should perform data collection for the device.
To specify that the device is managed locally, select Central Manager.
Note: This field is only relevant when a Geographic Distribution architecture is configured. For more details, see Configure a distributed architecture.
Select one of the following methods to collect data:
SSH (recommended)
Telnet
Then define:
Custom Port
To specify a custom port, select this option and type the port.
This option is only relevant when SSH is selected.
Number of allowed encryption keys
Enter the permitted number of different RSA keys received from this device's IP address.
Different RSA keys may be sent from the same IP address in cases of cluster fail-over, device operating system upgrades, etc.
For example, if a cluster fail-over occurs, the secondary node will send a new RSA key from the same IP address to AFA. If this number is set to 1, the connection to the node will fail, resulting in a failed analysis.
Specify how AFA should acquire the device's routing information:
Automatic. AFA will automatically generate the device's routing information upon analysis or monitoring.
Static Routing Table (URT). AFA will take the device's routing information from a static file you provide. For more details, see Specify routing data manually.
Enter any additional IP addresses or host names that identify the device. When adding multiple entries, separate values by a colon (:).
For example: 1.1.1.1:2.2.2.2:ServerName.
This is relevant when the device is represented by multiple or non-standard device identifiers in the logs, for example, in cases of firewall clusters or non-standard logging settings. If AFA receives logs with an identifier it does not recognize, the logs will not be processed.
Select this option to enable FireFlow to generate CLI recommendations and push them to the device.
Checking this box will enable ActiveChange for all the supported Cisco firewalls, Cisco IOS routers, and Juniper SRX firewalls (not only for this device).
This procedure describes how to connect Cisco ACI devices to AFA. AFA always connects to Cisco ACI devices via REST.
Note:
(1) If defined Cisco ACI users have the following minimum privileges, they can perform all ASMS functionality:
tenant-connectivity
tenant-epg
tenant-ext-connectivity
tenant-security
(2) To identify service graph data in queries and change requests, you must specifically configure AFA to recognize that data. For details, see Configure support for Cisco service graphs.
Tip: Typically, your APIC cluster has three nodes. Specify the host name or IP address of only one of the APIC nodes.
If the node you added goes down, you'll need to switch your AFA device configuration to another node. Edit the device configuration in AFA and enter the host name or IP address of that second node.
Select this option to enable FireFlow to generate CLI recommendations and push them to the device.
Checking this box will enable ActiveChange for all the supported Cisco firewalls, Cisco IOS routers, and Juniper SRX firewalls (not only for this device).
If you want to be able to identify service graph data in queries and change requests, you must specifically configure AFA to recognize that data.
Do the following:
Ensure that your device has the following vendor property definition: fip_additional_devices_set_support = yes.
This parameter is set to yes by default, and is defined in the /home/afa/.fa/config file.
Create a CSV file named devicesSetDefinition.csv. Save this file on the AFA machine, in the /home/afa/.fa/ directory.
Populate the devicesSetDefinition.csv file with tenant, service graph, and device mapping data, as shown in the following example:
Tenant Name
Service Graph Redirect Name
Devices
Jasmine_ACI
SG_HTTP_S
CKP1, F51
Jasmine_ACI
SG_HTTP3
PAN1
Flower_ACI
SG_eCommerce
PAN1, PAN2
Begal_ACI
SG_2
FP1, F52
Begal_ACI
SG_SQL
FP1, F52
Note: In this file, device names must be exact matches to the names used to identify the devices in ASMS.
Create another CSV file, in the same /home/afa/.fa/, named devicesSetConnection.csv.
In the devicesSetConnection.csv file, define the network logic used to define the service graph redirect. Use source and destination addresses, as shown in the following example:
Source
Destination
Tenant Name
Service Graph Redirect Name
10.1.0.0 -10.1.0.255.255
10.2.1.6
Jasmine_ACI
SG_HTTP_S
10.1.0.0 -10.1.0.255.255
10.2.1.6
Jasmine_ACI
SG_HTTP_S
10.1.1.3
10.2.1.6
Jasmine_ACI
SG_HTTP3
10.5.7.3-10.5.7.8
10.9.1.5
Flower_ACI
SG_eCommerce
192.1.1.3
192.2.1.6
Begal_ACI
SG_2
0.0.0.0-255.255.255.255
10.3.1.1
Begal_ACI
SG_SQL
Service graph data is now recognized in AFA queries and FireFlow change requests.
Tip: Alternately, advanced administrators can configure a script that resolves service graph redirects based on any custom logic using FireFlow ticket fields as parameters.
We recommend contacting AlgoSec professional services to configure this sort of custom logic.
By default, AFA query results include ACI tenants with either of the following criteria:
ACI tenants with a BD that intersects with the query source or destination
ACI tenants where one or more of the tenant’s VRFs is included in the query path
ASMS administrators can configure AFA to identify ACI tenants only when the tenant's VRF is included in the query path. Do the following:
On your AFA machine, browse to and open the devicedriver-cisco-aci.properties file for editing. This file is located in the /data/algosec-ms/config directory on your AFA machine.
Update the devicedriver.cisco.aci.protectedCloudHostsEnabled parameter value to false.
Note: AFA automatically identifies Cisco Firepower devices in service-chaining mode if the device has only a single interface.
If your device has multiple interfaces and service-chaining mode is not identified automatically, configure this for your device manually. For more details, see Configure one-armed mode manually.
Network connectivity
The following diagram shows an ASMS Central Manager or Remote Agent connecting to a Cisco Firepower device:
Device permissions
ASMS requires the following device permissions to connect to Cisco Firepower devices:
The Cisco Firepower system includes both the Firepower Management Center (FMC) and the Firepower Threat Defense (FTD) firewalls.
AFA manges the FMC directly, mainly supporting the FTD via the FMC API. In addition, AFA collects routing and baseline compliance data directly from the FTD via SSH.
Therefore, AFA must have both of the following access rights:
API (HTTPS) access to the FMC
SSH access to the FTD. AFA does not support direct access to the FDM API.
To connect to your device, ASMS requires a user with Administrator role that is:
Dedicated for ASMS. Connecting to the device using any other user may cause that user to be logged out of the Firepower UI at each monitoring cycle, as well as for any changes made to the Firepower device via ASMS.
In the Global domain
For example:
Note: The Administrator level role is required due to FMC limitations for fetching Audit logs.
Enter the username to use for SSH access to the FMC device.
Note: AFA does not support user or network application awareness for Cisco Firepower. The network application appears as a field for each rule in the Policy tab, but is not used in traffic simulation queries.
Password
Enter the password to use for SSH access to the FMC device.
AFA automatically identifies Cisco Firepower devices in one-armed mode, when the device has a single interface. If your device has multiple interfaces and one-armed mode is not identified automatically, configure this for your device manually.
Do the following:
On the AFA machine, access your device configuration meta file as follows:
/home/afa/.fa/firewalls/<device_name>/fwa.meta
where <device_name> is the name of the device listed. If you device is listed multiple times, enter the longer name.
On a new line, enter:
is_steering_device=yes
Run an analysis on the device to update the device data in AFA.