Onboard Devices and Services
Secure Device Connector
Supported Devices, Software, and Hardware
- Secure Firewall Threat Defense Device Support Specifics
Onboard FDM-Managed Device

Onboard Devices and Services

You can onboard both live devices and model devices to Security Cloud Control. Model devices are uploaded configuration files that you can view and edit using Security Cloud Control.

Most live devices and services require an open HTTPS connection so that the Secure Device Connector can connect Security Cloud Control to the device or service.

This chapter covers the following sections:

Secure Device Connector

The Secure Device Connector (SDC) is an intelligent proxy that allows your Cisco devices to communicate with Security Cloud Control. When onboarding a device that is not directly reachable over the internet to Security Cloud Control using device credentials, you can deploy an SDC in your network to proxy communications between the devices and Security Cloud Control. Alternatively, if you prefer, you can enable a device to receive direct communications through its outside interface from Security Cloud Control.

Adaptive Security Appliances (ASA), Meraki MXs, Secure Firewall Management Center devices, and generic SSH and IOS devices can be onboarded to Security Cloud Control using an SDC. Secure Firewall Threat Defense devices managed by Cloud-Delivered Firewall Management Center do not require onboarding using an SDC and do not support onboarding through proxies. Ensure that the threat defense devices have proper DNS settings and outbound internet connectivity to connect to Cloud-Delivered Firewall Management Center. For more information, see Onborading Overview.

The SDC monitors Security Cloud Control for commands that need to be executed on your managed devices, and messages that need to be sent to your managed devices. The SDC executes the commands on behalf of Security Cloud Control, sends messages to Security Cloud Control on behalf of the managed devices, and returns replies from the managed devices to Security Cloud Control.

The SDC uses secure communication messages signed and encrypted using AES-128-GCM over HTTPS (TLS 1.3) to communicate with Security Cloud Control. All credentials for onboarded devices and services are encrypted directly from the browser to the SDC as well as encrypted at rest using AES-128-GCM. Only the SDC has access to the device credentials. No other Security Cloud Control service has access to the credentials.

See Connect Security Cloud Control to your Managed Devices for information explaining how to allow communication between an SDC and Security Cloud Control.

The SDC can be installed on any Ubuntu instance. For convenience, we provide an OVA for a hardened Ubuntu 22 instance which includes the SDC CLI pre-installed. The CLI helps you configure your VM, install all required system packages, and bootstrap the SDC as a Docker container on the host. Alternatively, you can roll your own Ubuntu instance (versions 20 through 24 are currently tested) and download the CLI separately.

Each Security Cloud Control tenant can have an unlimited number of SDCs. These SDCs are not shared between tenants, they are dedicated to a single tenant. The number of devices a single SDC can manage depends on the features implemented on those devices and the size of their configuration files. For the purposes of planning your deployment, however, expect one SDC to support approximately 500 devices.

Deploying more than one SDC for your tenant also provides these benefits:

You can manage more devices with your Security Cloud Control tenant without experiencing performance degradation.
You can deploy an SDC to an isolated network segment within your network and still manage the devices in that segment with the same Security Cloud Control tenant. Without multiple SDCs, you would need to manage the devices in those isolated network segments with different Security Cloud Control tenants.

Multiple SDCs can run on a single host, follow the bootstrap procedure for each SDC you want to run. The initial SDC on your tenant incorporates the name of your tenant and the number 1 and is displayed on the Secure Connectors tab in the Services page of Security Cloud Control. Each additional SDC is numbered in order.

For more information, see Deploy a VM for Running the Secure Device Connector and Secure Event Connector.

Connect Security Cloud Control to your Managed Devices

Security Cloud Control connects to the devices that it manages through the cloud connector or through a Secure Device Connector (SDC).

If your device can be accessed directly from the internet, you should be using the cloud connector to connect to your device. If you can, configure the device to allow inbound access on port 443 from the Security Cloud Control IP addresses in your cloud region.

If your device is not accessible from the internet, you can deploy an on-premises SDC in your network to allow Security Cloud Control to communicate with your devices.

Configure the device to allow full inbound access from your device subnets/IPs on port 443 (or whichever port you have configured for your device management).

An FDM-managed device can be onboarded to Security Cloud Control using its device credentials, a registration key, or its serial number whether it is directly accessible from the internet. If the FDM-managed device does not have direct access to the internet, but it resides on a network that does; the Security Services Exchange connector delivered as part of the device can reach the Security Services Exchange cloud allowing the FDM-managed device to be onboarded.

You need an on-premises SDC in your network to onboard:

An FDM-managed device that is not accessible from the cloud and the credentials onboarding method is used.

All other devices and services do not require an on-premise SDC as Security Cloud Control will connect using its cloud connector. See the next section to know the IP addresses that must be allowed for inbound access.

Connecting Devices to Security Cloud Control Through the Cloud Connector

When connecting Security Cloud Control directly to your device through the cloud connector, you should allow inbound access on port 443 (or whichever port you have configured for your device management) for the various IP addresses in the EMEA, United States, or APJ region.

If you are a customer in the Asia-Pacific-Japan (APJ) region, and you connect to Security Cloud Control at https://apj.manage.security.cisco.com, allow inbound access from the following IP addresses:

54.199.195.111
52.199.243.0

If you are a customer in the Australia (AUS) region, and you connect to Security Cloud Control at https://aus.manage.security.cisco.com, allow inbound access from the following IP addresses:

13.55.73.159
13.238.226.118

If you are a customer in Europe, the Middle East, or Africa (EMEA) region, and you connect to Security Cloud Control at https://eu.manage.security.cisco.com, allow inbound access from the following IP addresses:

35.157.12.126
35.157.12.15

If you are a customer in the India (IN) region, and you connect to Security Cloud Control at https://in.manage.security.cisco.com, allow inbound access from the following IP addresses:

35.154.115.175
13.201.213.99

If you are a customer in the United States (US) region, and you connect to Security Cloud Control at https://us.manage.security.cisco.com, allow inbound access from the following IP addresses:

52.34.234.2
52.36.70.147

Connecting Security Cloud Control to SDC

When connecting Security Cloud Control to your device through an SDC, the devices you want Security Cloud Control to manage must allow full inbound access from your SDC host on port 443 (or whichever port you have configured for your device management). This is configured using a management access control rule.

You must also ensure that the virtual machine on which the SDC is deployed has network connectivity to the management interface of the managed device.

Deploy a VM for Running the Secure Device Connector and Secure Event Connector

When using device credentials to connect Security Cloud Control to a device, it is a best practice to download and deploy an SDC in your network to manage the communication between Security Cloud Control and the device. Typically, these devices are nonperimeter based and do not have a public IP address, or have an open port to the outside interface.

The number of devices a single SDC can manage depends on the features that are implemented on those devices and the size of their configuration files. To plan your deployment, however, we expect one SDC to support approximately 500 devices. For more information, see Using Multiple SDCs on a Single Security Cloud Control Tenant.

This procedure describes how to install an SDC in your network, using Security Cloud Control's VM image. This is the recommended and most reliable way to create an SDC.

Before you begin

Security Cloud Control requires strict certificate checking and does not support Web or Content Proxy inspection between the Secure Device Connector (SDC) and the internet. If using a proxy server, disable inspection for traffic between the SDC and Security Cloud Control.
The SDC must have full outbound access to the internet on TCP port 443, or the port you have configured for device management.
The devices that are managed by Security Cloud Control must allow inbound traffic from the SDC VM’s IP address.
Review Connect Connect Security Cloud Control to your Managed Devices to the Secure Device Connector to ensure proper network access.
If you are using a proxy on your network, ensure that you have all the required details before running the host setup command. Most of the issues are related to incorrect proxy configurations. Important details are:
- The IP/hostname of your proxy.
- Whether or not your proxy intercepts traffic and reencrypts it using its own cert. This detail is the cause of most of the complications with the SDC VM setup.
  - If your proxy does intercept traffic, have the root certificate ready when configuring the VM. You can paste it in when prompted so that the host and the SDC know to trust the certificates generated by your proxy.
  - If your proxy does not intercept traffic, then nothing else is required here.
- The following items are most likely the same for proxied HTTP and HTTPS connections. However, if you use a different proxy for each protocol, you would need all of the following for each:
  - The IP address of your proxy
  - The port your proxy uses
  - Whether your proxy requires that the connection to the proxy itself be over HTTPS (typically not the case). For example, if the address of your proxy is listed as https://proxy.corp.com:80 then you would answer yes. If the listed address is http://proxy.corp.com:80 then you would answer no. Note that both URLs use port 80, but the protocol is different.
  - The authentication details of your proxy including:
    - Whether your proxy requires auth (most do not)
    - If yes, then you’ll need the username and password available when you configure the host.

Supported Installations

Security Cloud Control supports installing its SDC VM OVF image using the vSphere web client or the ESXi web client.
Security Cloud Control does not support installing the SDC VM OVF image using the vSphere desktop client.
Security Cloud Control supports installing the SDC on your own Ubuntu instance. Versions 20LTS - 24LTS are currently supported.
ESXi 5.1 hypervisor.

System Requirements

System requirements for a VM with one SDC:
- 2 vCPUs
- 2 GB of memory
- 64 GB of disk space
Each SDC you add to your host requires an additional 1 vCPU and 1 GB of RAM.
System requirements for a VM with one SEC (a component that is used in Cisco Security Analytics and Logging):
- 4 vCPUs minimum
- 8 GB of memory
Each SEC you add to the host requires doubling its resources, therefore, these are the requirements for a VMware ESXi host with one SDC and one SEC:
- 6 vCPUs
- 10 GB memory
- 64 GB of disk space

Prepare for Installation

To configure networking manually on the host, gather the following information:
- The static IP address that you want to use for your VM
- The passwords to use for the cdouser (or whichever user has sudo access) and the `sdc` user (the user under which Docker runs)
- The IP address of the DNS server your organization uses
- The gateway IP address of the network the SDC address is on
- The FQDN or IP address of your time/NTP server

The SDC virtual machine is configured to install security patches regularly and to do this, opening port 80 outbound is required.

If your network is using allow/deny lists for outbound connections, you need to allow connections to ubuntu.com so those security updates can be applied.

Note

Ubuntu secures its updates with checksums and only uses HTTP, not HTTPS. To pull security updates, you must allow HTTP connections to ubuntu.com.

Deploy the VM

There are two options for deploying the VM used to run the SDC and SEC.

Follow the steps below to download the VMware image provided by Security Cloud Control.
To deploy Ubuntu 20, 22, or 24 yourself. If deploying your own Ubuntu instance, you may skip the following section and proceed to the Configure the VM section.

Procedure

In the left pane, click Administration > Integrations > Secure Connectors.
Select the Secure Connectors tab on the Services page, click the blue plus button, and select Secure Device Connector.
Click Download the SDC VM image. This opens in a new tab.
Extract all the files from the .zip file. They look similar to these:
- CDO-SDC-VM-ddd50fa.ovf
- CDO-SDC-VM-ddd50fa.mf
- CDO-SDC-VM-ddd50fa-disk1.vmdk

Note

Do not use the ESXi Web Client.

Deploy the Secure Device Connector virtual machine from the OVF template by following the prompts.

When the setup is complete, power on the SDC VM.
Open the console for your new SDC VM.
Log in with the cdo username. The default password is adm123.

Configure the VM

Now you are able to bring up the console for the VM image you deployed (or SSH into it if you rolled your own and enabled SSH), you should run the configuration script to get your host ready to run the SDC or SEC Docker container(s).

If you downloaded the Security Cloud Control-provided VM, the CLI is already installed, and you can proceed to step 2. If you have deployed your own VM, SSH into it and run the command to install the CLI:
```
curl -O https://s3.us-west-2.amazonaws.com/download.defenseorchestrator.com/sdc-cli/sdc-cli-package-latest.tgz && tar -xvf sdc-cli-package-latest.tgz && chmod +x ./install.sh && ./install.sh
```
Start the host configuration by running the command:
```
sudo sdc host configure
```
When prompted for the password, enter adm123 for the Security Cloud Control-provided VM or whatever admin password you chose for your own VM.
Follow the prompts to configure the sdc user.
When prompted for the networking configuration, choose one of the following:
- Manually configure this host with a static IP: If you want to specify the IP, gateway, DNS server, and so on, for this host and write it to the system config on the VM.
- DHCP: If you have a DHCP server assigning static IPs to your VMs.
- Static IP is already configured and I don't want to change my networking now.
When prompted, answer the questions about your proxy configuration. Review the detailed list at the top of this topic for all the prerequisites and potential proxy configuration options.
If you have configured a proxy, you will be prompted to reboot the VM for all the proxy settings to take effect. If you did not, you will not be prompted to reboot and you can move on to step 8.
Set a custom internet access test URL. You only need to do this if you deny all outbound connections by default. If you do, then specify a publicly accessible web url such at https://google.com that is on your allow list.
Install the latest security patches, some requires os tools and Docker server.
When prompted, indicate whether you want to have the script harden your SSH configuration.

If using our VM, proceed. If you are using your own VM and configuring SSH yourself, you may want to skip this step to avoid changing your current configuration.
When prompted to enable automatic updates for the SDC or SEC and the CLI itself, it is recommended that you do this to stay up to date with bug fixes, patches, and new features. If your policies prevent you from allowing automatic updates, see Update your Secure Device Connector.

Deploy a Secure Device Connector On Your VM

When using device credentials to connect Security Cloud Control to a device, it is a best practice to download and deploy a Secure Device Connector (SDC) in your network to manage the communication between Security Cloud Control and the device. Typically, these devices are non-perimeter based, do not have a public IP address, or have an open port to the outside interface. Adaptive Security Appliances (ASAs), FDM-managed devices, and Firepower Management Centers (FMCs) devices can all be onboarded to Security Cloud Control using device credentials.

The number of devices a single SDC can manage depends on the features implemented on those devices and the size of their configuration files. For the purposes of planning your deployment, however, we expect one SDC to support approximately 500 devices. See Using Multiple SDCs on a Single Security Cloud Control Tenant for more information.

This procedure describes how to install an SDC in your network by using your own virtual machine image.

Note

The preferred, easiest, and most reliable way to install an SDC is to download Security Cloud Control's SDC OVA image and install it.

Before you begin

Security Cloud Control requires strict certificate checking and does not support a Web/Content Proxy between the SDC and the Internet.
The SDC must have full outbound access to the Internecdot on TCP port 443 in order for it to communicate with Security Cloud Control.
Devices that reach Security Cloud Control through the SDC must allow inbound access from the SDC on port 443.
Review Connect to Security Cloud Control Firewall Management using Secure Device Connector for networking guidelines.

VMware ESXi host installed with vCenter web client or ESXi web client.

Note

We do not support installation using the vSphere desktop client.

ESXi 5.1 hypervisor.
Ubuntu 22.04 and Ubuntu 24.04 operating system.
System requirements for a VM with only an SDC:
- VMware ESXi host needs 2 CPUs.
- VMware ESXi host needs a minimum of 2 GB of memory.
- VMware ESXi requires 64 GB disk space to support the virtual machine depending on your provisioning choice. This value assumes you are using Logical Volume Management (LVM) with the partition so you can expand required disk space as needed.
System requirements for a VM with an SDC and a single Secure Event Connector (SEC) for your tenant. (The SEC is a component used in Cisco Security Analytics and Logging).

Each SEC you add to the VMware ESXi host requires an additional 4 CPUs and an additional 8 GB of memory.

Therefore, these are the requirements for a VMware ESXi host with one SDC and one SEC:
- VMware ESXi host needs 6 CPU.
- VMware ESXi host needs a minimum of 10 GB of memory.
- VMware ESXi requires 64 GB disk space to support the virtual machine depending on your provisioning choice.
After you have updated the CPU and memory on the VM, power on the VM and ensure that the Secure Connectors page indicates that the SDC is in the "Active" state.
Users performing this procedure should be comfortable working in a Linux environment and using the vi visual editor for editing files.
If you are installing your on-premise SDC on a CentOS virtual machine, we recommend you install Yum security patches on a regular basis. Depending on your Yum configuration, to acquire Yum updates, you may need to open outbound access on port 80 as well as 443. You will also need to configure yum-cron or crontab to schedule the updates. Work with your security-operations team to determine if any security policies need to change to allow you to get the Yum updates.

Note

Before you get started: Do not copy and paste the commands in the procedure into your terminal window, type them instead. Some commands include an "n-dash" and in the cut and paste process, these commands can be applied as an "m-dash" and that may cause the command to fail.

Procedure

Step 1

Log on to the Security Cloud Control tenant you are creating the SDC for.

Step 2

In the left pane, click Administration > Integrations > Secure Connectors.

Step 3

On the Services page, select the Secure Connectors tab, click the blue plus button, and select Secure Device Connector.

Step 4

Copy the bootstrap data in step 2 on the window to a notepad.

Step 5

Install a CentOS 7 virtual machine with at least the following RAM and disk space allotted to the SDC:

8GB of RAM
10GB disk space

Step 6

Once installed, configure basic networking such as specifying the IP address for the SDC, the subnet mask, and gateway.

Step 7

Configure a DNS (Domain Name Server) server.

Step 8

Configure a NTP (Network Time Protocol) server.

Step 9

Install an SSH server on CentOS for easy interaction with SDC's CLI.

Step 10

Run a Yum update and then install the packages: open-vm-tools, nettools, and bind-utils

[root@sdc-vm ~]# yum update -y 
               [root@sdc-vm ~]# yum install -y open-vm-tools net-tools bind-utils

Step 11

Install the AWS CLI package; see https://docs.aws.amazon.com/cli/latest/userguide/awscli-install-linux.html.

Note

Do not use the --user flag.

Step 12

Install the Docker CE packages; see https://docs.docker.com/install/linux/docker-ce/centos/#install-docker-ce

Note

Use the "Install using the repository" method.

Step 13

Start the Docker service and enable it to start on boot:


 [root@sdc-vm ~]# systemctl start docker
 [root@sdc-vm ~]# systemctl enable docker
 Created symlink from /etc/systemd/system/multiuser.target.wants/docker.service to
     /usr/lib/systemd/system/docker.service.

Step 14

Create two users: cdo and sdc. Use the cdo user to perform administrative tasks without directly accessing the root user. The sdc user will be designated for running the SDC docker container.


  [root@sdc-vm ~]# useradd cdo
  [root@sdc-vm ~]# useradd sdc –d /usr/local/cdo

Step 15

Set a password for the sdc user.


  [root@sdc-vm ~]# passwd cdo
  Changing password for user cdo.
  New password: <type password> 
  Retype new password: <type password> 
  passwd: all authentication tokens updated successfully.

Step 16

Add the sdc user to the wheel group to give it administrative (sudo) privileges.


   [root@sdc-vm ~]# usermod -aG wheel cdo 
   [root@sdc-vm ~]#

Step 17

When Docker is installed, there is a user group created. Depending on the version of CentOS/Docker, this may be called either "docker" or "dockerroot". Check the /etc/group file to see which group was created, and then add the sdc user to this group.


  [root@sdc-vm ~]# grep docker /etc/group
   docker:x:993:
  [root@sdc-vm ~]#
  [root@sdc-vm ~]# usermod -aG docker sdc
  [root@sdc-vm ~]#

Step 18

If the /etc/docker/daemon.json file does not exist, create it, and populate with the contents below. Once created, restart the docker daemon.

Note

Make sure that the group name entered in the "group" key matches the group you found in the /etc/group file the previous step.

[root@sdc-vm ~]# cat /etc/docker/daemon.json
         {
            "live-restore": true,
            "group": "docker"
         }
         [root@sdc-vm ~]# systemctl restart docker 
         [root@sdc-vm ~]#

Step 19

If you are currently using a vSphere console session, switch over to SSH and log in with thecdo user. Once logged in, change to the sdc user. When prompted for a password, enter the password for the cdo user.

[CDO@sdc-vm ~]$ sudo su sdc
               [sudo] password for cdo: <type password for cdo user>
               [sdc@sdc-vm ~]$

Step 20

Change directories to /usr/local/CDO.

Step 21

Create a new file called bootstrapdata and paste the bootstrap data from Step 2 of the Deploy an On-Premises Secure Device Connector wizard into this file. Save the file. You can use vi or nano to create the file.

Step 22

The bootstrap data comes encoded in base64. Decode it and export it to a file called extractedbootstrapdata

[sdc@sdc-vm ~]$ base64 -d /usr/local/ CDO/bootstrapdata > /usr/local/CDO/extractedbootstrapdata
              [sdc@sdc-vm ~]$

Run the cat command to view the decoded data. The command and decoded data should look similar to this:

[sdc@sdc-vm ~]$ cat /usr/local/ CDO/extractedbootstrapdata
               CDO_TOKEN="<token string>"
               CDO_DOMAIN="www.defenseorchestrator.com"
               CDO_TENANT="<tenant-name>"
               CDO_BOOTSTRAP_URL="https://www.defenseorchestrator.com/sdc/bootstrap/tenant-name/<tenant-name-SDC>"

Step 23

Run the following command to export the sections of the decoded bootstrap data to environment variables.

[sdc@sdc-vm ~]$ sed -e 's/^/export /g' extractedbootstrapdata > sdcenv && source sdcenv
              [sdc@sdc-vm ~]$

Step 24

Download the bootstrap bundle from Security Cloud Control.

[sdc@sdc-vm ~]$ curl -O -H "Authorization: Bearer $CDO_TOKEN" "$CDO_BOOTSTRAP_URL"
               100 10314 100 10314 0 0 10656 0 --:--:-- --:--:-- --:--:-- 10654
               [sdc@sdc-vm ~]$ ls -l /usr/local/ CDO/*SDC
               -rw-rw-r--. 1 sdc sdc 10314 Jul 23 13:48 /usr/local/CDO/tenant-name-SDC

Step 25

Extract the SDC tarball, and run the bootstrap.sh file to install the SDC package.

[sdc@sdc-vm ~]$ tar xzvf /usr/local/CDO/tenant-name-SDC
               <snipped – extracted files>
               [sdc@sdc-vm ~]$
               [sdc@sdc-vm ~]$ /usr/local/ CDO/bootstrap/bootstrap.sh
               [2018-07-23 13:54:02] environment properly configured
               download: s3://onprem-sdc/toolkit/prod/toolkit.tar to toolkit/toolkit.tar
               toolkit.sh
               common.sh
               [2018-07-23 13:54:04] startup new container
               Unable to find image 'ciscodefenseorchestrator/sdc_prod:latest' locally
               sha256:d98f17101db10e66db5b5d6afda1c95c29ea0004d9e4315508fd30579b275458: Pulling from
               ciscodefenseorchestrator/sdc_prod
               08d48e6f1cff: Pull complete
               ebbd10b629b1: Pull complete
               d14d580ef2ed: Pull complete
               45421d451ab8: Pull complete
               <snipped – downloads>
               no crontab for sdc

The SDC should now show "Active" in Security Cloud Control.

What to do next

Return to Install a Secure Event Connector on an SDC Virtual Machine if you are installing a Secure Event Connector.
Return to Install Multiple SECs for your tenant, if you are installing your second or more Secure Event Connectors on your tenant.

Bootstrap a Secure Device Connector on the Deployed Host

Procedure

Step 1	In the left pane, click Administration > Integrations > Secure Connectors.
Step 2	On the Services page, select the Secure Connectors tab, click the + icon, and select Secure Device Connector.
Step 3	Copy the bootstrap data in step 2 on the window to a notepad.
Step 4	SSH into your VM using the admin user, typically `cdo`, and your chosen password.
Step 5	Switch to the `sdc` user using the command: `sudo su - sdc`
Step 6	Bootstrap your new SDC using the command: `sdc bootstrap <paste-your-bootstrap-data-here>`
Step 7	Select the version of the SDC you want to use. We have three options for the SDC version: SDC 2024- This is the version that most will want to run. SDC 2024 with FIPS enabled- Choose this version if you are subject to FedRamp compliance. SDC Legacy- This version is no longer receiving feature updates and it is recommended to run SDC 2024 instead.
Step 8	The CLI pulls the container image and starts the SDC and you can validate that your SDC is active and operational on the user interface, and also on the host by running: `sdc show running`

You should now see an SDC for your tenant.

Deploy a Secure Device Connector to vSphere Using Terraform

Before you begin

This procedure details how you can use the Security Cloud Control SDC Terraform module for vSphere in conjunction with the Security Cloud Control Terraform Provider to deploy an SDC to your vSphere. Ensure you review the following prerequisites before attempting to perform this task procedure:

You have vSphere datacenter version 7 and above
You have an admin account on the datacenter with permissions to do the following:
- Create VMs
- Create folders
- Create content libraries
- Upload files to content libraries
Terraform knowledge

Procedure

Step 1	Create an API-only user in Security Cloud Control and copy the API token. To know how to create an API-only user, see Create API Only Users.
Step 2	Configure the Security Cloud Control Terraform provider in your Terraform repository by following the instructions in Security Cloud Control Terraform Provider. Example: `terraform { required_providers { cdo = { source = "CiscoDevNet/cdo" version = "0.7.0" } } } provider "cdo" { base_url = “<the CDO URL you use to access CDO>” api_token = “<the API Token generated in step 1>” }`
Step 3	Write Terraform code to create a `cdo_sdc` resource using the Security Cloud Control Terraform provider. See the Terraform registry for Security Cloud Control-sdc resource for more information. Example: `Resource “cdo_sdc” “my-sdc” { name = “my-sdc-in-vsphere” }` The `bootstrap_data` attribute of this resource is populated with the value of the Security Cloud Control bootstrap data and is provided to the `cdo_sdc` Terraform module in the next step.
Step 4	Write Terraform code to create the SDC in vSphere using Security Cloud Control_sdc Terraform module. Example: data "cdo_tenant" "current" {} module "vsphere-cdo-sdc" { source = "CiscoDevNet/cdo-sdc/vsphere" version = "1.0.0" vsphere_username = "<replace-with-username-with-admin-privileges>" vsphere_password = "<super-secure-password>" vsphere_server = "<replace-with-address-of-vsphere-server>" datacenter = "<replace-with-datacenter-name>" resource_pool = "<replace-with-resource-pool-name>" cdo_tenant_name = data.cdo_tenant.current.human_readable_name datastore = "<replace-with-name-of-datastore-to-deploy-vm-in>" network = "<replace-with-name-of-network-to-deploy-vm-in>" host = "<replace-with-esxi-host-address>" allow_unverified_ssl = <boolean; set to true if your vsphere server does not have a valid SSL certificate> ip_address = "<sdc-vm-ip-address; must be in the subnet of the assigned network for the VM>" gateway = "<replace-with-network-gateway-address>" cdo_user_password = "<replace-with-password-for-cdo-user-in-sdc-vm>" root_user_password = "<replace-with-password-for-root-user-in-sdc-vm>" cdo_bootstrap_data = cdo_sdc.sdc-in-vsphere.bootstrap_data } Note that the VM created has two users—a `root` user and a user called `cdo`—and the IP Address of the VM is configured statically. The `cdo_bootstrap_data` attribute is given the value of the `bootstrap_data` attribute generated when the `cdo_sdc` resource is created.
Step 5	Plan and apply your Terraform using `terraform plan` and `terraform apply`, as you would normally. See the Security Cloud Control Automation Repository in the CiscoDevNet for a complete example.

If your SDC stays in the onboarding state, connect to the vSphere VM using remote console, log in as the cdo user, and execute the following command:

sdc host status

Depending on the readout, you may need to manually run:

sdc host configure

Note

The Security Cloud Control Terraform modules are published as Open Source Software under the Apache 2.0 license. You can file issues on GitHub if you require support.

Deploy a Secure Device Connector on an AWS VPC Using a Terraform Module

Before you begin

Review these prerequisites before attempting to deploy an SDC on your AWS VPC:

Security Cloud Control requires strict certificate checking and does not support Web/Content Proxy inspection between the SDC and the Internet. If using a proxy server, disable inspection for traffic between the Secure Device Connector (SDC) andSecurity Cloud Control.
See Connect Security Cloud Control Firewall Management to the Secure Device Connector to ensure proper network access.
You require an AWS account, an AWS VPC with at least one subnet, and an AWS Route53-hosted zone.
Ensure you have the Security Cloud Control bootstrap data, your AWS VPC ID, and its subnet ID handy.
Ensure that the private subnet to which you deploy the SDC has a NAT gateway attached.
Open traffic on the port on which your firewall management HTTP interface is running, from your firewalls to the Elastic IP attached to the NAT gateway.

Procedure

Step 1

Add the following lines of code in your Terraform file; make sure you manually enter inputs for variables:

module "example-sdc" {
  source             = "git::https://github.com/cisco-lockhart/terraform-aws-cdo-sdc.git?ref=v0.0.1"
  env                = "example-env-ci"
  instance_name      = "example-instance-name"
  instance_size      = "r5a.xlarge"
  cdo_bootstrap_data = "<replace-with-cdo-bootstrap-data>"
  vpc_id             = <replace-with-vpc-id>
  subnet_id          = <replace-with-private-subnet-id>
}

See the Secure Device Connector Terraform module for a list of input variables and descriptions.

Step 2

output "example_sdc_instance_id" {
  value = module. example-sdc.instance_id
}

You can use the instance_id to connect to the SDC instance for troubleshooting using the AWS Systems Manager Session Manager (SSM). See Outputs in the Secure Device Connector Terraform module for a list of available outputs.

What to do next

For any troubleshooting of your SDC, you need to connect to the SDC instance using AWS SSM. See AWS Systems Manager Session Manager to know more about how to connect to your instance. Note that the ports to connect to the SDC instance using SSH are not exposed because of security reasons.

Note

The Security Cloud Control Terraform modules are published as Open Source Software under the Apache 2.0 license. You can file issues on GitHub if you require support.

Migrate an On-Premises Secure Device Connector and Secure Event Connector from a CentOS 7 Virtual Machine to an Ubuntu Virtual Machine

Security Cloud Control Firewall Management's on-premises Secure Device Connector (SDC) has been installed on CentOS 7 virtual machines up to this point. Since CentOS 7 is now end-of-life and has been deprecated by Security Cloud Control, we have created this migration process to help you migrate all SDCs from CentOS 7 to an Ubuntu virtual machine.

Before You Migrate

The SDC must have full outbound access to the internet on TCP port 443.
The Ubuntu virtual machine running the SDC must have network access to the management interfaces of the devices it communicates with, such as ASAs and Cisco IOS devices.
Any networking rules created for the IP address or FQDN of the old SDC VM to reach your devices should be recreated with the IP address or FQDN of the new SDC VM.
The migration will take 10 to 15 minutes. During this time, your device will continue to enforce security policy and route network traffic, but you will not be able to communicate with it through the SDC.

Prerequisites

Deploy a new host by following the instructions on Deploy a VM for Running the Secure Device Connector and Secure Event Connector.

Host Configuration

Follow this procedure if you are migrating the SDC and/or SEC:

Download the new VM image here.
Unzip the CDO-SDC_VM.zip file. You should see three VM files named similarly to the following:
- CDO-SDC-VM-708cd33-2024-05-30-2031-disk1.vmdk
- CDO-SDC-VM-708cd33-2024-05-30-2031.mf
- CDO-SDC-VM-708cd33-2024-05-30-2031.ovf
Deploy the VM you just downloaded.
Note the static IP address or FQDN you assigned to the new VM.
Using SSH, log in to the new VM as the cdo user.

At the prompt, enter the command:

sudo sdc host configure

Note

Follow the prompts in the migration script closely. The script is well-documented and will guide you through the migration process, explaining each step.
At the end of the migration script, you will receive a message indicating that your SDC has been migrated to the new VM. The SDC will retain its name after the migration.

SDC Migration

Procedure:

Using SSH, log in to the old (CentOS) SDC as the cdo user.

Install the CLI using the command:

curl -O https://s3.us-west-2.amazonaws.com/download.defenseorchestrator.com/sdc-cli/sdc-cli-package-latest.tgz && tar -xvf sdc-cli-package-latest.tgz && chmod +x ./install.sh && ./install.sh

Run the following command and follow the prompts:
```
sudo sdc migrate now
```

Verification:

Log in to your Security Cloud Control tenant.
Select the SDC you migrated, and in the Actions pane, click Request Heartbeat.

Note

Ensure that the SDC is in the Active state.

SEC Migration

Procedure:

Using SSH, log in to the old (CentOS) SDC as the cdo user.

Install the CLI using the command:

curl -O https://s3.us-west-2.amazonaws.com/download.defenseorchestrator.com/sdc-cli/sdc-cli-package-latest.tgz && tar -xvf sdc-cli-package-latest.tgz && chmod +x ./install.sh && ./install.sh

Run the following command and follow the prompts:
```
sudo sdc eventing migrate
```
You can configure your devices to point to the new IP address of the SEC or you can shut down the old host and assign the new host the same IP address that the old host had so that the devices do not need to be updated.

Verification:

For information on the state of the SEC, see Use Health Check to Learn the State of your Secure Event Connector.

Additional Instructions

Do Not Restart Your Old SDC

After the migration is complete, do not restart your old SDC on the original virtual machine.

Revert Failed Migration

If the migration fails for any reason, or the result is not what you are expecting and you want to revert to the old SDC, follow the instructions below:

Log in to the new VM and switch to the SDC user.
Ensure the SDC is not currently running on the new VM using the command:
```
docker ps
```
If the SDC is running, run the command:
```
sdc stop
```
Confirm that the SDC has stopped running by executing docker ps again.
Log in to the old VM and run the command:
```
sdc migrate revert
```
When the old SDC is active and visible in the UI, return to the new VM and execute the command:
```
sdc delete <your-tenant-name-here>
```
Refresh the browser completely, click on the SDC, and verify that the IP of the old host appears in the sidebar.

If the new IP still appears despite following these steps, request a new health check, refresh the browser, and check again.
To revert the SEC migration,run the command:
```
sdc eventing revert
```

Change the IP Address of a Secure Device Connector

Before you begin

You must be an admin to perform this task.
The SDC must have full outbound access to the Internet on TCP port 443, or the port you have configured for device management.

Note

You will not be required to re-onboard any devices to Security Cloud Control after changing the SDC's IP address.

Procedure

Step 1

Create an SSH connection to your SDC or open your virtual machine's console, and log in as the CDO user.

Step 2

To view your SDC VM's network interface configuration information before changing the IP address, use the command:

[cdo@localhost ~]$ ip addr

Step 3

To change the IP address of the interface, re-initiate the host configuration using the command:

[cdo@localhost ~]$ sdc host configure network

Step 4

Enter your password at the prompt.

Step 5

The configure script will then ask you about your networking configuration, write the new config file with the new IP and apply that configuration.

Note

You will lose your SSH connection at this time.

Step 6

Create an SSH connection using the new IP address you assigned to your SDC and log in.

Step 7

Your SDC should start automatically, but if it does not, run the following commands:

[cdo@localhost ~]$ sudo su - sdc

[cdo@localhost ~]$ sdc start

Note

If you are performing this procedure in the VM's console, when you confirm the values are correct, the connectivity status test is automatically run and the status is shown.

Step 8

You can also check your SDC's connectivity through the Security Cloud Control user interface. To do that, open the Security Cloud Control application and navigate to Administration > Integrations > Secure Connectors page.

Step 9

Refresh the page once and select the secure connector whose IP address you changed.

Step 10

On the Actions pane, click Request Heartbeat. You should see the Heartbeat requested successfully message, and the Last Heartbeat should display the current date and time.

Remove a Secure Device Connector

Warning

This procedure deletes your Secure Device Connector (SDC). It is not reversible. After taking this action, you will not be able to manage the devices connected to that SDC until you install a new SDC and reconnect your devices. Reconnecting your devices may requires you to re-enter the administrator credentials for each device you need to reconnect.

To remove the SDC from your tenant, follow this procedure:

Procedure

Step 1

Remove any devices connected to the SDC you want to delete.

1. See Find all Devices that Connect to Security Cloud Control Using the Same SDC to identify all the devices used by the SDC.
2. In the Security Devices page, select all the devices you identified.
3. In the Device Actions pane, click Remove and click OK to confirm your action.

Step 2

In the left pane, click Administration > Integrations > Secure Connectors.

Step 3

On the Services page with the Secure Connectors tab selected, click the blue plus button and select Secure Device Connector.

Step 4

In the Secure Connectors table, select the SDC you want to remove. Its device count should now be zero.

Step 5

In the Actions pane, click Remove. You receive this warning:

Warning

You are about to delete <sdc_name>. Deleting the SDC is not reversible. Deleting the SDC will require you to create and onboard a new SDC before you can onboard, or re-onboard, your devices.

Because you currently have onboarded devices, removing the SDC will require you to reconnect those devices and provide credentials again after setting up a new SDC.

If you have any questions or concerns, click Cancel and contact Security Cloud Control support.
If you wish to proceed, enter <sdc_name> in the text box below and click OK.

Step 6

In the confirmation dialog box, if you wish to proceed, enter your SDC's name as it is stated in the warning message.

Step 7

Click OK to confirm the SDC removal.

Move an ASA from one SDC to Another

Security Cloud Control supports the use of more than one SDC per tenant. You can move a managed ASA from one SDC to another using this procedure:

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the ASA tab.

Step 3

Select the ASA or ASAs you want to move to a different SDC.

Step 4

In the Device Actions pane, click Update Credentials.

Step 5

Click the Secure Device Connector button and select the SDC you want to move the device to.

Step 6

Enter the administrator username and password Security Cloud Control uses to log into the device and click Update. Unless they were changed, the administrator username and password are the same credentials you used to onboard the ASA. You do not have to deploy these changes to the device.

Note

If all the ASAs use the same credentials, you can move ASAs in bulk from one SDC to another. If the ASAs have different credentials, you have to move them from one SDC to another one at a time.

Rename a Secure Device Connector

Procedure

Step 1	In the left pane, choose Administration > Integrations > Secure Connectors.
Step 2	Select the SDC you want to rename.
Step 3	In the Details pane, click the edit icon next to the name of the SDC.
Step 4	Rename the SDC.

This new name will appear wherever the SDC name appears in the Security Cloud Control interface including the Secure Device Connectors filter of the Security Devices pane.

Update your Secure Device Connector

Use this procedure as a troubleshooting tool. Usually, the SDC is updated automatically and you should not have to use this procedure. In case of errors, you may need to initiate a manual update.

Procedure

Step 1

Connect to your SDC. You can connect using SSH or use the console view in your Hypervisor.

Step 2

Step 3

Switch to the SDC user to update the SDC docker container:

 [cdo@sdc-vm ~]$ sudo su sdc
                [sudo] password for cdo: <type password for cdo user>
                [sdc@sdc-vm ~]$

Step 4

Upgrade the SDC:

sdc upgrade

Note

Recommended updates and maintenance on the SDC Virtual Machine

Ensure that you monitor and apply updates to the SDC VM running on Ubuntu Linux following your organisation's internal IT security and patch management policies. We highly recommend regularly reviewing and applying relevant security patches to ensure that the SDC VM remains secure and functions optimally within your network environment.

Using Multiple SDCs on a Single Security Cloud Control Tenant

Deploying more than one SDC for your tenant allows you to manage more devices without experiencing performance degradation. The number of devices a single SDC can manage depends on the features implemented on those devices and the size of their configuration files.

You can install an unlimited number of SDCs on a tenant. Each SDC could manage one network segment. These SDCs would connect the devices in those network segments to the same Security Cloud Control tenant. Without multiple SDCs, you would need to manage the devices in isolated network segments with different Security Cloud Control tenants.

The procedure for deploying a second or subsequent SDC is the same for deploying your first SDC.
The initial SDC for your tenant incorporates the name of your tenant and the number 1. Each additional SDC is numbered in order.

Security Cloud Control Devices that Use the Same SDC

Follow this procedure to identify all the devices that connect to Security Cloud Control using the same SDC:

Procedure

Step 1	In the left pane, Security Devices.
Step 2	Click the Devices tab to locate the device.
Step 3	Click the appropriate device type tab.
Step 4	If there is any filter criteria already specified, click the clear button at the top of the Security Devices page to show all the devices and services you manage with Security Cloud Control.
Step 5	Click the filter button to expand the filter menu.
Step 6	In the Secure Device Connectors section of the filter, check the name of the SDC(s) you're interested in. The Security Devices page displays only the devices that connect to Security Cloud Control through the SDC you checked in the filter.
Step 7	(Optional) Check additional filters in the filter menu to refine your search further.
Step 8	(Optional) When you're done, click the clear button at the top of the Security Devices page to show all devices and services you manage with Security Cloud Control.

Open Source and Third-Party License in SDC

================================================================================

* amqplib *

Michael Bridgen <mikeb@squaremobius.net>

This package, "amqplib", is licensed under the MIT License. A copy maybe found in the file LICENSE-MIT in this directory, or downloaded from

http://opensource.org/licenses/MIT

================================================================================

* async *

Permission is hereby granted, free of charge, to any person obtaining a copyof this software and associated documentation files (the "Software"), to dealin the Software without restriction, including without limitation the rightsto use, copy, modify, merge, publish, distribute, sublicense, and/or sellcopies of the Software, and to permit persons to whom the Software isfurnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included inall copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THEAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS INTHE SOFTWARE.

================================================================================

* bluebird *

The MIT License (MIT)

The above copyright notice and this permission notice shall be included inall copies or substantial portions of the Software.

================================================================================

* cheerio *

Permission is hereby granted, free of charge, to any person obtaining a copyof this software and associated documentation files (the 'Software'), to dealin the Software without restriction, including without limitation the rightsto use, copy, modify, merge, publish, distribute, sublicense, and/or sellcopies of the Software, and to permit persons to whom the Software isfurnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included inall copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THEAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS INTHE SOFTWARE.

================================================================================

* command-line-args *

The MIT License (MIT)

The above copyright notice and this permission notice shall be included in allcopies or substantial portions of the Software.

================================================================================

* ip *

This software is licensed under the MIT License.

The above copyright notice and this permission notice shall be included in allcopies or substantial portions of the Software.

================================================================================

* json-buffer *

Permission is hereby granted, free of charge,to any person obtaining a copy of this software andassociated documentation files (the "Software"), todeal in the Software without restriction, includingwithout limitation the rights to use, copy, modify,merge, publish, distribute, sublicense, and/or sellcopies of the Software, and to permit persons to whomthe Software is furnished to do so,subject to the following conditions:

The above copyright notice and this permission noticeshall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIESOF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FORANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THESOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

================================================================================

* json-stable-stringify *

This software is released under the MIT license:

Permission is hereby granted, free of charge, to any person obtaining a copy ofthis software and associated documentation files (the "Software"), to deal inthe Software without restriction, including without limitation the rights touse, copy, modify, merge, publish, distribute, sublicense, and/or sell copies ofthe Software, and to permit persons to whom the Software is furnished to do so,subject to the following conditions:

The above copyright notice and this permission notice shall be included in allcopies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESSFOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS ORCOPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHERIN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR INCONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

================================================================================

* json-stringify-safe *

The ISC License

Permission to use, copy, modify, and/or distribute this software for anypurpose with or without fee is hereby granted, provided that the abovecopyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIESWITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FORANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGESWHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN ANACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF ORIN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

================================================================================

* lodash *

Based on Underscore.js, copyright Jeremy Ashkenas,

DocumentCloud and Investigative Reporters & Editors<http://underscorejs.org/>

This software consists of voluntary contributions made by manyindividuals. For exact contribution history, see the revision historyavailable at https://github.com/lodash/lodash

The following license applies to all parts of this software except as

documented below:

====

Permission is hereby granted, free of charge, to any person obtaininga copy of this software and associated documentation files (the"Software"), to deal in the Software without restriction, includingwithout limitation the rights to use, copy, modify, merge, publish,distribute, sublicense, and/or sell copies of the Software, and topermit persons to whom the Software is furnished to do so, subject tothe following conditions:

The above copyright notice and this permission notice shall beincluded in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BELIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTIONOF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTIONWITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

====

Copyright and related rights for sample code are waived via CC0. Samplecode is defined as all source code displayed within the prose of thedocumentation.

CC0: http://creativecommons.org/publicdomain/zero/1.0/

====

Files located in the node_modules and vendor directories are externallymaintained libraries used by this software which have their ownlicenses; we recommend you read them, as their terms may differ from theterms above.

================================================================================

* log4js *

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions andlimitations under the License.

================================================================================

* mkdirp *

This project is free software released under the MIT/X11 license:

The above copyright notice and this permission notice shall be included inall copies or substantial portions of the Software.

================================================================================

* node-forge *

New BSD License (3-clause)

Redistribution and use in source and binary forms, with or withoutmodification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyrightnotice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyrightnotice, this list of conditions and the following disclaimer in thedocumentation and/or other materials provided with the distribution.

* Neither the name of Digital Bazaar, Inc. nor thenames of its contributors may be used to endorse or promote productsderived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" ANDANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AREDISCLAIMED. IN NO EVENT SHALL DIGITAL BAZAAR BE LIABLE FOR ANYDIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED ANDON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THISSOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

================================================================================

* request *

Apache License

Version 2.0, January 2004

http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

"License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.

"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."

"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

You must give any other recipients of the Work or Derivative Works a copy of this License; and

You must cause any modified files to carry prominent notices stating that You changed the files; and

You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

================================================================================

* rimraf *

The ISC License

================================================================================

* uuid *

MIT License - http://opensource.org/licenses/mit-license.php

================================================================================

* validator *

Permission is hereby granted, free of charge, to any person obtaininga copy of this software and associated documentation files (the"Software"), to deal in the Software without restriction, includingwithout limitation the rights to use, copy, modify, merge, publish,distribute, sublicense, and/or sell copies of the Software, and topermit persons to whom the Software is furnished to do so, subject tothe following conditions:

The above copyright notice and this permission notice shall beincluded in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BELIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTIONOF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTIONWITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

================================================================================

* when *

Open Source Initiative OSI - The MIT License

http://www.opensource.org/licenses/mit-license.php

Permission is hereby granted, free of charge, to any person obtaininga copy of this software and associated documentation files (the"Software"), to deal in the Software without restriction, includingwithout limitation the rights to use, copy, modify, merge, publish,distribute, sublicense, and/or sell copies of the Software, and topermit persons to whom the Software is furnished to do so, subject tothe following conditions:

The above copyright notice and this permission notice shall beincluded in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BELIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTIONOF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTIONWITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.================================================================================

Supported Devices, Software, and Hardware

Security Cloud Control is a cloud-based management solution enabling the management of security policies and device configurations across multiple security platforms. Security Cloud Control centrally manages policy and configuration across:

Cisco Secure Firewall ASA, both on-premises and virtual
Cisco Secure Firewall Threat Defense (FTD), both on-premises and virtual
Cisco Catalyst SD-WAN Manager
Cisco Secure Firewall Management Center, on-premises
Cisco Meraki MX
Cisco IOS devices
Cisco Umbrella
AWS Security Groups

The documentation describes devices, software, and hardware Security Cloud Control supports. It does not point out software and devices that Security Cloud Control does not support. If we do not explicitly claim support for a software version or a device type, then we do not support it.

Cisco Secure Firewall ASA

Cisco Adaptive Security Appliance (ASA) is a security device integrating firewall, VPN, and intrusion prevention capabilities. It protects networks from unauthorized access, cyber threats, and data breaches, offering robust security services in a single platform. Security Cloud Control supports the management of ASA devices, offering features to streamline configuration management and ensure regulatory compliance across the network infrastructure.

Cisco Secure Firewall Threat Defense

Firewall Threat Defense integrates traditional firewall features with advanced threat protection capabilities. It offers comprehensive security functions, including intrusion prevention, application control, URL filtering, advanced malware protection, and so on. An FTD can be deployed on ASA hardware appliances, and Cisco firewall hardware appliances, and in virtual environments. Managing threat defense devices is possible through various management interfaces, such as Cisco Firewall Management Center, Security Cloud Control, and Firewall Device Manager.

For more information on software and hardware compatibility, see the Cisco Secure Firewall Threat Defense Compatibility Guide.

Firewall Device Manager is a web-based management interface explicitly designed for threat defense device management. It provides a simplified approach for configuring and monitoring threat defense devices, making it ideal for smaller-scale deployments or organizations preferring an intuitive interface.

FDM offers basic configuration capabilities for network settings, access control policies, NAT rules, VPN configuration, monitoring, and basic troubleshooting. Typically accessed through a web browser, FDM is directly available on the FTD device, eliminating the need for additional management servers or appliances.

Cisco Catalyst SD-WAN Manager

Security Cloud Control offers centralized management for Catalyst SD-WAN and Branch WAN environments, allowing organizations to efficiently configure, monitor, and enforce security policies across their networks. This integration also facilitates advanced troubleshooting, rule optimization, and change management on the Catalyst SD-WAN Manager.

For more information on software and hardware compatibility, see Cisco Catalyst SD-WAN Device Compatibility.

Cisco Secure Firewall Management Center

Security Cloud Control simplifies the management of on-premises Firewall Management Center by establishing a secure integration, discovering security devices, and enabling centralized policy management. Security policies such as firewall rules, VPN settings, and intrusion prevention policies can be efficiently managed and deployed across all devices under FMC.

Cisco Meraki MX

The Meraki MX appliance is an enterprise-grade security and SD-WAN next-generation firewall appliance, designed for decentralized deployments. Security Cloud Control supports managing layer 3 network rules on Meraki MX devices. When you onboard a Meraki device to Security Cloud Control, it communicates with the Meraki dashboard to manage that device. Security Cloud Control securely transfers configuration requests to the Meraki dashboard, which then applies the new configuration to the device. Key features of Security Cloud Control's support for Cisco Meraki MX include centralized policy management, backup and restore, monitoring and reporting, compliance checking, and automation capabilities.

Cisco IOS Devices

Cisco IOS can manage and control network functions, including routing, switching, and other networking protocols. It offers a set of features and commands to configure and maintain Cisco network devices, enabling efficient communication and management within networks of varying sizes and complexities.

Cisco Umbrella

Security Cloud Control manages Cisco Umbrella through integrations such as the Umbrella ASA Integration, which allows administrators to include their Cisco Adaptive Security Appliance (ASA) within their Umbrella configuration using per-interface policies. This integration enables the ASA to redirect DNS queries to Umbrella, enhancing network security by leveraging Umbrella's DNS security, web filtering, and threat intelligence capabilities.

AWS Security Groups

Security Cloud Control offers a simplified management interface for Amazon Web Services (AWS) Virtual Private Clouds (VPCs). Key features include monitoring AWS Site-to-Site VPN connections, tracking changes to AWS devices, and viewing AWS Site-to-Site VPN tunnels.

Secure Firewall Threat Defense Device Support Specifics

Secure Firewall Threat Defense is Cisco's next generation firewall. It can be installed on a variety of hardware and virtual platforms; see the Cisco Secure Firewall Threat Defense Compatibility Guide.

Firewall Threat Defense with Secure Firewall Device Manager

You can add Security Cloud Control managment to threat defense Version 6.4+ with Firewall Device Manager. However, this option is only available upon request for those who already have device manager support enabled on their tenant. See:

Open a Support Ticket with TAC to request this option.
Managing FDM Devices with Security Cloud Control to review the supported features.
Onboard FDM-managed Devices for a full discussion of onboarding prerequisites and requirements.
Guidelines and Limitations for Firepower Interface Configuration for Security Cloud Control limitations.

Snort

Snort 3 is the default inspection engine for threat defense starting in threat defense Version 6.7 (with device manager) and Version 7.0 (with management center).

Important

If you are still using the Snort 2 inspection engine, switch to Snort 3 now for improved detection and performance. Snort 2 will be deprecated in a future release and will eventually prevent threat defense upgrade.

Onboard FDM-Managed Device

FDM-managed Device Management

You can only onboard FDM-managed Firewall Threat Defense devices to Security Cloud Control. These devices cannot be managed by Cloud-Delivered Firewall Management Center.

If the device is not configured for local management, you must switch to local management before onboarding the device. See the Switching Between Local and Remote Management chapter of the Secure Firewall Threat Defense Configuration Guide for Firepower Device Manager.

Licensing

The device must have at least an license installed before it can be onboarded to Security Cloud Control although you can have a Smart License applied in some circumstances.


Onboarding Method	Secure Firewall Device Manager Software Version	90-day Evaluation licensed allowed?	Can the device already be smart-licensed before onboarding?	Can the device already be registered with Cisco Cloud Services before you onboarding?
Credentials (user name and password)	6.4 or later	Yes	Yes	Yes
Registration Key	6.4 or 6.5	Yes	No. Unregister the smart license and then onboard the device.	N/A
Registration Key	6.6 or later	Yes	Yes	No. Unregister the device from Cisco Cloud Services and then onboard the device.
Zero-Touch Provisioning	6.7 or later	Yes	Yes	Yes
Onboarding a device with a Serial Number	6.7 or later	Yes	Yes	Yes

See Cisco Firepower System Feature Licenses for more information.

Device Addressing

It is a best practice that the address you use to onboard the FDM-managed device is a static address. If the device's IP address is assigned by DHCP, it would be optimal to use a DDNS (dynamic domain name system) to automatically update your device's domain name entry with the new IP address of the device if it changes.

Note

FDM-managed devices do not natively support DDNS; you must configure your own DDNS.

Important

If your device gets an IP address from a DHCP server, and you do not have a DDNS server updating the FDM-managed device's domain name entry with any new IP addresses, or your device receives a new address, you can change the IP address the manager maintains for the device and then reconnect the device. Better still, onboard the device with a registration key.

Managing an FDM-Managed Device from the Inside Interface

Managing an FDM-managed device using the inside interface may be desirable if the dedicated MGMT interface is assigned an address that is not routable within your organization; for example, it might only be reachable from within your data center or lab.

Remote Access VPN Requirement

If the FDM-managed device you manage with Security Cloud Control will be managing Remote Access VPN (RA VPN) connections, Security Cloud Control must manage the device using the inside interface.

What to do next:

Continue to Manage an FDM-Managed Device from the Inside Interface for the procedure for configuring the FDM-managed device.

Manage an FDM-Managed Device from the Inside Interface

This configuration method:

Assumes that the FDM-managed device has not been on-boarded to Security Cloud Control.
Configures a data interface as the inside interface.
Configures the inside interface to receive MGMT traffic (HTTPS).
Allows the address of the cloud connector to reach the inside interface of the device.

Before you begin

Review the prerequisites for this configuration in these topics:

Managing an FDM-Managed Device from the Inside Interface
Connect Security Cloud Control to your Managed Devices

Procedure

Step 1	Log in to the Secure Firewall Device Manager.
Step 2	In the System Settings menu, click Management Access.
Step 3	Click the Data Interfaces tab and click Create Data Interface. In the Interface field, select the pre-named "inside" interface from the list of interfaces. In the Protocols field, select HTTPS if it is not already. In the Allowed Networks field, select the network objects that represent the networks inside your organization that will be allowed to access the inside address of the FDM-managed device. The IP address of the SDC or cloud connector should be among the addresses allowed to access the inside address of the device. In the Interface Addresses diagram, the SDC's IP address, 192.168.1.10 should be able to reach 192.168.1.1.
Step 4	Deploy the change. You can now manage the device using the inside interface.

What to do next

What if you are using a Cloud Connector?

Use the procedure above and add these steps:

Add a step to "NAT" the outside interface to (203.0.113.2) to the inside interface (192.168.1.1). See Interface Addresses.
In step 3c of the procedure above, your "Allowed Network" is a network group object containing the public IP addresses of the cloud connector.
Add a step that creates an Access Control rule allowing access to the outside interface (203.0.113.2) from the public IP addresses of the cloud connector. See for a list of all the Cloud Connector IP addresses for the various Security Cloud Control regions.

Onboard the FDM-Managed Device

The recommended way of onboarding the FDM-managed device to Security Cloud Control is to use the registration token onboarding approach. After you configure the inside interface to allow management access from the Cloud Connector to the FDM-managed device, onboard the FDM-managed device with the user name and password. See Onboard an FDM-managed Device Using Username, Password, and IP Address for more information. You will connect using the IP address of the inside interface. In our scenario above, that address is 192.168.1.1.

Managing an FDM-Managed Device from the Outside Interface

Managing an cloud-delivered Firewall Management Center device from the outside interface may be desirable if you have one public IP address assigned to a branch office and Security Cloud Control is managed using a Cloud Connector at another location.

Figure 2. Device Management on Outside Interface

This configuration doesn't mean that the physical MGMT interface is no longer the device's management interface. If you were in the office where the cloud-delivered Firewall Management Center device was located, you would be able to connect to the address of the MGMT interface and manage the device directly.

Remote Access VPN Requirement

If the device you manage with cloud-delivered Firewall Management Center will be managing Remote Access VPN (RA VPN) connections, cloud-delivered Firewall Management Center will not be able to manage the cloud-delivered Firewall Management Center device using the outside interface. See Managing an FDM-Managed Device from the Inside Interface instead.

What to do next:

Continue to Manage the FDM-Managed Device's Outside Interface for the procedure for configuring the cloud-delivered Firewall Management Center device.

Manage the FDM-Managed Device's Outside Interface

This configuration method:

Assumes that the FDM-managed device has not been on-boarded to Security Cloud Control.
Configures a data interface as the outside interface.
Configures management access on the outside interface.
Allows the public IP address of the cloud connector (after it has been NAT'd through the firewall) to reach the outside interface.

Before you begin

Review the prerequisites for this configuration in these topics:

Manage the FDM-Managed Device's Outside Interface
Connect Security Cloud Control to your Managed Devices

Procedure

Step 1	Log in to the Secure Firewall Device Manager.
Step 2	In the System Settings menu, click Management Access.
Step 3	Click the Data Interfaces tab and click Create Data Interface. In the Interface field, select the pre-named "outside" interface from the list of interfaces. In the Protocols field, select HTTPS if it is not already. Security Cloud Control only needs HTTPS access. In the Allowed Networks field, create a host network object containing the public-facing IP address of the cloud connector after it gets NAT'd through the firewall. In the Device Management from Outside Interface network diagram, the cloud connector's IP address, 10.10.10.55, would be NAT'd to 203.0.113.2. For the Allowed Network, you would create a host network object with the value 203.0.113.2.
Step 4	Create an Access Control policy in Secure Firewall Device Manager that allows management traffic (HTTPS) from the public IP address of the SDC or cloud connector, to the outside interface of your FDM-managed device. In this scenario, the source address would be 203.0.113.2 and the source protocol would be HTTPS; the destination address would be 209.165.202.129 and the protocol would be HTTPS.
Step 5	Deploy the change. You can now manage the device using the outside interface.

What to do next

What if you are using a cloud connector?

The process is very similar, except for two things:

In step 3c of the procedure above, your "Allowed Network" is a network group object containing the public IP addresses of the cloud connector. See Connecting Devices to Security Cloud Control Through the Cloud Connector for a list of Cloud Connector IP addresses for the various Security Cloud Control regions.
In step 4 of the procedure above, you create an Access Control rule that allows access to the outside interface from the public IP addresses of the cloud connector.

The registration token onboarding approach is the recommended way of onboarding the FDM-managed device to Security Cloud Control. After you configure the outside interface to allow management access from the cloud connector, onboard the FDM-managed device. You will connect using the IP address of the outside interface. In our scenario, that address is 209.165.202.129.

Onboard an FDM-Managed Device to Security Cloud Control

Use the following procedures to onboard an FDM-managed to Security Cloud Control with the following methods.

Onboard an FDM-Managed Device Using Username, Password, and IP Address

Use this procedure to onboard an FDM-managed device using only the device credentials and the device's Management IP address. This is the simplest method of onboarding an FDM-managed device.

However, the recommended way of onboarding an FDM-managed device to Security Cloud Control is by using a registration key.

Before you begin

Important

Before you onboard an FDM-managed device to Security Cloud Control, read Onboarding an FDM-managed Device and Connect Security Cloud Control to your Managed Devices. They provide the general device requirements and onboarding prerequisites needed to onboard a device.

You need the following information to onboard an FDM-managed device using the credentials method:
- The device credentials Security Cloud Control will use to connect to the device.
- The device's IP address of the interface you are using to manage the device. This may be the Management interface, an inside interface, or the outside interface depending on how you have configured your network.
- The device must be managed by Secure Firewall Device Manager and configured for local management in order for you to onboard it to Security Cloud Control. It cannot be managed by Secure Firewall Management Center.

Note

If you connect to https://eu.manage.security.cisco.com and your FDM-managed device is running software version 6.4, you must use this method. You can only onboard an FDM-managed device running software version 6.5+.

Procedure

Step 1

Step 2

In the left pane, click Security Devices.

Step 3

Click the blue plus button to Onboard a device.

Step 4

Click FTD.

Important

When you attempt to onboard an FDM-managed device, Security Cloud Control prompts you to read and accept the Secure Firewall Threat Defense End User License Agreement (EULA), which is a one-time activity for your tenant. Once you accept the EULA, Security Cloud Control won't prompt you again to accept it unless the EULA changes.

Step 5

In the onboarding wizard, click Use Credentials.

Step 6

In the Device Details step:

Click the Secure Device Connector button and select a Secure Device Connector (SDC) installed in your network. If you would rather not use an SDC, Security Cloud Control can connect to your FDM-managed device using the Cloud Connector.

Your choice depends on how you connect Security Cloud Control to your managed devices.
Enter the device name in the Device Name field. This could be the hostname of the device or any other name you choose.
In theLocation field, enter the IP address of the interface you are using to manage the device, hostname, or fully qualified domain name of the device. The default port is 443.

Important

If you already have a SecureX or Cisco Threat Response (CTR) account, you will need to merge your Security Cloud Control tenant and SecureX/CTR account in order for your devices to be registered with SecureX. Your accounts can be merged through the SecureX portal. See Merge Your Security Cloud Control and SecureX Accounts for instructions. Until your accounts are merged, you will not be able to see your device’s events in SecureX or benefit from other SecureX features.

Step 7

In the Database Updates area, the Immediately perform security updates, and enable recurring updates is enabled by default. This option immediately triggers a security update as well as automatically schedules the device to check for additional updates every Monday at 2AM. See Update FTD Security Databases and Schedule a Security Database Update for more information.

Disabling this option does not affect any previously scheduled updates you may have configured through FDM.

Click Next.

Step 8

Enter the device administrator's username and password and click Next.

Step 9

If there are pending changes on the device's Secure Firewall Device Manager, you will be notified and you can revert the changes or log in to the manager and deploy the pending changes. If there are no pending changes on Secure Firewall Device Manager, you will not see a prompt.

Step 10

(Optional) Add a label the device. See Labels and Label Groups for more information.

Onboard an FDM-Managed Device Running Software Version 6.4 or 6.5 Using a Registration Key

This procedure describes how to onboard an FDM-managed device using a registration key. This method is the recommended way of onboarding the FDM-managed device to Security Cloud Control and is beneficial if your FDM-managed device is assigned an IP address using DHCP. If that IP address changes for some reason, your FDM-managed device remains connected to Security Cloud Control. Additionally, your FDM-managed device can have an address on your local area network, and as long as it can access the outside network, it can be onboarded to Security Cloud Control using this method.

Warning

If you already have a SecureX or Cisco Threat Response (CTR) account, you will need to merge your Security Cloud Control tenant and SecureX/CTR account in order for your devices to be registered with SecureX. Until your accounts are merged, you will not be able to see your device's events in SecureX or benefit from other SecureX features. We strongly recommend merging your accounts before you create a Security Cloud Control module in SecureX. Your accounts can be merged through the SecureX portal. See Merge Accounts for instructions.

Before Onboarding

For customers running version 6.4, this method of onboarding is only supported for the US region, https://us.manage.security.cisco.com.
For customers running version 6.4, and connecting to the EU region, they must onboard their device using its device username, password, and IP address.
Customers running version 6.5 or later, and connecting either to the US, EU, or APJ regions can use this method of onboarding.
Review Connect Security Cloud Control to your Managed Devices for the networking requirements needed to connect Security Cloud Control to yourFDM-managed device.
Make sure your device is managed by Secure Firewall Device Manager, not Secure Firewall Management Center.
Devices running version 6.4 and 6.5 must not be registered with Cisco Smart Software Manager before onboarding them with a registration key. You will need to unregister the smart licenses of those FDM-managed devices before onboarding them to Security Cloud Control. See "Unregistering a Smart-licensed Firewall Device Manager" below.
The device may be using a 90-day evaluation license.
Log in to the FDM-managed device and make sure that there are no pending changes waiting on the device.
Make sure DNS is configured properly on your FDM-managed device.
Make sure the time services are configured properly on the FDM-managed device.
Make sure the FDM-managed device shows the correct date and time otherwise the onboarding will fail.

What to do next

Do one of these two these things:

Unregsiter your FDM-managed device from Cisco Smart Software Manager if it is already smart-licensed. You must unregister the device from Cisco Smart Software Manager before you onboard it to Security Cloud Control with a registration Key.Continue to Unregister a Smart-licensed FDM-Managed Device.
If your device is not already smart-licensed, continue to Procedure to Onboard an FDM-Managed Device Running Software Version 6.4 or 6.5 Using a Registration Key.

Unregister a Smart-licensed FDM-Managed Device

If the device you want to onboard is running version 6.4 or 6.5, and is already smart-licensed, the device is likely to be registered with Cisco Smart Software Manager. You must unregister the device from Cisco Smart Software Manager before you onboard it to Security Cloud Control with a registration Key. When you unregister, the base license and all optional licenses associated with the device, are freed in your virtual account.

After unregistering the device, the current configuration and policies on the device continue to work as-is, but you cannot make or deploy any changes.

Procedure

Step 1	Log on to the device using the Secure Firewall Device Manager.
Step 2	Click the device icon in the upper tab.
Step 3	In the Smart License area, click View Configuration.
Step 4	Click the Go to Cloud Services gear menu and select Unregister Device.
Step 5	Read the warning and click Unregister to unregister the device.

What to do next

If you unregistered your in order to onboard it to Security Cloud Control, continue to Procedure to Onboard an FDM-Managed Device Running Software Version 6.4 or 6.5 Using a Registration Key

Procedure to Onboard an FDM-Managed Device Running Software Version 6.4 or 6.5 Using a Registration Key

To onboard an FDM-managed using a registration key, follow this procedure:

Before you begin

Review the prerequisites discussed in Onboard an FDM-Managed Device Running Software Version 6.4 or 6.5 Using a Registration Key.

Procedure

Step 1

Step 2

In the left pane, click Security Devices.

Step 3

click the blue plus button to Onboard a device.

Step 4

Click FTD.

Important

When you attempt to onboard an FDM-managed device, Security Cloud Control prompts you to read and accept the Firepower Threat Defense End User License Agreement (EULA), which is a one-time activity in your tenant. Once you accept this agreement, Security Cloud Control doesn't prompt it again in subsequent FDM-managed onboarding. If the EULA agreement changes in the future, you must accept it again when prompted.

Step 5

On the Onboard FTD Device screen, click Use Registration Key.

Step 6

Enter the device name in the Device Name field. This could be the hostname of the device or any other name you choose.

Step 7

In the Database Updates area, the Immediately perform security updates, and enable recurring updates option is enabled by default. This option immediately triggers a security update as well as automatically schedules the device to check for additional updates every Monday at 2AM. See Update FTD Security Databases and Schedule a Security Database Update for more information.

Note

Disabling this option does not affect any previously scheduled updates you may have configured through Secure Firewall Device Manager.

Step 8

In the Create Registration Key area, Security Cloud Control generates a registration key.

Note

If you move away from the onboarding screen after the key is generated and before the device is fully onboarded, you will not be able to return to the onboarding screen; however, Security Cloud Control creates a placeholder for that device on the Security Devices page. When you select the device's placeholder, you will be able to see the key for that device in an action pane located to the right.

Step 9

Click the Copy icon to copy the registration key.

Note

You can skip copying the registration key and click Next to complete the place holder entry for the device and later, register the device. This option is useful when you're attempting to create the device first and later register it or if you're a Cisco partner installing a Proof of Value (POV) device in a customer network.

In the Security Devices page, you will see that the device is now in the connectivity state, "Unprovisioned". Copy the registration key appearing under Unprovisioned to Firewall Device Manager to complete the onboarding process.

Step 10

Log into the Secure Firewall Device Manager of the device you want to onboard to Security Cloud Control.

Step 11

In System Settings, click Cloud Services.

Step 12

In the Security Cloud Control tile, click Get Started.

Step 13

In the Region field, select the Cisco cloud region that your tenant is assigned to.

Note

This step is not applicable FDM-managed devices running version 6.4.

Step 14

In the Registration Key field, paste the registration key that you generated in Security Cloud Control.

Step 15

Click Register and then Accept the Cisco Disclosure.

Step 16

Return to Security Cloud Control. Select all the licenses you want to apply to the device.

For more information, see Applying or Updating a Smart License. You can also click Skip to continue the onboarding with a 90-day evaluation license.

Step 17

Return to Security Cloud Control, open the Security Devices page and see that the device status progresses from "Unprovisioned" to "Locating" to "Syncing" to "Synced."

Onboard an FDM-Managed Device Running Software Version 6.6+ Using a Registration Key

This procedure describes how to onboard an FDM-managed device running Version 6.6+ using a registration key. This method is the recommended way of onboarding the FDM-managed device to Security Cloud Control and is beneficial if your FDM-managed device is assigned an IP address using DHCP. If that IP address changes for some reason, your FDM-managed device remains connected to Security Cloud Control. Additionally, your FDM-managed device can have an address on your local area network, and as long as it can access the outside network, it can be onboarded to Security Cloud Control using this method.

Warning

If you already have a SecureX or Cisco Threat Response (CTR) account, you will need to merge your Security Cloud Control tenant and SecureX/CTR account in order for your devices to be registered with SecureX. Until your accounts are merged, you will not be able to see your device's events in SecureX or benefit from other SecureX features. We strongly recommend merging your accounts before you create a Security Cloud Control module in SecureX. Your accounts can be merged through the SecureX portal. See Merge Accounts for instructions.

If you want to onboard an FDM-managed device running version 6.4 or 6.5, see Onboard an FDM-Managed Device Running Software Version 6.4 or 6.5 Using a Registration Key.

Before Onboarding

This method of onboarding is currently available for version 6.6+ and to customers connecting to https://us.manage.security.cisco.com, https://eu.manage.security.cisco.com, or https://apj.manage.security.cisco.com.
Review Connect Security Cloud Control to your Managed Devices for the networking requirements needed to connect Security Cloud Control to your FDM-managed device.
Make sure your device is managed by Secure Firewall Device Manager, not Secure Firewall Management Center.
The device can be using a 90-day evaluation license or it can be smart-licensed. Devices running version 6.6+ can be onboarded to Security Cloud Control using a registration key without unregistering any installed smart licenses.
The device cannot already be registered with Cisco Cloud Services. See "Unregistering an FDM-Managed Device from Cisco Cloud Services" below before onboarding.
Log in to the device's Secure Firewall Device Manager UI and make sure that there are no pending changes waiting on the device.
Make sure DNS is configured properly on your FDM-managed device.
Make sure the time services are configured on the FDM-managed device.
Make sure the FDM-managed device shows the correct date and time otherwise the onboarding will fail.

What to do next:

Do one of these things:

If your FDM-managed device running verison 6.6+ is already registered with Cisco Cloud Services, you need to unregister the device before onboarding it. Continue to Unregistering an FDM-Managed Device from Cisco Cloud Services.
If your device is not registered to Cisco Cloud Services, continue to Procedure to Onboad an FDM-Managed Device Running Software Version 6.6+ Using a Registration Key.

Unregistering an FDM-Managed Device from Cisco Cloud Services

The following procedure is how to unregister the device from Cisco Cloud Services. Use this method before you onboard and FDM-managed device to Security Cloud Control with a registration key.

Note

If you onboard a virtual FDM-managed device running version 7.0 or later, registering the virtual FDM-managed device to Security Cloud Control automatically resets the performance-tiered Smart Licensing selection to Variable, which is the default tier. You must manually re-select the tier that matches the license associated with the device through the Secure Firewall Device Manager UI after onboarding.

Use this procedure to check and make sure it is not registered to Cisco Cloud Services:

Procedure

Step 1	Log on to the device using Secure Firewall Device Manager.
Step 2	Click the device icon in the upper tab.
Step 3	Expand the System Settings menu and then click Cloud Services.
Step 4	In the Cloud Services page, click the gear menu and select Unregister Cloud Services.
Step 5	Read the warning and click Unregister to unregister the device.

What to do next

If you are trying to onboard a FDM-managed device running version 6.6 or later, continue to Procedure to Onboad an FDM-Managed Device Running Software Version 6.6+ Using a Registration Key.

Procedure to Onboad an FDM-Managed Device Running Software Version 6.6+ Using a Registration Key

To onboard an FDM-managed device using a registration key, follow this procedure:

Procedure

Step 1

Step 2

In the left pane, click Security Devices.

Step 3

Click the blue plus button to Onboard a device.

Step 4

Click FTD.

Important

When you attempt to onboard the FDM-managed device, Security Cloud Control prompts you to read and accept the End User License Agreement (EULA), which is a one-time activity in your tenant. Once you accept this agreement, Security Cloud Control doesn't prompt it again in subsequent onboarding. If the EULA agreement changes in the future, you must accept it again when prompted.

Step 5

On the Onboard FTD Device screen, click Use Registration Key.

Step 6

Enter the device name in the Device Name field. This could be the hostname of the device or any other name you choose.

Step 7

Note

Disabling this option does not affect any previously scheduled updates you may have configured through Secure Firewall Device Manager.

Step 8

In the Create Registration Key step, Security Cloud Control generates a registration key.

Note

Step 9

Click the Copy icon to copy the registration key.

Note

You can skip copying the registration key and click Next to complete the place holder entry for the device and later, register the device. This option is useful when you're attempting to create the device first and register it later, or if you're a Cisco partner installing a Proof of Value (POV) device in a customer network.

In the Security Devices page, you will see that the device is now in the connectivity state, "Unprovisioned". Copy the registration key appearing under Unprovisionedto Firewall Device Manager to complete the onboarding process.

Step 10

Log into the Secure Firewall Device Manager of the device you are onboarding.

Step 11

Under System Settings, click Cloud Services.

Step 12

In the Region field, select the Cisco cloud region that your tenant is assigned to.

Step 13

In the Enrollment Type area, click Security Account .

Note

For devices running version 6.6, note that the Tenancy tab for Security Cloud Control is titled Security Account and you must manually enable Security Cloud Control in Secure Firewall Device Manager.

Step 14

In the Registration Key field, paste the registration key that you generated in Security Cloud Control.

Step 15

For devices running version 6.7 or later in the Service Enrollment area, check Enable Security Cloud Control Firewall Management.

Step 16

Review the information about the Cisco Success Network Enrollment. If you do not want to participate, uncheck the Enroll Cisco Success Network checkbox.

Step 17

Click Register and then Accept the Cisco Disclosure. Secure Firewall Device Manager sends the registration request to Security Cloud Control.

Step 18

Return to Security Cloud Control, in the Create Registration Key area, click Next.

Step 19

Select all licenses you want to apply to the device. Click Next.

Step 20

Return to Security Cloud Control, open the Security Devices page and see that the device status progresses from "Unprovisioned" to "Locating" to "Syncing" to "Synced."

Onboard an FDM-Managed Device using the Device's Serial Number

This procedure is a simplified method of setting up and onboarding the FDM-managed devices to Security Cloud Control. All you need is the chassis serial number or PCA serial number of the device. You can apply a smart license or use a 90-day evaluation license when onboarding the device.

Ensure that you read through the use cases to understand the concepts before you perform the onboarding steps.

Important

These methods of onboarding FDM-managed devices are only available for devices running version 6.7 or higher.

Use Cases

Onboarding a new factory-shipped FDM-managed device that is added to a network and reached from the Internet. The initial device setup wizard is not complete on the device.
Onboard a Configured FDM-Managed Device using the Device's Serial Number: Onboarding an already configured FDM-managed device or an upgraded device that is already added to a network and reached from the Internet. The initial device setup wizard is complete on the device.

Important

If you want to use this method to onboard a device running on an older software version that is supported for your device, you need to perform a fresh installation (reimage) of the software on that device instead of an upgrade.

Workflow and Prerequisites to Onboard the FDM-Managed Device Using Zero-Touch Provisioning

Zero-Touch Provisioning is a feature that allows a new factory-shipped Firepower 1000, Firepower 2100, or Secure Firewall 3100 series device to be provisioned and configured automatically, eliminating most of the manual tasks involved with onboarding the device to Security Cloud Control. The zero-touch provisioning is intended for remote offices or other locations where your employees are less experienced working with networking devices.

To use the zero-touch provisioning process, you must onboard the device to Security Cloud Control, connect it to a network that can reach the internet, and power on the device. See Onboard a Configured FDM-Managed Device using the Device's Serial Number for more information.

Note

You can power-on the device before or after onboarding it to Security Cloud Control. We recommend that you onboard the device to Security Cloud Control first and power-on the device and connect it to your branch network second. When you onboard the device in Security Cloud Control, the device is associated with your Security Cloud Control tenant in the Cisco cloud and Security Cloud Control automatically syncs the device configuration.

You can also use this procedure to onboard a device purchased from an external vendor or onboard a device already managed by another cloud tenant in a different region. However, if the device is already registered to the external vendor's cloud tenant or a cloud tenant in a different region, Security Cloud Control doesn't onboard the device but displays the "Device serial number already claimed" error message. In such cases, the Security Cloud Control admin must unregister the device's serial number from its previous cloud tenant and then claim the Security Cloud Control device in their own tenant. See Device Serial Number Already Claimed in the troubleshooting chapter.

The device Connectivity status changes to "Online" and the Configuration status changes to "Synced". The FDM-managed device is onboarded to Security Cloud Control.

You can see the Status LED (Firepower 1010), SYS LED (Firepower 2100), or S LED Secure Firewall 3100) flashing green on the rear panel of the hardware. The device LED continues to flash in green when it's connected to the cloud. If the device can't connect to the Cisco cloud or loses its connectivity after being connected, you can see the Status LED (Firepower 1010), SYS LED (Firepower 2100), or M LED (Secure Firewall 3100) flashing alternate green and amber.

See this video: Installing Your Cisco Firepower Firewall Using Zero-Touch Provisioning video to understand the LED indicators.

Important

If you have logged into the FDM-managed device console, SSH, or Secure Firewall Threat Defense, you would have changed the device's password during your first login. You can still use the zero-touch provisioning process for onboarding the device using Security Cloud Control. After you log into Secure Firewall Threat Defense, ensure that you do not complete the device setup wizard step that configures the outside interface. If you complete this step, the device is unregistered from the cloud, and you cannot use the zero-touch provisioning process.

When you log into Secure Firewall Threat Defense, you will see the following screen on the dashboard.

Without proceeding further on the Secure Firewall Threat Defense UI, go to the serial number onboarding wizard and onboard the device. Here, you must select Default Password Changed because the device password has already been changed.

Prerequisites

Software and Hardware Requirements

The FDM-managed devices must be running software that supports serial-number-onboarding. Use the following table as a guide:

Table 1. Hardward and Software Support
Firewall Model Numbers that Support Zero-Touch Provisioning	Supported Firewall Software Version	Software Package
Firepower 1000 series device models: 1010, 1120, 1140, 1150	6.7 or later	SF-F1K-TDx.x-K9
Firepower 2100 series device models: 2110, 2120, 2130, 2140	6.7 or later	SF-F2K-TDx.x-K9
Secure Firewall 3100 series device models: 3110, 3120, 3130, 3140	7.1 or later	SF-F3K-TDx.x-K9

Confirm the management platforms are running the correct version.

Table 2. Support FTD Manager Versions
Manager	Supported Version
Secure Firewall Device Manager	7.0 or later
On-Premises Firewall Management Center	7.2 or later
Cloud-Delivered Firewall Management Center	Not applicable

Configuration Prerequisites for Hardware Installation

The network at the branch office cannot use the 192.168.1.0/24 address space. The network on Ethernet 1/1 (outside) cannot use the 192.168.1.0/24 address space. The default IP address of the Ethernet 1/2 "inside" interface on the 1000 and 2100 series devices running FDM 6.7 is 192.168.1.1 may conflict with the DHCP address allocated by your WAN modem if it's on that subnet.
- inside - Ethernet 1/2, IP address 192.168.1.1
- outside - Ethernet 1/1, IP address from DHCP or an address you specify during setup
If you are unable to change the outside interface settings, use Secure Firewall Device Manager to change the subnet on the Ethernet 1/2 "inside" interface settings to avoid conflict. For example, you could change to the following subnet settings:
- IP Address: 192.168.95.1
- DHCP server range: 192.168.95.5-192.168.95.254
To learn about the steps for configuring the physical interface, see the "Secure Firewall Device Manager Configuration Guide". In the "Interfaces" chapter, see the "Configure a Physical Interface" section.
The Firewall Threat Defense device must be installed and connected to the Cisco Cloud.

The outside or management interface of the device must be connected to a network providing DHCP addressing. Typically, the device has a default DHCP client on the outside or management interface.

Note

If the management interface is connected to a network having a DHCP server, it takes precedence over the outside interface for Linux stack initiated traffic.

Your outside or management interface needs to access to be able to access the following Security Services Exchange domains for the serial onboarding method.
- Australia Region
  - api.aus.sse.itd.cisco.com
  - est.sco.cisco.com (common across geographies)
  - mx*.aus.sse.itd.cisco.com (currently only mx01.aus.sse.itd.cisco.com)
  - dex.aus.sse.itd.cisco.com (for customer success)
  - eventing-ingest.aus.sse.itd.cisco.com (for CTR and Security Cloud Control)
  - registration.aus.sse.itd.cisco.com (allows for device registration to the regional Cisco cloud)
- APJ Region
  - api.apj.sse.itd.cisco.com
  - est.sco.cisco.com (common across geographies)
  - mx*.apj.sse.itd.cisco.com (currently only mx01.apj.sse.itd.cisco.com)
  - dex.apj.sse.itd.cisco.com (for customer success)
  - eventing-ingest.apj.sse.itd.cisco.com (for CTR and Security Cloud Control)
  - registration.apj.sse.itd.cisco.com (allows for device registration to the regional Cisco cloud)
- EU Region
  - api.eu.sse.itd.cisco.com
  - est.sco.cisco.com (common across geographies)
  - mx*.eu.sse.itd.cisco.com (currently only mx01.eu.sse.itd.cisco.com)
  - dex.eu.sse.itd.cisco.com (for customer success)
  - eventing-ingest.eu.sse.itd.cisco.com (for CTR and Security Cloud Control)
  - registration.eu.sse.itd.cisco.com (allows for device registration to the regional Cisco cloud)
- India Region
  - api.in.sse.itd.cisco.com
  - est.sco.cisco.com (common across geographies)
  - mx*.in.sse.itd.cisco.com (currently only mx01.in.sse.itd.cisco.com)
  - dex.in.sse.itd.cisco.com (for customer success)
  - eventing-ingest.in.sse.itd.cisco.com (for CTR and Security Cloud Control)
  - registration.in.sse.itd.cisco.com (allows for device registration to the regional Cisco cloud)
- US Region
  - api-sse.cisco.com
  - est.sco.cisco.com (common across geographies)
  - mx*.sse.itd.cisco.com (currently only mx01.sse.itd.cisco.com)
  - dex.sse.itd.cisco.com (for customer success)
  - eventing-ingest.sse.itd.cisco.com (for CTR and Security Cloud Control)
  - registration.us.sse.itd.cisco.com (allows for device registration to the regional Cisco cloud)
The outside interface of the device must have DNS access to Cisco Umbrella DNS.

Before Claiming the Device in Security Cloud Control

Before claiming the device in Security Cloud Control, make sure that you have the following information:

Chassis serial number or PCA number of the Firewall Threat Defense device. You can find this information on the bottom of the hardware chassis or on the carton box in which your device is delivered. In the following example picture, you can see the serial number "*******X0R9" on the bottom of the Firepower 1010 chassis.
The default password of the device.
A smart license generated from Cisco Smart Software Manager for using the additional capabilities. However, you can complete the device onboarding using a 90-day evaluation license and later apply the smart license.

Onboard a Secure Firewall Threat Defense Device With Zero-Touch Provisioning

Caution

When the device is being onboarded in Security Cloud Control, we recommend that you not perform the device easy setup using the Secure Firewall Device Manager. This causes provisional error in Security Cloud Control.

Before you begin

The Firewall Threat Defense device must not be prevously or currently managed by Firewall Device Manager or Firewall Management Center. If the device is currently managed by a platform, see Onboard a Configured FDM-Managed Device using the Device's Serial Number.
If you onboard a device with the intention of managing it with an on-premises management center, the on-premises management center must be running version 7.4 and later.

Procedure

Step 1

If you are onboarding a device purchased from an external vendor, you must reimage the device first. For more information, see the "Reimage Procedures" chapter of the Cisco FXOS Troubleshooting Guide.

Step 2

Step 3

In the navigation pane, click Security Devices.

Step 4

Click the blue plus button to Onboard a device.

Step 5

Click the FTD tile.

Important

When you attempt to onboard a device, Security Cloud Control prompts you to read and accept the End User License Agreement (EULA), which is a one-time activity in your tenant. Once you accept this agreement, Security Cloud Control doesn't prompt it again in subsequent onboarding. If the EULA agreement changes in the future, you must accept it again when prompted.

Step 6

On the Onboard FTD Device screen, click Use Serial Number.

Step 7

In the Select FMC step, use the drop-down menu to select an on-premises management center that has already been onboarded to Security Cloud Control. Click Next.

The on-premises management center must be running version 7.4 or higher. If you do not have an on-premises management center onboarded, click +Onboard On-Prem FMC for the onboarding wizard.

Step 8

In the Connection step, enter the device's serial number and device name. Click Next.

Step 9

For zero-touch provisioning, the device must be brand new, or has been reimaged. For the Password Reset, be sure to select Yes, this new device has never been logged into or configured for a manager. Enter a new password and confirm the new password for the device, then click Next.

Step 10

For Policy Assignment, use the drop-down menu to select a access control policy to be deployed once the device is onboarded. If you do not have a customized policy, Security Cloud Control auto-selects the default access control policy. Click Next.

Step 11

Select all licenses you want to apply to the device. Click Next.

Step 12

(Optional) Add labels to the device. Security Cloud Control applies these labels once the device successfully onboards.

What to do next

Security Cloud Control starts claiming the device, and you will see the Claiming message on the right. Security Cloud Control continuously polls for an hour to determine if the device is online and registered to the cloud. Once it's registered to the cloud, Security Cloud Control starts the initial provisioning and onboards the device successfully. The device registration can be confirmed when the LED status flashes green on the device. If the device can't connect to the Cisco cloud or lose its connectivity after being connected, you can see the Status LED (Firepower 1000) or SYS LED (Firepower 2100) flashing alternate green and amber.

If the device is still not registered to the cloud within the first one hour, a time-out occurs, and now Security Cloud Control polls periodically for every 10 minutes to determine the device status and remain in Claiming state. When the device is turned on and connected to the cloud, you don't have to wait for 10 minutes to know its onboarding status. You can click the Check Status link anytime to see the status. Security Cloud Control starts the initial provisioning and onboards the device successfully.

Important

Suppose you have already completed the device setup wizard (see Onboard an Already Configured FDM-Managed Device), the device is unregistered from the cloud, and in this case, Security Cloud Control remains in Claiming state. You need to complete manual registration from Secure Firewall Device Manager to add it to Security Cloud Control. (In Secure Firewall Device Manager, go to System Settings > Cloud Services and select the Auto-enroll with Tenancy from Security Cloud Control Firewall Management option and click Register). Then, click Check Status.

Onboard a Configured FDM-Managed Device using the Device's Serial Number

This procedure is for devices that have already been configured for local management. Because the device setup wizard is completed on an already configured FDM-managed device, the device is unregistered from the cloud, and you can't onboard such devices to Security Cloud Control using the zero-touch provisioning process.

If you device is brand new and has never been managed or configured, you can onboard the device with zero-touch provisioning. See Onboard a Secure Firewall Threat Defense Device With Zero-Touch Provisioning for more information.

Note

When the device is not connected to the Cisco cloud, you can see the Status LED (Firepower 1000), SYS LED (Firepower 2100), or M LED (Secure Firewall 3100) flashing alternate green and amber.

You may have completed the device setup wizard to perform the following tasks:

The device must be running version 6.7 or later.
Configure a static IP address on the management interface of the device. If the interfaces cannot obtain the necessary dynamic IP address, or the DHCP server does not provide the gateway route, you need to configure a static IP address.
Obtain an address using PPPoE and configure the outside interface.
Manage the device running version 6.7 or later device using Secure Firewall Device Manager or Secure Firewall Management Center.

Important

You can switch the manager of a Secure Firewall Threat Defense device from Secure Firewall Device Manager to Secure Firewall Management Center, or the other way. Perform the steps explained in the Switching Between Local and Remote Management section of the "System Management" chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version the device runs.

If you want to onboard devices, perform the following:

Procedure

Step 1	Review the prerequisites for onboarding here Procedure for Onboarding FDM-Managed Device using Device Serial Number.
Step 2	In the Secure Firewall Device Manager UI, navigate to System Settings > Cloud Services and select the Auto-enroll with Tenancy from Security Cloud Control Firewall Management option and click Register.
Step 3	Log in to Security Cloud Control.
Step 4	In the navigation pane, click Security Devices.
Step 5	Click the FTD tile.
Step 6	On the Onboard FTD Device screen, click Use Serial Number.
Step 7	In the Select FMC step, use the drop-down menu to select an on-premises management center that has already been onboarded to Security Cloud Control. Click Next. The on-premises management center must be running version 7.4 or higher. If you do not have an on-premises management center onboarded, click +Onboard On-Prem FMC for the onboarding wizard.
Step 8	In the Connection step, enter the device's serial number and device name. Click Next.
Step 9	If the device is not brand new and has already been configured for management, select Yes, this new device has never been logged into or configured for a manager for the Password Reset. Click Next.
Step 10	For Policy Assignment, use the drop-down menu to select a access control policy to be deployed once the device is onboarded. If you do not have a customized policy, Security Cloud Control auto-selects the default access control policy. Click Next.
Step 11	Select all licenses you want to apply to the device. Click Next.

Security Cloud Control changes the device Connectivity status changes to "Online" and the Configuration status changes to the "Synced" state. The FDM-managed device is onboarded to Security Cloud Control. You can see the Status LED (Firepower 1000), SYS LED (Firepower 2100), or M LED flashing green on the rear panel of the hardware. The device LED continues to flash in green when it's connected to Cisco Cloud. If the device can't connect to the Cisco cloud or loses its connectivity after being connected, you can see the same status LED flash alternate green and amber.

Onboard an FDM-Managed High Availability Pair

To onboard an Secure Firewall Threat Defense HA pair to Security Cloud Control, you must onboard each device of the pair individually. Once both peers of the pair are onboarded Security Cloud Control automatically combines them as a single entry in the Seurity Devices page. Onboard the devices using either the device login credentials or a registration key. We recommend onboarding both devices with the same method. Also be aware that if you onboard a device that is in standby mode first, Security Cloud Control disables the ability to deploy or read from that device. You can only read or deploy to the active device within an HA pair.

Note

Security Cloud Control strongly recommends onboarding devices with a registration key. Onboarding with a registration key is slightly different for Firewall Threat Defense devices running specific versions. See Onboard an FDM-Managed HA Pair Running Version 6.4 or Version 6.5 and Onboard an FDM-Managed HA Pair Running Threat Defense Version 6.6 or Version 6.7 and later for more information.

Before you onboard an Firewall Threat Defense HA pair to Security Cloud Control, review the following:

Your HA pair is already formed prior to onboarding to Security Cloud Control.
Both devices are in a healthy state. The pair could be either primary/active and secondary/standby or primary/standby and secondary/active modes. Unhealthy devices will not successfully sync to Security Cloud Control.
Your HA pair is managed by Secure Firewall Device Manager, not Secure Firewall Management Center.
Your cloud connector connects to Security Cloud Control at https://us.manage.security.cisco.com.

Onboard an FDM-Managed High Availablity Pair with a Registration Key

Be aware of the following prerequisites before you onboard an FDM-managed High Availability (HA) pair with a registration key:

Onboarding devices that are running version 6.4 with a registration key is only supported for the US region (https://us.manage.security.cisco.com). To connect to the EU region (https://eu.manage.security.cisco.com) they must onboard their HA pair with username, password, and IP address.
Customers running version 6.5 or later, and connecting either to the US, EU, or APJ regions can use this method of onboarding.
Devices running version 6.4 and 6.5 must not be registered with Cisco Smart Software Manager before onboarding them with a registration key. You will need to unregister the smart licenses of those FDM-managed devices before onboarding them to Security Cloud Control. See Unregister a Smart-licensed FDM-Managed Device for more information.

Onboard an FDM-Managed HA Pair Running Version 6.4 or Version 6.5

To onboard an FDM-managed HA pair running software version 6.4 or 6.5, you must onboard the devices one at a time. It does not matter if you onboard the active or standby, the primary or secondary device.

Note

If you onboard either device of an HA pair with a registration key, you must onboard the other peer device in the same method.

Use the following steps for onboard an HA pair running Version 6.4 or 6.5:

Procedure

Step 1

Onboard a peer device. See Procedure to Onboard an FDM-Managed Device Running Software Version 6.4 or 6.5 Using a Registration Key to onboard the first device within the pair.

Step 2

In the left pane, click Security Devices.

Step 3

Click the Devices tab to locate your device.

Step 4

Click the FTD tab. Once the device is synced, select the device so it is highlighted. In the action pane located directly below Device Details, click Onboard Device.

Step 5

Enter the HA Peer Device Name for the peer device that has already been onboarded. Click Next.

Step 6

If you provided a smart license for the first device, Security Cloud Control repopulates that license so you can use it for onboarding this current device. Click Next.

Note

If you unregistered your device's Smart License to onboard your FDM-managed device, this is where you re-apply the smart license.

Step 7

Security Cloud Control automatically generates that registration key for the device you are preparing to onboarding. Click the Copy icon to copy the registration key.

Step 8

Log into the Secure Firewall Device Manager UI of the device you are onboarding.

Step 9

In System Settings, click Cloud Services.

Step 10

In the Security Cloud Control tile, click Get Started.

Step 11

In the Registration Key field, paste the registration key that you generated in Security Cloud Control.

Step 12

In the Region field, select the Cisco cloud region that your tenant is assigned to.

Note

This step is not applicable to the FDM-managed device running on version 6.4.

Step 13

Click Register and then Accept the Cisco Disclosure.

Step 14

Return to Security Cloud Control and, in the Create Registration Key area, click Next.

Step 15

Click Go to Security Devices. Security Cloud Control automatically onboards the device and combines them as a single entry. Similar to the first peer device you onboard, the device status changes from "Unprovisioned" to "Locating" to "Syncing" to "Synced."

Onboard an FDM-Managed HA Pair Running Threat Defense Version 6.6 or Version 6.7 and later

To onboard an FDM-managed HA pair running threat defense version 6.6 or 6.7, you must onboard the device one at a time. It does not matter if you onboard the active or standby, the primary or secondary device.

Note

If you onboard either device of an HA pair with a registration key, you must onboard the other peer device in the same method.

Use the following steps for onboard an HA pair running version 6.6 or 6.7:

Procedure

Step 1

Onboard a peer device. See Onboard an FDM-Managed Device Running Software Version 6.6+ Using a Registration Key

Step 2

In the left pane, click Security Devices.

Step 3

Click the Devices tab to locate your device.

Step 4

Click the FTD tab. Once the device is synced, select the device so it is highlighted. In the action pane located directly below Device Details, click Onboard Device.

Step 5

Enter the HA Peer Device Name for the peer device that has already been onboarded. Click Next.

Step 6

If you provided a smart license for the first device, Security Cloud Control repopulates that license so you can use it for onboarding this current device. Click Next.

Step 7

Security Cloud Control automatically generates that registration key for the device you are preparing to onboarding. Click the Copy icon to copy the registration key.

Step 8

Log into the Secure Firewall Device Manager UI of the device you want to onboard to Security Cloud Control.

Step 9

Under System Settings, click Cloud Services.

Step 10

In the Enrollment Type area, click Security/Security Cloud Control Account.

Note

For devices running version 6.6, note that the Tenancy tab for Security Cloud Control is titled Security Account and you must manually enable Security Cloud Control in the Secure Firewall Device Manager UI.

Step 11

In the Region field, select the Cisco cloud region that your tenant is assigned to.

Step 12

In the Registration Key field, paste the registration key that you generated in Security Cloud Control.

Step 13

For devices running version 6.7 or later in the Service Enrollment area, check Enable Security Cloud Control Firewall Management.

Step 14

Review the information about the Cisco Success Network Enrollment. If you do not want to participate, uncheck the Enroll Cisco Success Network check box.

Step 15

Click Register and then Accept the Cisco Disclosure. FDM sends the registration request to Security Cloud Control.

Step 16

Return to Security Cloud Control, in the Create Registration Key area, click Next.

Step 17

In the Smart License area, you can apply a smart license to the FDM-managed device and click Nextor you can click Skip to continue the onboarding with a 90-day evaluation license or if the device is already smart-licensed. For more information, see Updating an Existing Smart License of an FDM-Managed Device.

Note

If your device is running version 6.6, you need to manually enable communication to Security Cloud Control. From the device's FDM-managed UI, navigate to System Settings > Cloud Services and, in the Security Cloud Control Firewall Management tile, click Enable.

Step 18

Return to Security Cloud Control, click Go to Security Devices. Security Cloud Control automatically onboards the device and combines them as a single entry. Similar to the first peer device you onboard, the device status changes from "Unprovisioned" to "Locating" to "Syncing" to "Synced."

Onboard an FDM-Managed High Availability Pair

Note

Whichever method you onboard the first device of an HA pair with, you must onboard the other peer device in the same method.

To onboard an FDM-managed HA pair that has been created outside of Security Cloud Control, follow this procedure:

Procedure

Step 1	Onboard one of the peer devices within the HA pair. Onboard the device with its username, registration key, or serial number.
Step 2	Once the device is synced, in the Security Devices page, click the Devices tab.
Step 3	Click the FTD tab.
Step 4	Select the device. In the action pane located directly below Device Details, click Onboard Device.
Step 5	In the pop-up window, enter the HA peer's device name and location.
Step 6	Click Onboard Device. Once both devices are successfully synced to Security Cloud Control, the HA pair is displayed as a single entity in the Security Devices page.

Onboard an FTD Cluster

Onboard a Clustered Secure Firewall Threat Defense Device

Onboard a Firewall Threat Defense device that has already been clustered with the following procedure:

Before you begin

The following devices support clustering:

Secure Firewall 3100 devices
Firepower 4100 devices
Firepower 9300 devices
Firewall Threat Defense Virtual device (AWS, Azure, VMware, KVM, GCP)

Note the following limitations for clustered devices:

Devices must be running at least version 6.4.
Devices must be managed by a physical or virtual Secure Firewall Management Center.
Firepower 4100 and Firepower 9300 devices must be clustered through the device's chassis manager.
Secure Firewall 3100 devices, KVM, and VMware environments must be clustered through the Secure Firewall Management Center UI.
Azure, AWS, and GCP environment clusters must be created through their own environment and onboarded to Secure Firewall Management Center.

Procedure

Step 1	Log in to Security Cloud Control.
Step 2	In the left pane, click Security Devices.
Step 3	Click the blue plus button to Onboard a device.
Step 4	Click FTD.
Step 5	Under Management Mode, be sure FTD is selected. By selecting FTD, you are retaining Secure Firewall Management Center as the managing platform. If you select FDM, this switches the manager from Secure Firewall Management Center to a local manager such as the Firewall Device Manager or cloud-delivered Firewall Management Center. Note that Switching managers resets all existing policy configurations except for interface configurations and you must re-configure policies after you onboard the device.
Step 6	On the Onboard FTD Device screen, click Use CLI Registration Key.
Step 7	Enter the device name in the Device Name field. This could be the hostname of the device or any other name you choose.
Step 8	In the Policy Assignment step, use the drop-down menu to select an access control policy to deploy once the device is onboarded. If you have no policies configured, select the Default Access Control Policy.
Step 9	Specify whether the device you are onboarding is a physical or virtual device. If you are onboarding a virtual device, you must select the device's performance tier from the drop-down menu.
Step 10	Select the essentials licenses you want applied to the device. Click Next.
Step 11	Security Cloud Control generates a command with the registration key. Paste the entire registration key as is into the device's CLI.
Step 12	The device starts to onboard. As an optional step, you can add labels to your device to help sort and filter the Security Devices page. Enter a label and select the blue plus button. .

What to do next

Once the device is sychronized, Security Cloud Control automatically detects that the device is clustered. From here, select the device you just onboarded from the Security Devices page and select any of the options listed under the Management pane located to the right. We strongly recommend the following actions:

If you did not already, create a custom access control policy to customize the security for your environment. See FDM-Managed Access Control Policy for more information.
Enable Cisco Security Analytics and Logging (SAL) to view events in the Security Cloud Control dashboard or register the device to an Secure Firewall Management Center for security analytics.

Applying or Updating a Smart License

Applying a New Smart License to an FDM-Managed Device

Perform one of the following procedures to Smart License the FDM-managed device:

Smart license an FDM-managed device when onboarding using a registration key.
Smart license an FDM-managed device after onboarding the device using a registration key or the administrator's credentials.

Note

The FDM-managed device may be using a 90-day evaluation license, or the license could be unregistered.

Smart-License an FDM-Managed Device When Onboarding Using a Registration Key

Procedure

Step 1	Log on to the Cisco Smart Software Manager and generate a new Smart License key. Copy the newly generated key. You can watch the Generate Smart Licensing video for more information.
Step 2	Begin onboarding an FDM-managed device using a registration key. For more information, see Onboard an FDM-Managed Device Running Software Version 6.6+ Using a Registration Key or Onboard an FDM-Managed Device Running Software Version 6.4 or 6.5 Using a Registration Key.
Step 3	In step 4 of the onboarding wizard, in the Smart License here box, paste the Smart License in the Activate field and click Next.
Step 4	Click Go to Security Devices.
Step 5	Click the FTD tab and see the progress of the onboarding process. The device starts synchronizing and applies the Smart License. You should see that the device is now in the Online connectivity state. If the device is not in the online connectivity state, look in the Device Actions pane on the right and click Manage Licenses > Refresh Licenses to update the connectivity state.
Step 6	After applying the Smart License successfully to the FDM-managed device, click the Manage Licenses. The device status shows "Connected, Sufficient License." You can enable or disable the optional licenses. For more information, see FDM-managed Device Smart Licensing Types.

Smart-License an FDM-Managed Device After Onboarding the Device Using a Registration Key or its Credentials

Procedure

Step 1	In the left pane, click Security Devices.
Step 2	Click the Devices tab to locate the device.
Step 3	Click the FTD tab and select the device that you want to license.
Step 4	In the Device Actions pane on the right, click Manage Licenses.
Step 5	Follow the on-screen instructions and enter the Smart License generated from Cisco Smart Software Manager.
Step 6	Paste the new license key in the box and click Register Device. After synchronizing with the device, the connectivity state changes to 'Online'. After applying the Smart License successfully to the FDM-managed device, the device status shows "Connected, Sufficient License." You can enable or disable the optional licenses. For more information, see FDM-managed Device Smart Licensing Types.

Updating an Existing Smart License of an FDM-Managed Device

You can apply a new Smart License to an FDM-managed device which is Smart Licensed. Based on the method you have selected for onboarding your device, select the appropriate procedure:

Change the Smart License Applied to an FDM-Managed Device Onboarded Using a Registration Key

Procedure

Step 1	Remove the corresponding FDM-managed device from Security Cloud Control.
Step 2	Log into the Secure Firewall Device Manager for that device and unregister the Smart License. For more information, see Unregister a Smart-licensedFDM-Managed Device.
Step 3	In Security Cloud Control, onboard the FDM-managed device again using a registration key. For more information, see Onboard an FDM-Managed Device with a Registration Key.
Step 4	Click the Devices tab to locate the device.
Step 5	Click the tab.
Step 6	Apply the new Smart License during the onboarding process or by looking in the Device Actions pane on the right and clickingManage Licenses.

Change the Smart License Applied to an FDM-Managed Device Onboarded Using its Credentials

Procedure

Step 1	Log into the Secure Firewall Device Manager for that device and unregister the Smart License. For more information, see Onboard an FDM-Managed Device with a Registration Key.
Step 2	Apply the new Smart License to the FDM-managed device in Secure Firewall Device Manager. In the Smart License area, click View Configuration. Click Register Now and follow the onscreen instructions.
Step 3	In the left pane, click Security Devices page in Security Cloud Control, and then click the Devices tab.
Step 4	Click the FTD device. Check the FDM-managed device configuration for changes so that Security Cloud Control can make a copy of the FDM-managed device's deployed configuration and save it to the Security Cloud Control database. For more information, see Reading, Discarding, Checking for, and Deploying Configuration Changes.

Security Cloud Control Support for DHCP Addressing of FDM-Managed Devices

What happens if the IP address used by my FDM-managed device changes?

Security Cloud Control has many Adaptive Security Appliance (ASA) and FDM-managed device customers who have onboarded devices using the IP address provided by their service provider using DHCP.

If the IP address of the device for any reason, whether that is a change in the static IP address or a change in the IP address due to DHCP, you can change the IP address that Security Cloud Control uses to connect to the device and then reconnect the device.

The field, expressed concerns regarding the case of branch deployed FDM-managed devices managed by Security Cloud Control, a static IP is required on the outside interface of the FDM-managed device, which, in the view of some SE's, precludes using Security Cloud Control as a management solution when the FDM-managed device has a DHCP address configured for the outside interface.

However, this situation does not impact customers that have VPN tunnels to remote branch firewalls, and we know that a vast majority of customers have Site to Site tunnels from their Branch Offices back to their datacenters. In the case that Site-to -Site VPN is used to connect to the central site from devices, DHCP on the outside interface is not a concern since Security Cloud Control (and any management platform) can connect to the FW via its inside, statically addressed, interface (if so configured). This is a recommended practice and we have Security Cloud Control customers with many (+1000) devices using this deployment mode.

Also, the fact that an interface IP address is being issued via DHCP does not preclude the customer from managing the device using that IP. Again, this is not optimal, but the experience of periodically having to potentially change the IP address in Security Cloud Control has not been seen as a hurdle to customers. This situation is not exclusive to Security Cloud Control and happens with any manager using the outside interface including ASDM, FDM or SSH.

FDM-Managed Device Licensing Types

Smart License Types

The following table explains the licenses available for FDM-managed devices.

Your purchase of an FDM-managed device automatically includes a base license. All additional licenses are optional.


License	Duration	Granted Capabilities
License (automatically included)	Perpetual	All features not covered by the subscription term licenses. You must also specify whether to Allow export-controlled functionality on the products registered with this token. You can select this option only if your country meets export-control standards. This option controls your use of advanced encryption and the features that require advanced encryption.
	Term-based	Intrusion detection and prevention-Intrusion policies analyze network traffic for intrusions and exploits and, optionally, drop offending packets. File control-File policies detect and, optionally, block users from uploading (sending) or downloading (receiving) files of specific types. AMP for Firepower, which requires a Malware license, allows you to inspect and block files that contain malware. You must have the license to use any type of File policy. Security Intelligence filtering-Drop selected traffic before the traffic is subjected to analysis by access control rules. Dynamic feeds allow you to drop connections based on the latest intelligence immediately.
Malware	Term-based	File policies that check for malware, which use Cisco Advanced Malware Protection (AMP) with AMP for Firepower (network-based Advanced Malware Protection) and Cisco Threat Grid. File policies can detect and block malware in files transmitted over your network.
URL License	Term-based	Category and reputation-based URL filtering. You can perform URL filtering on individual URLs without this license.
	Term-based or perpetual based on the license type	Remote access VPN configuration. Your essentials license must allow export-controlled functionality to configure RA VPN. You select whether you meet export requirements when you register the device. Firepower Device Manager can use any valid AnyConnect license. The available features do not differ based on the license type. If you have not already purchased one, see Licensing Requirements for Remote Access VPN. Also, see the Cisco AnyConnect Ordering Guide, http://www.cisco.com/c/dam/en/us/products/collateral/security/anyconnect-og.pdf.

Virtual FDM-Managed Device Tiered Licenses

Version 7.0 introduces support for performance-tiered Smart Licensing for virtual FDM-Managed devices based on throughput requirements and RA VPN session limits. When the virtual FDM-Managed device is licensed with one of the available performance licenses, two things occur: session limits for RA VPNs are determined by the installed virtual FDM-Managed device platform entitlement tier, and enforced via a rate limiter.

Security Cloud Control does not fully support tiered smart licensing at this time; see the following limitations:

You cannot modify the tiered license through Security Cloud Control. You must make the changes in the Secure Firewall Device Manager UI.
If you register a virtual FDM-Managed device to be managed by the cloud-delivered Firewall Management Center, the tiered license selection automatically resets to Variable, which is the default tier.
If you onboard a virtual FDM-Managed device running version 7.0 or later, and select a license that is not a default license during the onboarding process, the tiered license selection automatically resets to Variable, which is the default tier.

We strongly recommend selecting a tier for your virtual FDM-Managed device license after onboarding your device to avoid the issues listed above. See Managing Smart Licenses for more information.

Viewing Smart-Licenses for a Device

Procedure

Step 1	In the left pane, click Security Devices.
Step 2	Click the Devices tab to locate your device.
Step 3	Click the FTD tab.
Step 4	Select an FDM-managed device to view its current license status.
Step 5	In the Device Actions pane on the right, click Manage Licenses. The Manage Licenses screen provides the following information: Smart License Agent status: Shows whether you're using a 90-day evaluation license, or if you have registered with the Cisco Smart Software Manager. The Smart License Agent status can be the following: "Connected," "Sufficient Licenses" - The device has contacted and registered successfully with the License Authority, which has authorized the license entitlements for the appliance. The device is now In-Compliance. Out-of-Compliance - There's no available license entitlement for the device. Licensed features continue to work. However, you can either purchase or free up extra entitlements to become In-Compliance. Authorization Expired - The device hasn't communicated with the Licensing Authority in 90 or more days. Licensed features continue to work. In this state, the Smart License Agent retries its authorization requests. If a retry succeeds, the agent enters either an Out-of-Compliance or Authorized state and begins a new Authorization Period. Try manually synchronizing the device. License Registration: Allows you to apply smart-license to an already onboarded FDM-managed device. Once registered, you can see the status of the connection to the Cisco Smart Software Manager and the status for each type of license. License Status: Shows the status of the optional licenses available for your FDM-managed device. You can enable a license to use the features controlled by the license.

Enabling or Disabling Optional Licenses

You can enable (register) optional licenses on FDM-managed devices that are using a 90-day evaluation license or a full license. You must enable a license to use the features controlled by the license.

If you no longer want to use the features covered by an optional term license, you can disable (release) the license. Disabling the license releases it in your Cisco Smart Software Manager account so that you can apply it to another device.

In evaluation mode, you can also enable evaluation versions of the optional licenses and perform all operations. In this mode, the licenses aren't registered with Cisco Smart Software Manager until you register the device.

Note

You can't enable the license in evaluation mode.

Before you begin

Before disabling a license, ensure that you are not using it. Rewrite or delete any policies that require the license.

For units operating in a high availability configuration, you enable or disable licenses on the active unit only. The change is reflected in the standby unit the next time you deploy the configuration when the standby unit requests (or frees) the necessary licenses. When enabling licenses, you must ensure that your Cisco Smart Software Manager account has sufficient licenses available, or you could have one unit compliant while the other unit is non-compliant.

To enable or disable optional licenses, follow this procedure:

Procedure

Step 1

In the Security Devices page, select the FDM-managed device that you want and click Manage Licenses in Device Actions pane, The Manage Licenses screen appears.

Step 2

Click the slider control for each optional license to enable or disable the license. The status of the license shows OK when enabled.

Enabled: Registers the license with your Cisco Smart Software Manager account and enable the controlled features. You can now configure and deploy policies controlled by the license.
Disabled: Unregisters the license with your Cisco Smart Software Manager account and disables the controlled features. You cannot configure the features in new policies, nor can you deploy policies that use the feature.

Step 3

Click Save to save the changes.

Impact of Expired or Disabled Optional Licenses

If an optional license expires, you can continue using features that require the license. However, the license is marked out of compliance, and you need to purchase the license and add it to your account to bring the license back into compliance.

If you disable an optional license, the system reacts as follows:

Malware license: The system stops querying the AMP cloud and also stops acknowledging retrospective events sent from the AMP cloud. You cannot re-deploy existing access control policies if they include file policies that apply malware inspection. Note that for a very brief time after a Malware license is disabled, the system can use existing cached file dispositions. After the time window expires, the system assigns a disposition of Unavailable to those files.
: The system no longer applies intrusion or file-control policies. For Security Intelligence policies, the system no longer applies the policy and stops downloading feed updates. You cannot re-deploy existing policies that require the license.
URL: Access control rules with URL category conditions immediately stop filtering URLs, and the system no longer downloads updates to URL data. You cannot re-deploy existing access control policies if they include rules with category and reputation-based URL conditions.
: You cannot edit the remote access VPN configuration, but you can remove it. Users can still connect using the RA VPN configuration. However, if you change the device registration so that the system is no longer export compliant, the remote access VPN configuration stops immediately, and no remote users can connect through the VPN.

Create and Import an Firewall Device Manager Model

Security Cloud Control provides the ability to export the complete configuration of an FDM-managed device on a Security Cloud Control tenant to a JSON file format. You can then import this file to another tenant as an Firewall Device Manager model and apply it to a new device on that tenant. The feature is beneficial when you want to use an FDM-managed device's configuration on different tenants that you manage.

Note

If the FDM-managed device contains rulesets, the shared rules associated with the rulesets are modified as local rules when exporting the configuration. Later, when the model is imported to another tenant and applied to an FDM-managed device, you'll see the local rules in the device.

Export FDM-Managed Device Configuration

The export configuration functionality is unavailable if your FDM-managed device has the following configuration:

High Availability
Snort 3 enabled

Procedure

Step 1	In the left pane, click Security Devices.
Step 2	Click the Devices tab to locate the device or the Templates tab to locate the model device.
Step 3	Click the FTD tab.
Step 4	Select an FDM-managed device and in the Device Actions on the right pane, click Export Configuration.

Import FDM-Managed Device Configuration

Procedure

Step 1

In the Security Devices page, click the blue plus () button to import the configuration.

Step 2

Click Import to import configuration for offline management.

Step 3

Select the Device Type as FTD.

Step 4

Click Browse and select the configuration file (JSON format) to upload.

Step 5

Once the configuration is verified, you're prompted to label the device or service. See Labels and Label Groups for more information.

Step 6

After labeling your model device, you can view it in the Security Devices list.

Note

Depending on the size of the configuration and the number of other devices or services, it may take some time for the configuration to be analyzed.

Backing Up FDM-Managed Devices

You can use Security Cloud Control to back up an FDM-managed device's system configuration so that you can restore the device to a previous state. Backups include the configuration only, and not the system software. If you need to completely reimage the device, you need to reinstall the software, then you can upload a backup and recover the configuration. Security Cloud Control saves the last 5 backups made for a device. When a new backup occurs, the oldest backup is deleted in order to store the newest backup.

Note

The backup does not include the management IP address configuration. Thus, when you recover a backup file, the management address is not replaced from the backup copy. This ensures that any changes you made to the address are preserved, and also makes it possible to restore the configuration on a different device on a different network segment.

The configuration database is locked during backup. You cannot make configuration changes during a backup, although you can view policies, dashboards, and so forth. During a restore, the system is completely unavailable.

To make backup schedules across your devices consistent, you can configure your own default backup schedule. When you schedule a backup for a particular device, you can use your own default settings or change them. You can schedule recurring backups with cadences from daily to once a month and you can perform an on-demand backup. You can also download backups and then use the Firewall Threat Defense device manager to restore them.

Requirements and best practice for backing up and restoring an FDM-managed device using Security Cloud Control

Security Cloud Control can backup FDM-managed devices running software version 6.5 and later.
The FDM-managed device must be onboarded to Security Cloud Control using a registration key.
You can restore a backup onto a replacement device only if the two devices are the same model and are running the same version of the software, including the build number, not just the same point release. For example, a backup of an FDM-managed device running software version 6.6.0-90 can only be restored to an FDM-managed device running 6.6.0-90. Do not use the backup and restore process to copy configurations between appliances. A backup file contains information that uniquely identifies an appliance, so that it cannot be shared in this manner.
For the Secure Firewall Threat Defense backup functionality to work in Security Cloud Control, Firewall Threat Defense needs to access one of these Security Cloud Control URLs based on your tenant region.
- edge.apj.cdo.cisco.com
- edge.aus.cdo.cisco.com
- edge.eu.cdo.cisco.com
- edge.in.cdo.cisco.com
- edge.us.cdo.cisco.com
Ensure that port 443 has external and outbound access for the HTTPS protocol. If the port is blocked behind a firewall, the backup and restore process may fail.

Best Practice

The device you are going to backup should be in the Synced state in Security Cloud Control. Security Cloud Control backs up the configuration of the device from the device not from Security Cloud Control. So, if the device is in a Not Synced state, changes on Security Cloud Control will not be backed up. If the device is in a Conflict Detected state, those changes will be backed up.

Back up an FDM-Managed Device On-Demand

This procedure describes how to backup an FDM-managed device so that it can be restored if need be.

Before you Begin

Review these requirements and best practices before you backup up an FDM-managed device.

Procedure

Step 1	(Optional) Create a change request for the backup.
Step 2	In the left pane, click Security Devices.
Step 3	Click the Devices tab.
Step 4	Click the FTD tab and select the device you want to backup.
Step 5	In the Device Actions pane on the right, click Manage Backups.
Step 6	Click Backup Now. The Device enters the Backing Up configuration state. When the backup is done, the Security Cloud Control displays the device's configuration state it was in before the backup started. You can also open the change log page to look for a recent change log record with the description, "Backup completed successfully." If you created a change request in step 1, you can also filter by that value to find the change log entry.
Step 7	If you created a change request in step 1, clear the change request value so you do not inadvertently associated more changes with the change request.

Configure a Recurring Backup Schedule for a Single FDM-Managed Device

Before you Begin

Review these requirements and best practices before you backup up an FDM-managed device.

Procedure

Step 1	In the left pane, click Security Devices.
Step 2	Click the Devices tab.
Step 3	Click the FTD tab and select the device you want to backup.
Step 4	In the Device Actions pane on the right, click Manage Backups.
Step 5	In the Device Backups page, click Set Recurring Backup or click the schedule in the Recurring Backup field. Security Cloud Control presents the default backup schedule for all FDM-managed devices on your tenant. See Configure a Default Recurring Backup Schedule for all FDM-Managed Devices for more information.
Step 6	Select the time of day, in 24-hour time, you want the backup to occur. Note that you schedule the time in Coordinated Universal Time (UTC) time.
Step 7	In the Frequency field, select daily, weekly, or monthly backup. Daily backups: Give the scheduled backup a name and a description. Weekly backups: Check the days of the week on which you want the backup to occur. Give the scheduled backup time a name and a description. Monthly backups: Click in the Days of Month field and add whichever days of the month you want to the schedule the backup. Note: If you enter day 31 but a month doesn't have 31 days in it, the backup will not take place. Give the scheduled backup time a name and a description.
Step 8	Click Save. Notice that on the Device Backup page, the Recurring Backup field is replaced by the backup schedule you set and reflects your local time.

Download the Device Backup

This procedure describes how to download a .tar file containing a backup of an FDM-managed device.

Procedure

Step 1

In the navigation bar, choose Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the FTD tab and the device whose backup you want to download.

Step 4

In the Actions pane on the right, click Manage Backups.

Step 5

Select the backup you want to download and, in its row, click the Generate Download Link button . The button changes to read, "Download Backup Image."

Step 6

The button now reads Download Backup Image. Do one of these things:

If you are on a device that can also reach the Firewall Device Manager of the device you want to restore, click the Download Backup Image button and save the downloaded file. Save it with a name that you will remember.

If you are not on a device that can also reach the FDM of the device you want to restore:

Right-click the Download Backup Image button and copy the link address.

Important

The link address expires 15 minutes after you click the Generate Download Link button.

Open a browser on a device that will also reach the Firewall Device Manager of the Secure Firewall Threat Defense you want to restore the image to.
Enter the download link into the browser address bar and download the backup file to that device. Save it with a name that you will remember.

Edit a Backup

This procedure allows you to edit the name or description of a successful FDM-managed device download.

Procedure

Step 1	In the left pane, click Security Devices.
Step 2	Click the Devices tab.
Step 3	Click the FTD tab and select the device you want to edit.
Step 4	In the Actions pane on the right, click Manage Backups.
Step 5	Select the backup you want to edit and it's row, click the edit icon .
Step 6	Change the name or description of the backup. You can see the new information in the Device Backups page.

Delete a Backup

Security Cloud Control saves the last 5 backups made for a device. When a new backup occurs, the oldest backup is deleted in order to store the newest backup. Deleting existing backups may help you manage which backups are kept and which are deleted.

Procedure

Step 1	In the left pane, click Security Devices.
Step 2	Click the Devices tab.
Step 3	Click the FTD tab and select the device you want to delete.
Step 4	In the Actions pane on the right, click Manage Backups.
Step 5	Select the backup you want to delete and it's row, click the trash icon .
Step 6	Click OK to confirm.

Managing Device Backup

Backups of FDM-managed devices you produce using Security Cloud Control can be seen in the Device Backups page:

Procedure

Step 1	In the left pane, click Security Devices.
Step 2	Click the Devices tab.
Step 3	Click the FTD tab.
Step 4	Click the filter icon and check FDM under Devices/Services to see only FDM-managed devices in the device table.
Step 5	Select the device you want.
Step 6	In the Device Actions pane, click Manage Backups. You will see up to 5 of the latest backups made of that device.

What to do next

See Restore a Backup to an FDM-Managed Device if you want to restore a backup.

Restore a Backup to an FDM-Managed Device

Review this information before you restore a backup of an FDM-managed managed Firewall Threat Defense device.

Review these requirements and best practices before you restore a backup to an FDM-managed Firewall Threat Defense device.
If the backup copy you want to restore is not already on the device, you must upload the backup first before restoring it.
During a restore, the system is completely unavailable. After the backup is restored, the device reboots.
This procedure assumes that you have an existing backup of the device ready to be restored to the device.
You cannot restore a backup if the device is part of a high availability pair. You must first break HA from the Device > High Availability page, then you can restore the backup. If the backup includes the HA configuration, the device will rejoin the HA group. Do not restore the same backup on both units, because they would then both go active. Instead, restore the backup on the unit you want to go active first, then restore the equivalent backup on the other unit.

Note

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the FTD tab and select the device you want to restore.

Step 4

In the Device Actions pane on the right, click Manage Backups.

Step 5

Select the backup you want to restore. In its row, click the Generate Download Link button .

Note

The link address expires 15 minutes after you click the Generate Download Link button.

Step 6

The button now reads Download Backup Image. Do one of these things:

If you are on a device that can also reach the Firewall Device Manager of the device you want to restore, click the Download Backup Imagebutton and save the downloaded file. Save it with a name that you will remember.
If you are not on a device that can also reach the Firewall Device Manager of the device you want to restore:
1. Right-click the Download Backup Image button and copy the link address.
2. Open a browser on a device that will also reach the Firewall Device Manager you want to restore the image to.
3. Enter the download link into the browser address bar and download the backup file to that device. Save it with a name that you will remember.

Step 7

Log on to Firewall Device Manager for the device you want to restore.

Step 8

Open version 6.5 or higher of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager. Navigate to the System Management chapter, and search for Restoring a Backup. Follow those instructions to restore the image you just downloaded to your FDM-managed device.

Tip

You will need to upload your image to Firewall Device Manager in order to restore it.

Step 9

Follow the prompts in Firewall Device Manager. When the restore starts, your browser is disconnected from Firewall Device Manager. After the restore has finished, the device reboots.

FDM Software Upgrade Paths

Upgrading FDM Versions

If you use Security Cloud Control to upgrade your FDM-managed firewalls, Security Cloud Control determines which version you can upgrade to and you will not need this topic. If you maintain your own repository of FDM images and upgrade your FDM-managed devices using your own images, this topic explains what upgrade paths are available to you.

You can upgrade an FDM-managed device directly from one major or maintenance version to another; for example, Version 6.4.0 > 6.5.0, or Version 6.4.0 > 7.0.1. You do not need to be running any specific patch level.

If direct upgrade is not possible, your upgrade path must include intermediate versions, such as Version 6.4.0 > 7.0.0 > 7.1.0.

Table 3. Upgrade Paths for Major Releases
Target Version	Oldest Release you can Upgrade to the Target Version
7.3.x	7.0.0
7.2.x	6.6.0
7.1.x	6.5.0
7.0.x	6.4.0
6.7.x	6.4.0
6.6.x	6.4.0
6.5.0	6.4.0

Patching FDM-Managed Devices

You cannot upgrade directly from a patch of one version to a patch of another version, such as from Version 6.4.0.1 > 6.5.0.1. You must upgrade to the major release first, and then patch that release. For example you must upgrade from Version 6.4.0.1 > 6.5.0 > 6.5.0.1.

Firepower Hotfixes

Security Cloud Control does not support hotfix updates or installations. If there is a hotfix available for your device model or software version, we strongly recommend using the configured manager's dashboard or UI. After a hotfix is installed on the device, Security Cloud Control detects out of band configuration changes.

Removing FDM Upgrades

You cannot use Security Cloud Control to remove or downgrade any release type, whether major, maintenance, or patch.

Starting with Secure Firewall Threat Defense defense Version 6.7.0, you can use Firepower Device Manager or the FTD CLI to revert a successfully upgraded device to its state just before the last major or maintenance upgrade (also called a snapshot). Reverting after patching necessarily removes patches as well. After reverting, you must reapply any configuration changes you made between upgrading and reverting. Note that to revert a major or maintenance upgrade to FDM Version 6.5.0 through 6.6.x, you must reimage. See the "System Management" section of a Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for more information.

Removing FDM Patches

You cannot remove an FDM patch with either Security Cloud Control or FDM. To remove a patch, you must reimage to a major or maintenance release.

Snort Upgrade

Snort is the main inspection engine for the product and is packaged into the Secure Firewall Threat Defense software for your convenience. Version 6.7 introduces an update to the package that you can upgrade to, or revert from, at any time. Although you can switch Snort versions freely, some intrusion rules in Snort 2.0 might not exist in Snort 3.0, and vice versa. We strongly recommend reading about the differences in the Firepower Device Manager Configuration Guide for Version 6.7.0 for more information.

To proceed with upgrading your FDM-managed device to use Snort 3 or to revert from Snort 3 back to Snort 2 from the Security Cloud Control UI, see Upgrade to Snort 3.0 and Revert From Snort 3.0 for FTD respectively.

Other Upgrade Limitations

2100 Series Devices

Security Cloud Control can upgrade Firepower 2100 series devices only if they are running appliance mode.

Firepower Threat Defense devices are always in appliance mode.

What to do next

See the "Cisco Firepower 2100 Getting Started Guide" for a more detailed discussion of these commands.

4100 and 9300 Series Devices

Security Cloud Control does not support the upgrade for the 4100 or 9300 series devices. You must upgrade these devices outside of Security Cloud Control.

FDM-Managed Device Upgrade Prerequisites

Security Cloud Control provides a wizard that helps you upgrade the Firewall Device Manager (FDM) images installed on an individual device or an HA pair.

The wizard guides you through the process of choosing compatible images, installs them, and reboots the device to complete the upgrade. We secure the upgrade process by validating that the images you chose on Security Cloud Control are the ones copied to, and installed on, your FDM-managed device. We strongly recommend the FDM-managed devices you are upgrading have outbound access to the internet.

If your FDM-managed device does not have outbound access to the internet, you can download the image you want from Cisco.com, store them in your own repository, provide the upgrade wizard with a custom URL to those images, and Security Cloud Control performs upgrades using those images. In this case, however, you determine what images you want to upgrade to. Security Cloud Control does not perform the image integrity check or disk-space check.

Configuration Prerequisites

DNS needs to be enabled on the FDM-managed device. See the "Configuring DNS" section of the System Administration chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running for more information.
The FDM-managed device should be able to reach the internet if you use upgrade images from Security Cloud Control's image repository.
The FDM-managed device has been successfully onboarded to Security Cloud Control.
The FDM-managed device is reachable.
The FDM-managed device is synced.
- If you update a device that has pending changes in Security Cloud Control and you do not accept changes, pending changes are lost after the upgrade completes. Best practice is to deploy any pending changes before you upgrade..
- If you have staged changes in Firewall Device Manager and the device is not synced, the upgrade in Security Cloud Control will fail at an eligibility check.

4100 and 9300 Series Running FTD

Security Cloud Control does not support the upgrade for the 4100 or 9300 series devices. You must upgrade these devices outside of Security Cloud Control.

Software and Hardware Requirements

Security Cloud Control is a cloud management platform. Software updates are released over time and are generally not dependent on hardware.

See Software and Hardware Supported by Security Cloud Control for information about supported hardware types.

Devices running Firewall Device Manager software have a recommended upgrade path for optimal performance. See Firepower Software Upgrade Path for more information.

Upgrade Notes

You cannot deploy changes to a device while it is upgrading.

Upgrade a Single FDM-Managed Device

Before You Begin

Be sure to read through the FTD Upgrade Prerequisites, Firepower Software Upgrade Path, and the Supported Devices, Software, and Hardware by Security Cloud Control before you upgrade.

See Supported Devices, Software, and Hardware.

This document covers any requirements and warnings you should know prior to upgrading to your desired version of Firepower software.

Upgrade A Single FDM-Managed Device with Images from Security Cloud Control's Repository

Use the following procedure to upgrade a standalone FDM-managed device using a software image that is stored in Security Cloud Control's repository:

Procedure

Step 1

In the navigation bar, click Security Devices.

Step 2

Click the Devices tab to locate your device..

Step 3

Click the FTD tab.

Step 4

Select the device you want to upgrade.

Step 5

In the Device Actions pane, click Upgrade.

Step 6

In step 1, click Use Security Cloud Control Image Repository to select the software image you want to upgrade to, and click Continue. You are only presented with choices that are compatible with the device you can upgrade.

Step 7

In step 2, confirm your choices and decide whether you only want to download the images to your device or copy the images, install them, and reboot the device.

Step 8

Click Perform Upgrade when you are ready. From the Security Devices page, devices that are upgrading have a "Upgrade in Progress" configuration status.

Warning

If you decide to cancel the upgrade while it is in progress, click Abort Upgrade from the Upgrade page. If you cancel the upgrade after it has started, Security Cloud Control does not deploy or check for changes from the device and the device does not roll back to the previous configuration. This may cause the device to enter an unhealthy state. If you experience any issues during the upgrade process, contact Cisco TAC.

Step 9

Alternatively, if you want Security Cloud Control to perform the upgrade later, select the Schedule Upgrade check box. Click the field to select a date and time in the future. When you are done, click the Schedule Upgrade button.

Step 10

Look at the notifications tab (notifications tab) for the progress of the bulk upgrade action. If you want more information about how the actions in the bulk upgrade job succeeded or failed, click the blue Review link and you will be directed to the Jobs page (Jobs page).

Step 11

Upgrade the system databases. You must do this step in Firewall Device Manager. See "Updating System Databases" in Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager, Version 6.4in for more information.

Upgrade a Single FDM-Managed Device with Images from your own Repository

Use the following procedure to upgrade a standalone FDM-managed device using a URL protocol to locate a software image:

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab to locate your device..

Step 3

Click the FTD tab.

Step 4

Select the device you want to upgrade.

Step 5

In the Device Actions pane, click Upgrade.

Step 6

In step 1, click Specify Image URL to select the software image you want to upgrade to, and click Continue. You are only presented with choices that are compatible with the device you can upgrade.

Step 7

In step 2, confirm your choices and decide whether you only want to download the images to your device or copy the images, install them, and reboot the device.

Step 8

Click Perform Upgrade when you are ready. From the Security Devices page, devices that are upgrading have a "Upgrade in Progress" configuration status.

Warning

Step 9

Step 10

Step 11

Upgrade the system databases. You must do this step in Firewall Device Manager. See Updating System Databases in Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager, Version 6.4 for more information.

Monitor the Upgrade Process

You can view the progress of your single device by selecting that device on the Security Devices page and clicking the upgrade button. Security Cloud Control takes you to the Device Upgrade page for that device.

If the upgrade fails at any point, Security Cloud Control displays a message. Security Cloud Control does not automatically restart the upgrade process.

Warning

Upgrading devices that have self-signed certificates may experience issues; see New Certificate Detected for more information

Bulk FDM-Managed Devices Upgrade

Before You Begin

Be sure to read through the FDM-Managed Device Upgrade Prerequisites, Firepower Software Upgrade Path, and the Supported Devices, Software, and Hardware supported by Security Cloud Control before you upgrade.

See Supported Devices, Software, and Hardware.

This document covers any requirements and warnings you should know prior to upgrading to your desired version of Firepower software.

Note

You can only bulk upgrade FDM-managed devices if they are all upgrading to the same software version.

Upgrade Bulk FDM-Managed Devices with Images from Security Cloud Control's Repository

Use the following procedure to upgrade multiple FDM-managed devices using a software image that is stored in Security Cloud Control's repository:

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab to locate your devices.

Step 3

Click the FTD tab.

Step 4

Use the filter to narrow down the list of devices you may want to include in your bulk upgrade.

Step 5

From the filtered list of devices, select the devices you want to upgrade.

Step 6

In the Device Actions pane, click Upgrade.

Step 7

On the Bulk Device Upgrade page, the devices that can be upgraded are presented to you. If any of the devices you chose are not upgradable, Security Cloud Control gives you a link to view the not upgradable devices.

Step 8

Step 9

In step 1, click Use Security Cloud Control Image Repository to select the software image you want to upgrade to. You are only presented with choices that are compatible with the devices you can upgrade. Click Continue.

Step 10

In step 2, confirm your choices and decide whether you only want to download the images to your device or copy the images, install them, and reboot the device.

Step 11

Click Perform Upgrade when you are ready. From the Security Devices page, devices that are upgrading have a "Upgrade in Progress" configuration status.

Warning

If you decide to cancel the upgrades while in progress, click Abort Upgrade from the Upgrade page. If you cancel the upgrades after it has started, Security Cloud Control does not deploy or poll for changes from the devices. Devices do not roll back to the previous configuration after a canceled upgrade, either. This may cause the devices to enter an unhealthy state. If you experience any issues during the upgrade process, contact Cisco TAC.

Step 12

Step 13

Upgrade the system databases. You must do this step in Firewall Device Manager. See Updating System Databases in Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager, for the version your device is running.

Upgrade Bulk FDM-Managed Devices with Images from your own Repository

Use the following procedure to upgrade multiple FDM-managed devices using a URL protocol to locate a software image:

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab to locate your devices.

Step 3

Click the FTD tab.

Step 4

Use the filter to narrow down the list of devices you may want to include in your bulk upgrade.

Step 5

From the filtered list of devices, select the devices you want to upgrade.

Step 6

In the Device Actions pane, click Upgrade.

Step 7

Step 8

Step 9

In step 1, click Specify Image URL to select the software image you want to upgrade to, and click Continue.

Step 10

In step 2, confirm your choices and decide whether you only want to download the images to your devices or copy the images, install them, and reboot the device.

Step 11

Click Perform Upgrade when you are ready. From the Security Devices page, devices that are upgrading have a "Upgrade in Progress" configuration status.

Warning

If you decide to cancel the upgrades while in progress, click Abort Upgrade from the Upgrade page. If you cancel the upgrades after it has started, Security Cloud Control does not deploy or poll for changes from the devices and the devices do not roll back to the previous configuration. This may cause the devices to enter an unhealthy state. If you experience any issues during the upgrade process, contact Cisco TAC.

Step 12

Step 13

Monitor the Bulk Upgrade Process

You can view the progress of a single device that was included in the bulk upgrade by selecting that device on the Security Devices page and clicking the upgrade button. You can also view the progress details by clicking Jobs in the left pane and expanding the bulk operation.

If the upgrade fails at any point, Security Cloud Control displays a message. Security Cloud Control does not automatically restart the upgrade process.

Upgrade an FDM-Managed High Availability Pair

Upgrade your HA pair without disrupting traffic; the standby device continues to handle traffic detection while the secondary device is upgraded.

When you upgrade an HA pair, Security Cloud Control executes an eligibility check and copies or identifies the image location before starting the upgrade. The secondary device in a high availability pair upgrades first, even if it is currently the active device; if the secondary device is the Security Cloud Control active device, the paired devices automatically switch roles for the upgrade process. Once the secondary devices successfully upgrade, the devices switch roles, then the new standby device upgrades. When the upgrade completes, the devices are automatically configured so the primary device is active and the secondary device is standby.

We do not recommend deploying to the HA pair during the upgrade process.

Before You Begin

Deploy all pending changes to the active device before upgrading.
Ensure there are no tasks running during the upgrade.
Both devices in the HA pair are healthy.
Confirm you are ready to upgrade; you cannot rollback to a previous version in Security Cloud Control.
Read through the FTD Upgrade Prerequisites, Firepower Software Upgrade Path, and the Software and Hardware Supported by Security Cloud Control to review any requirements and warnings that may incur during the ugprade process.

Upgrade an FDM-Managed HA Pair with Images from Security Cloud Control's Repository

Use the following procedure to upgrade an FDM-managed HA pair using a software image that is stored in Security Cloud Control's repository:

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab to locate your device.

Step 3

Click the FTD tab.

Step 4

Select the HA pair you want to upgrade.

Step 5

In the Device Actions pane, click Upgrade.

Step 6

In step 1, click Use Security Cloud Control Image Repository to select the software image you want to upgrade to, and click Continue. You are only presented with choices that are compatible with the device you can upgrade.

Step 7

In step 2, confirm your choices and decide whether you only want to download the images to your device or copy the images, install them, and reboot the device.

Step 8

Click Perform Upgrade when you are ready. From the Security Devices page, devices that are upgrading have a "Upgrade in Progress" configuration status.

Warning

If you decide to cancel the upgrade while it is in progress, click Abort Upgrade from the Upgrade page. If you cancel the upgrade after it has started, Security Cloud Control does not deploy or poll changes from the device and the device does not roll back to the previous configuration. This may cause the device to enter an unhealthy state. If you experience any issues during the upgrade process, contact Cisco TAC.

Step 9

Step 10

Step 11

Upgrade the system databases. You must do this step in FDM. See "Updating System Databases" in Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager, Version 6.4 in for more information.

Upgrade an FDM-Managed HA Pair with Images from your own Repository

Use the following procedure to upgrade an FDM-managed HA pair using a URL protocol to locate a software image:

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab to locate your device.

Step 3

Click the FTD tab.

Step 4

Select the HA pair you want to upgrade.

Step 5

In the Device Actions pane, click Upgrade.

Step 6

Step 7

In step 2, confirm your choices and decide whether you only want to download the images to your device or copy the images, install them, and reboot the device.

Step 8

Click Perform Upgrade when you are ready. From the Security Devices page, devices that are upgrading have a "Upgrade in Progress" configuration status.

Warning

If you decide to cancel the upgrade while it is in progress, click Abort Upgrade from the Upgrade page. If you cancel the upgrade after it has started, Security Cloud Control does not deploy or poll changes from the device and the device does not roll back to the previous configuration. This may cause the device to enter an unhealthy state. If you experience any issues during the upgrade process, contact Cisco TAC.

Step 9

Step 10

Step 11

Monitor the Upgrade Process

You can view the progress of your single device by selecting that device on the Security Devices page and clicking the upgrade button. Security Cloud Control takes you to the Device Upgrade page for that device.

During the upgrade, the system suspends HA while updating system libraries, which includes an automatic deployment, and may not be in a healthy state for the entirety of the upgrade process. This is expected. The device is available for SSH connections during the last part of this process, so if you log in shortly after applying an upgrade, you might see HA in suspended status. If the system experiences issues during the upgrade process and the HA pair appears to be suspended, manually resume HA from the Firewall Device Manager console of the active device.

Note

If the upgrade fails at any point, Security Cloud Control displays a message. Security Cloud Control does not automatically restart the upgrade process.

Warning

Upgrading devices that have self-signed certificates may experience issues; see New Certificate Detected for more information.

Upgrade to Snort 3.0

Snort 3 is the latest snort engine, or a powerful preprocessor that uses Open Source Intrusion Prevention System (IPS), available for Firepower Version 6.7 and later. The snort engine uses a series of rules that help define malicious network activity and uses those rules to find packets that match against them and generates alerts for users and is ideally used as a packet sniffer, a packet logger, or, more traditionally, as a a standalone network IPS.

With Snort 3, you can now create custom intrusion policies; every FDM-managed device running Snort 3 has a set of intrusion policies that are pre-defined from Cisco's Talos Intelligence Group (Talos). Snort 3 makes it possible to change these default policies, although we strongly recommend building on top of the base for a more robust policy.

You cannot create custom policies with Snort 2.

Switching from Snort 2 to Snort 3

You can switch Snort versions freely, though some intrusion rules in Snort 2.0 might not exist in Snort 3.0, and vice versa. If you changed the rule action for an existing rule, that change is not preserved if you switch to Snort 3 and then back to Snort 2, or back again to Snort 3. Your changes to rule actions for rules that exist in both versions are preserved. Note that the mapping between rules in Snort 3 and Snort 2 can be one-to-one or one-to-many, so preservation of changes is done on a best-effort basis.

If you choose to upgrade from Snort 2 to Snort 3, please note that upgrading the snort engines is comparable to a system upgrade. We strongly recommend upgrading during a maintenance window to minimize the interruption in traffic monitoring for your network. See Managing Intrusion Policies (Snort3) in the Firepower Device Manager Configuration Guide as to how switching snort versions will affect how rules process traffic.

Tip

You can filter by Snort version on the Security Devices page, and the Details window of a selected device displays the current version running on the device.

Snort 3 Limitations

License Requirements

To allow the snort engine to process traffic for intrusion and malware analysis, you must have the license enabled for the FDM-managed device. To enable this license through Firewall Device Manager, log into the Firewall Device Manager UI and navigate to Device > View Configuration > Enable/Disable and enable the license.

Hardware Support

The following devices support Snort 3:

FTD 1000 series
FTD 2100 series
FTD 4100 series
FTD virutal with AWS
FTD virtual with Azure
ASA 5500-X Series with FTD

Software Support

Devices must be running at least Firewall Device Manager Version 6.7. Security Cloud Control supports Snort 3 functionality for devices running Version 6.7 and later.

For FTD 1000 and 2000 series, see FXOS bundled support for more information on FXOS patch support.

Configuration Limitations

Security Cloud Control does not support upgrading to Snort 3 if your device has the following configurations:

Device is not running at least Version 6.7.
If a device has pending changes. Deploy any changes prior to upgrading.
If a device is currently upgrading. Do not attempt to upgrade or deploy to the device until the device is synced.
If a device is configured with a virtual router.

Note

If you upgrade or revert the Snort version, the system automatically deploys to implement the changes between Snort 2 intrusion policies and Snort 3 intrusion policies.

Rulesets and Snort 3

Note that Snort 3 does not have full feature support at this time. Security Cloud Control rulesets are not supported on Snort 3 devices. If you simultaneously upgrade a device to Firewall Device Manager 6.7 or higher, and from Snort 2 to Snort 3, any rulesets configured prior to the upgrade are broken up and the rules in them are saved as individual rules.

For a full list of ruleset support in regards to devices configured for Snort 3, see Rulesets.

Upgrade the Device and the Intrusion Prevention Engine Simultaneously

Security Cloud Control allows you to upgrade the device to Version 6.7 and the Snort 3. Use the following procedure to upgrade the FDM-managed device:

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the FTD tab and select the device or devices you want to upgrade.

Step 4

In the Devices Actions pane located to the right, click Upgrade.

Step 5

Set the upgrade toggle to FTD System Upgrade.

Step 6

(Optional) If you want Security Cloud Control to perform the upgrade later, check the Schedule Upgrade check box. Click in the field to select a date and time in the future.

Step 7

In step 1, select your upgrade method. Either use the Security Cloud Control Image Repository and an image from your own repository:

Use Security Cloud Control Image Repository - Click this option to select the software image you want to upgrade to, and click Continue. You are only presented with choices that are compatible with the device you can upgrade.
Specify Image URL - Click this option to select the software image that is currently stored in your own repository, and click Continue. You are only presented with choices that are compatible with the device you can upgrade.

Step 8

In step 2, confirm your choices and decide whether you only want to download the images to your device or copy the images, install them, and reboot the device.

Step 9

Check Upgrade to Snort 3 Engine.

Step 10

Click Perform Upgrade when you are ready. From the Security Devices page, devices that are upgrading have a "Upgrade in Progress" configuration status.

Warning

Upgrade the Intrusion Prevention Engine

For devices that are already running Version 6.7 with Snort 2, use the following procedure to update just the Snort engine to version 3:

Procedure

Step 1	In the navigation bar, click Security Devices.
Step 2	Click the Devices tab.
Step 3	Click the FTD tab and select the device or devices you want to upgrade.
Step 4	In the Device Actions pane located to the right, click Upgrade.
Step 5	Set the upgrade toggle to Intrusion Prevention Engine.
Step 6	Click Upgrade to Snort Engine 3.0.
Step 7	From the Security Devices page, devices that are upgrading have a "Upgrade in Progress" configuration status.

Monitor the Upgrade Process

Warning

If you decide to cancel the upgrade while it is in progress, click Abort Upgrade from the Upgrade page. If you cancel the upgrade after it has started, Security Cloud Control does not deploy or check for changes from the device and the device does not roll back to the previous configuration. This may cause the device to enter an unhealthy state. If you experience any issues during the upgrade process, contact Cisco TAC.

If the upgrade fails at any point, Security Cloud Control displays a message. Security Cloud Control does not automatically restart the upgrade process.

Warning

Upgrading devices that have self-signed certificates may experience issues; see New Certificate Detected for more information

Revert From Snort 3.0 for FDM-Managed Device

Some intrusion rules in Snort 2.0 might not exist in Snort 3.0. If you downgrade to 2.0, any custom intrusion policies that you created are converted to the base policy used in the custom policy. As far as possible, rule action overrides are retained. If more than one custom policy uses the same base policy, the overrides of the custom policy that is used in the most access control policies are retained, and the overrides for the other custom policies are lost. Access control rules that used these"duplicate"policies will now use the base policy created from your most-used custom policy. All custom policies are deleted.

Before you opt to revert from Snort 3.0, read Managing Intrusion Policies (Snort2) of the Firepower Device Manager Configuration Guide and find out how switching snort engine versions will affect your current rules and policies.

Note

Reverting to version 2 does not uninstall the Firepower software version.

Revert From Snort 3.0

If you change the Snort version,the system will perform an automatic deployment to implement the change. Note that you can only revert individual devices from Snort 3.0 to version 2.

Use the following procedure to revert the intrusion prevention engine:

Procedure

Step 1	In the navigation pane, click Security Devices.
Step 2	Click the Devices tab.
Step 3	Click the FTD tab and and click the device you want to revert.
Step 4	In the Device Actions pane located to the right, click Upgrade.
Step 5	Set the upgrade toggle to Intrusion Prevention Engine.
Step 6	In Step 1, confirm you want to revert from Snort version 3, and click Revert to Snort Engine 2.
Step 7	From the Security Devices page, devices that are upgrading have a "Upgrade in Progress" configuration status.

Schedule a Security Database Update

Use the following procedure to create a scheduled task to check and update the security databases for an FDM-managed device:

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the FTD tab and select the desired FDM-managed device.

Step 4

In the Actions pane, locate the Security Database Updates section and click the add + button.

Note

If there is an existing scheduled task for the selected device, click the edit icon to create a new task. Creating a new task will overwrite the existing one.

Step 5

Configure the scheduled task with the following:

Frequency - Choose for the update to occur daily, weekly, or monthly.
Time - Choose the time of day. Note that the time displayed is UTC.
Select Days - Choose which day(s) of the week you want the update to occur.

Step 6

Click Save.

Step 7

The device's Configuration Status will change to "Updating Databases".

Edit a Scheduled Security Database Update

Use the following procedure to edit an existing scheduled task to check and update the security databases for an FDM-managed device

Procedure

Step 1	In the left pane, click Security Devices.
Step 2	Click the Devices tab.
Step 3	Click the FTD tab and select the desired FDM-managed device.
Step 4	In the Actions pane, locate the Database Updates section and click the edit icon.
Step 5	Edit the scheduled task with the following: Frequency - Choose for the update to occur daily, weekly, or monthly. Time - Choose the time of day. Note that the time displayed is UTC. Select Days - Choose which day(s) of the week you want the update to occur.
Step 6	Click Save.
Step 7	The device's Configuration Status will change to "Updating Databases".

Update FDM-Managed Device Security Databases

By updating the security databases on an FDM-managed device, you are updating the following: SRUs (intrusion rules), security intelligence (SI), vulnerability databases (VDB), and geolocation databases. If you opt into updating the security databases through the Security Cloud Control UI, note that all of the mentioned databases are updated; you cannot select which databases you want to update.

Please note that security database updates cannot be reverted.

Note

When you update the security databases, some packets may be dropped or pass uninspected. We recommend you schedule your security database updates during a maintenance window.

Update FDM-Managed Device Security Database While Onboarding

When you onboard an FDM-managed device to Security Cloud Control, part of the onboarding process allows you to Enable scheduled recurring updates for databases. This option is checked by default. When enabled, Security Cloud Control immediately checks for and applies any security updates as well as automatically schedules the device to check for additional updates. You are able to modify the date and time of the scheduled task after the device is onboarded.

We recommend enabling the automatic scheduler during the onboarding process to regularly check for and apply security database updates. This way your device will always be up to date. To update the security databases while onboarding your FDM-managed device, see Onboard an FDM-Managed Device with a Registration Key.

Note

If you onboard your device with the registration key method, the device must not be registered with a smart license. We recommend registering an license. As an alternative method, you can onboard your device using the device's username, password, and IP address.

Update FDM-Managed Device Security Database After Onboarding

After an FDM-managed device is onboarded to Security Cloud Control, you can configure a device to check for security database updates by scheduling an update. You can modify this scheduled task at any time by selecting the device the update is scheduled for. See Schedule a Security Database Update for more information.

Managing FDM Devices with Security Cloud Control

Bias-Free Language

Results

Chapter: Onboard Devices and Services

Onboard Devices and Services

Secure Device Connector

Connect Security Cloud Control to your Managed Devices

Connecting Devices to Security Cloud Control Through the Cloud Connector

Connecting Security Cloud Control to SDC

Deploy a VM for Running the Secure Device Connector and Secure Event Connector

Supported Installations

System Requirements

Prepare for Installation

Deploy the VM

Configure the VM

Deploy a Secure Device Connector On Your VM

Before you begin

Procedure

What to do next

Bootstrap a Secure Device Connector on the Deployed Host

Procedure

Deploy a Secure Device Connector to vSphere Using Terraform

Before you begin

Procedure

Example:

Example:

Example:

Deploy a Secure Device Connector on an AWS VPC Using a Terraform Module

Before you begin

Procedure

What to do next

Migrate an On-Premises Secure Device Connector and Secure Event Connector from a CentOS 7 Virtual Machine to an Ubuntu Virtual Machine

Before You Migrate

Prerequisites

Host Configuration

SDC Migration

SEC Migration

Additional Instructions

Change the IP Address of a Secure Device Connector

Before you begin

Procedure

Remove a Secure Device Connector

Procedure

Move an ASA from one SDC to Another

Procedure

Rename a Secure Device Connector

Procedure

Update your Secure Device Connector

Procedure

Using Multiple SDCs on a Single Security Cloud Control Tenant

Security Cloud Control Devices that Use the Same SDC

Procedure

Open Source and Third-Party License in SDC

Supported Devices, Software, and Hardware

Cisco Secure Firewall ASA

Cisco Secure Firewall Threat Defense

Cisco Catalyst SD-WAN Manager

Cisco Secure Firewall Management Center

Cisco Meraki MX

Cisco IOS Devices

Cisco Umbrella

AWS Security Groups

Secure Firewall Threat Defense Device Support Specifics

Firewall Threat Defense with Secure Firewall Device Manager

Snort

Onboard FDM-Managed Device

FDM-managed Device Management

Licensing

Device Addressing

Managing an FDM-Managed Device from the Inside Interface

Remote Access VPN Requirement

What to do next:

Manage an FDM-Managed Device from the Inside Interface

Before you begin

Procedure

What to do next

Managing an FDM-Managed Device from the Outside Interface

Remote Access VPN Requirement

What to do next:

Manage the FDM-Managed Device's Outside Interface