Onboard Devices and Services
Secure Device Connector
Supported Devices, Software, and Hardware
- ASA Support Specifics
- Cloud Device Support Specifics
Onboard ASA Devices

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.

See Secure Device Connector for more information on the SDC and its state.

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).

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

An ASA device that is not accessible from the cloud.

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.

Special Consideration for Connecting an ASA to an SDC

Specifically, for ASA the SDC uses the same secure communications channel used by ASDM.

If the ASA under management is also configured to accept AnyConnect VPN Client connections, the ASDM HTTP server port must be changed to a value of 1024 or higher. Note that this port number will be the same port number used when onboarding the ASA device into Security Cloud Control.

Example ASA Commands

The following examples assume that the ASA outside interface is named 'outside' and an AnyConnect client is configured on the ASA so the ASDM HTTP server is listening on port 8443.

To enable the outside interface, enter these commands:

Asia-Pacific-Japan Region:

http 54.199.195.111 255.255.255.255 outside
http 52.199.243.0 255.255.255.255 outside

Australia Region

http 13.55.73.159 255.255.255.255 outside
http 13.238.226.118 255.255.255.255 outside

EMEA Region

http 35.157.12.126 255.255.255.255 outside
http 35.157.12.15 255.255.255.255 outside

India Region

http 35.154.115.175 255.255.255.255 outside
http 13.201.213.99 255.255.255.255 outside

United States Region

http 52.34.234.2 255.255.255.255 outside
http 52.36.70.147 255.255.255.255 outside

To enable the ASDM HTTP server port, in the case where AnyConnect VPN Client is in use, enter this command:

http server enable 8443

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. You can do this one of two ways:

Move some devices to different SDCs or off of an SDC entirely. See below for more information:
Remove from Security Cloud Control 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.

Specify a Default Secure Device Connector

Many devices managed by Security Cloud Control, though not all, connect to Security Cloud Control through a SDC. When you onboard devices that connect to Security Cloud Control through an SDC, they are associated with the default SDC for your tenant unless you specify otherwise during onboarding.

You can specify which SDC is selected by default on the Secure Connectors page:

Procedure

Step 1	In the left pane, choose Administration > Secure Connectors.
Step 2	Select the SDC that you want to be the default.
Step 3	In the Actions pane, click Make Default. If you don't see the Make Default action, then the SDC already is the default SDC.

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.

ASA Support Specifics

Security Cloud Control can manage all platforms running currently supported code versions, including ASAv instances, except for the ASA Services Module (ASASM), which is not supported by Security Cloud Control.

Note

We do not test end-of-life ASA code versions and do not recommend using them in production. For optimal results, we suggest using the currently supported ASA code versions. Additionally, ASA 8.3 is not supported with the new policy view.

There may be a Security Cloud Control feature that does not support all versions of ASA, such as ASA upgrades" from pre-9.12 versions. In those cases, the Security Cloud Control documentation will list any version exceptions with the prerequisites for that feature.

Security Cloud Control does not manage the ASA FirePOWER module, which runs a different operating system from ASA. You must manage an ASA FirePOWER module separately with Firepower Management Center or ASDM.

Note

EOL code and hardware may continue work with Security Cloud Control, but we cannot assure all functionality of Security Cloud Control with respect to EOL code and hardware, as it is not part of our testing. Security Cloud Control makes no guarantees nor assurances of correct operation with EOL software and hardware. An example of this would be the EOL ASA versions 8.x, 9.1, and 9.2 do not support TLS 1.2 on the management plane and would be considered an insecure way to manage ASA software.

Please defer to the version download page for Cisco "suggested release" or "gold star" versions.

For a full discussion of ASA, ASDM, and hardware compatiblity, see the Cisco Secure Firewall ASA Compatibility guide.

Cloud Device Support Specifics

The following table describes software and device type support for cloud-based devices. Read the affiliated links for more information about onboarding and feature functionality for the device types in the table below:


Devices Types	Notes
Google Cloud Platform	Google Cloud Platform (GCP) receives any updates through the GCP console. See Google Cloud documentation for more information on the platform and available services. See
Microsoft Azure	Azure receives any updates through the Azure console. See Azure documentation for more information on the platform and available services.

Onboard ASA Devices

Onboard ASA Device to Security Cloud Control

Use this procedure to onboard a single live ASA device, not an ASA model, to Security Cloud Control. If you want to onboard multiple ASAs at once, see Onboard ASAs in Bulk.

Before you begin

Device Prerequisites

Review Connect Security Cloud Control to your Managed Devices.

Device must be running at least version 8.4+.

Note

TLS 1.2 was not available for the ASA management-plane until version 9.3(2). With version 9.3(2), a local SDC is required to onboard to Security Cloud Control.

The running configuration file of your ASA must be less than 4.5 MB.

To confirm the size of your running configuration file, see Confirming ASA Running Configuration Size.
IP addressing: Each ASA, ASAv, or ASA security context must have a unique IP address and the SDC must connect to it on the interface configured to receive management traffic.

Certificate Prerequisites

If your ASA device does not have a compatible certificate, onboarding the device may fail. Ensure the following requirements are met:

The device uses a TLS version equal to or greater than 1.0.
The certificate presented by the device is not expired, and its issuance date is in the past (i.e. it is already valid, not scheduled to become valid at a later date).
The certificate must be a SHA-256 certificate. SHA1 certificates are not accepted.
One of these conditions is true:
- The device uses a self-signed certificate, and it is the same as the most recent one trusted by an authorized user.
- The device uses a certificate signed by a trusted Certificate Authority (CA), and provides a certificate chain linking the presented leaf certificate to the relevant CA.

If you experience certificate errors during the onboarding process, see Cannot onboard ASA due to certificate errorfor more information.

Open SSL Cipher Prerequisites

If the device does not have a compatible SSL cipher suite, the device cannot successfully communicate to the Secure Device Connector (SDC). Use any of the following cipher suites:

ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA256
DHE-RSA-AES256-SHA256

If the cipher suite you use on your ASA is not in this list, the SDC does not support it and you will need to update the cipher suite on your ASA.

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Onboard device or service ().

Step 3

Click the ASA tile.

Step 4

In the Locate Device step, perform the following:

Click the Secure Device Connector button and select a Secure Device Connector installed in your network. If you would rather not use an SDC, Security Cloud Control can connect to your ASA using the Cloud Connector. Your choice depends on how you connect Security Cloud Control to your managed devices.
Give the device a name.
Enter the location (IP address, FQDN, or URL) of the device or service. The default port is 443.
Click Next.

Step 5

In the Credentials step, enter the username and password of the ASA administrator, or similar highest-privilege ASA user, that Security Cloud Control will use to connect to the device and click Next.

Step 6

(Optional) In the Done step, enter a label for the device. You will be able to filter your list of devices by this label. See Labels and Label Groups for more information.

Step 7

After labeling your device or service, 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.

Onboard a High Availability Pair of ASA Devices to Security Cloud Control

When onboarding an ASA that is part of a high-availability pair, use Onboard ASA Device to Security Cloud Control to onboard only the primary device of the pair.

Onboard an ASA in Multi-Context Mode to Security Cloud Control

About Multi-Context Mode

You can partition a single ASA, installed on a physical appliance, into multiple logical devices known as contexts. There are three kinds of configurations used in an ASA configued in multi-context mode:

Security Context
Admin Context
System Configuration

About Security Contexts

Each security context acts as an independent device, with its own security policy, interfaces, and administrators. Multiple security contexts are similar to having multiple standalone devices. A security context is not a virtual ASA in the sense of a virtual machine image installed in a private cloud infrastructure. A security context is configured on an ASA installed on a hardware appliance. Each context is configured on a physical interface of that appliance.

See the ASA CLI and ASDM configuration guides for more information about multi-context mode.

Security Cloud Control onboards each security context as a separate ASA and manages it as if it were a separate ASA.

About Admin Contexts

The admin context is like a security context, except that when a user logs in to the admin context, then that user has system administrator rights and can access the system and all other contexts. The admin context is not restricted in any way, and can be used as a regular context. However, because logging into the admin context grants you administrator privileges over all contexts, you might need to restrict access to the admin context to appropriate users.

Security Cloud Control onboards each admin context as a separate ASA and manages it as if it were a separate ASA. Security Cloud Control also uses the admin context when upgrading ASA and ASDM software on the appliance.

About System Configuration

The system administrator adds and manages contexts by configuring each context configuration location, allocated interfaces, and other context operating parameters in the system configuration, which, like a single mode configuration, is the startup configuration. The system configuration identifies basic settings for the ASA. The system configuration does not include any network interfaces or network settings for itself; rather, when the system needs to access network resources (such as downloading the contexts from the server), it uses one of the contexts that is designated as the admin context.

Security Cloud Control does not onboard the system configuration.

Onboarding Prerequisites for Security and Admin Contexts

The prerequisites for onboarding security and admin contexts are the same for onboarding any other ASA. See Onboard ASA Device to Security Cloud Controlfor the list of prerequisites.

To learn which Cisco appliances support ASAs in multi-context mode, see the "Multiple Context Mode" chapter in the CLI Book 1: Cisco ASA Series General Operations CLI Configuration Guide for whatever ASA software version you are running.

For an ASA running as a single context firewall and for the admin context of a multiple-context firewall, many different port numbers could be used for ASDM and Security Cloud Control access. However, for security contexts, the ASDM and Security Cloud Control access port is fixed to port 443. This is a limitation of ASA.

Onboarding ASA Security and Admin Contexts

The method of onboarding a security context or admin context is the same for onboarding any other ASA. See Onboard ASA Device to Security Cloud Control or Onboard Multiple ASAs to Security Cloud Control for onboarding instructions.

Upgrading Security Contexts

Security Cloud Control treats each security and admin context of a multiple-context ASA as a separate ASA and each is onboarded separately. However, all security and admin contexts of a multiple-context ASA run the same version of ASA software installed on the appliance.

To upgrade the versions of ASA and ASDM used by the ASA's security contexts, you onboard the the admin context and perform the upgrade on that context.

See Upgrade ASA and ASDM Images on a Single ASA or Upgrade Bulk ASA and ASDM in Security Cloud Control Upgrade Bulk ASA and ASDM in Security Cloud Controlfor more information.

Onboard Multiple ASAs to Security Cloud Control

Security Cloud Control allows you to bulk onboard ASAs by providing the necessary information for all the ASAs in a .csv file. As the ASAs are being onboarded, you can use the filter pane to show which onboarding attempts are queued, loading, complete, or have failed.

Before you begin

Review Connect Security Cloud Control to your Managed Devices.
Prepare a .csv file with the connection information of the ASAs you want to onboard. Add the information about one ASA on its own line. You can use a # at the beginning of a line to indicate a comment.
- ASA location (either IP address or FQDN)
- ASA administrator username
- ASA administrator password
- (Optional) Device name for Security Cloud Control
- In the SDCName field, specify the name of a Secure Device Connector (SDC) in your network you want to use to connect Security Cloud Control to your ASA. You can also enter "none" if you are not going to connect your ASA to Security Cloud Control using an SDC. When onboarding the device, specifying "none" in SDCName field, onboards the ASA using the Cloud Connector. The Cloud Connector allows you to connect your device to Security Cloud Control without installing an SDC. Your choice depends on how you connect Security Cloud Control to your managed device.
- (Optional) Device labels for Security Cloud Control
- To add one label, add the label name to the last CSV field.
- To add more than one label to a device, surround the values with quotes. For example, alpha,beta,gamma.
- To add a category and choice label, separate the two values with a colon ( : ). For example, Rack:50.

Sample of the configuration file:


#Location,Username,Password,DeviceName,SDCName,DeviceLabel 
192.168.3.2,admin,CDO123!,ASA3,sdc1,"HA-1,Rack:50" 
192.168.4.2,admin,CDO123!,ASA4,sdc1,"HA-1,Rack:50" 
ASA2.example.com,admin,CDO123!,ASA2,none,Rack:51 
asav.virtual.io,admin,CDO123!,ASA-virtual,sdc3,Test

Caution

Security Cloud Control does not validate any of the data in the .csv file. You need to ensure the accuracy of the entries.

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the blue plus button to onboard an ASA.

Step 3

On the Onboarding page, click the Multiple ASAs tile.

Step 4

Click Browse to locate the .csv file containing your ASA entries. The devices you specified are now queued in the ASA Bulk Onboarding table ready to be onboarded.

Caution

Do not navigate away from the ASA Bulk Onboarding page until the onboarding process is complete. Navigating away stops the onboarding process.

Step 5

Click Start. You will see the progress of the onboarding process in the status column of the ASA Bulk Onboarding table. After the device have been successfully onboarded you will see their status change to "Complete."

What to do next

If you need to pause bulk onboarding and resume it later, see Pause and Resume Onboarding Multiple ASAs

Pause and Resume Onboarding Multiple ASAs

If you need to pause the onboarding process, click Pause. Security Cloud Control finishes onboarding any device it started onboarding. To resume the bulk onboarding process, click Start. Security Cloud Control will start onboarding the next queued device.

If you click Pause and navigate away from this page, you will need to return to the page and follow the bulk onboarding procedure again from the beginning. However, Security Cloud Control recognizes the devices it has already onboarded, marks the devices from this new onboarding attempts as duplicates, and quickly moves through the list to onboard the queued devices.

Create and Import an ASA Model to Security Cloud Control

Procedure

Step 1	In the left pane, click Security Devices.
Step 2	Click the Devices tab.
Step 3	Click the ASA tab.
Step 4	Select an ASA device and in the Management on the left pane, click Configuration.
Step 5	Click Download to download the device configuration to your local computer.

Import ASA Configuration

Attention: The ASA running configuration file you are onboarding must be less than 4.5 MB. Confirm the size of the configuration file before you onboard it.

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the blue plus () button to import the configuration.

Step 3

Click on Import configuration for offline management.

Step 4

Select the Device Type as ASA.

Step 5

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

Step 6

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

Step 7

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.

Import Configuration for Offline Device Management

Importing a device's configuration for offline management allows you to review and optimize a device's configuration without having to work on a live device in your network. Security Cloud Control also refers to these uploaded configuration files as "models."

You can import the configurations of these devices to Security Cloud Control:

Adaptive Security Applicance (ASA). See Create and Import an ASA Model.
Cisco IOS devices like the Aggregation Services Routers (ASR) and Integrated Services Routers (ISRs).

Prerequisites for ASA and ASDM Upgrade in Security Cloud Control

Security Cloud Control provides a wizard that helps you upgrade the ASA and ASDM images installed on an individual ASA, multiple ASAs, ASAs in an active-standby configuration, and ASAs running in single-context or multi-context mode.

Security Cloud Control maintains a repository of ASA and ASDM images that you can upgrade to. When you choose your upgrade images from Security Cloud Control's image repository, Security Cloud Control performs all the necessary upgrade steps behind the scenes. The wizard guides you through the process of choosing compatible ASA software and ASDM 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 ASA. Security Cloud Control periodically reviews its inventory of ASA binaries and adds the newest ASA and ASDM images to its repository when they are available. This is the best option for customers whose ASAs have outbound access to the internet.

Security Cloud Control's image repository only contains generally available (GA) images. If you do not see a specific GA image in the list, please contact Cisco TAC or email support from the Contact Support page. We will process the request using the established support ticket SLAs and upload the missing GA image.

If your ASAs do not have outbound access to the internet, you can download the ASA and ASDM images 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. You can retrieve the images from your repository using any of these protocols: FTP, TFTP, HTTP, HTTPS, SCP, and SMB.

Configuration Prerequisites for All ASAs

DNS needs to be enabled on the ASA.
ASA should be able to reach the internet if you use upgrade images from Security Cloud Control's image repository.
Ensure HTTPS connectivity between the ASA and the repository FQDN.
The ASA has been successfully onboarded to Security Cloud Control.
The ASA is synced to Security Cloud Control.
The ASA is online.
For custom URL upgrades:
- Use the Cisco ASA Upgrade Guide to determine what version of ASA and ASDM are compatible with your ASAs.
- Download the ASA and ASDM images to your image repository.
- Ensure that the ASA has access to your image repository.
- Ensure you have enough disk space on your ASA for your ASA and ASDM images.
- Read Custom URL Upgrade for URL syntax information.

Configuration Prerequisites for Firepower 1000 and Firepower 2100 Series Devices

The FXOS mode of a Firepower 2100 series device must be configured for appliance mode. See Set the Firepower 2100 to Appliance or Platform Mode for more information.
The device must be running ASA Version 9.13(1) or later.
You must upgrade the FXOS bundle prior to upgrading the ASA software. See Firepower 2100 ASA and FXOS Compatibility for more information.

Firepower 4100 and Firepower 9300 Series Devices Running ASA

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

Upgrade Guidelines

Security Cloud Control can upgrade ASAs configured as an Active/Standby "failover" pair. Security Cloud Control cannot upgrade ASAs configured in an Active/Active "clustered" pair.

Software and Hardware Prerequisites

Minimum ASA and ASDM versions from which you can upgrade:

ASA: ASA 9.1.2
ASDM: There is no minimum version.

Supported Hardware Versions

See ASA Software and Hardware Support.

Upgrade Bulk ASA and ASDM in Security Cloud Control

Procedure

Step 1

Review ASA and ASDM Upgrade Prerequisites for upgrade requirements and important information about upgrading ASA and ASDM images.

Note

If you are upgrading an ASA 1000 or 2000 series device, be sure to read Configuration Prerequisites for 1000 and 2000 Series.

Step 2

(Optional) In the left pabe, click Security Devices.

Step 3

Create a change request label to identify the devices upgraded by this action in the change log.

Step 4

Click the Devices tab.

Step 5

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

Step 6

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

Step 7

In the Device Actions pane, click Upgrade.

Step 8

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 9

In step 1, click Use Security Cloud Control Image Repository to select the ASA software image you want to upgrade to, and click Continue.

The list indicates how many of the ASAs you chose can be upgraded to the software version you chose. In the example below, all of the devices can be upgraded to version 9.9(1.2), two devices can be upgraded to 9.8(2), and one of the devices can be upgraded to 9.6(1).

Security Cloud Control alerts you if any of the software versions you chose are incompatible with any of the devices you chose. In the example below, Security Cloud Control cannot upgrade the 10.82.109.176 device to a version earlier than it already runs.

Step 10

In step 2, select the ASDM image you want to upgrade to. You are only presented with ASDM choices that are compatible with the ASA you can upgrade.

Step 11

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

Step 12

Click Perform Upgrade when you are ready.

Note

If the upgrade fails, Security Cloud Control displays a message. Often the reason for a failed upgrade is a network issue preventing the ASA and ASDM images from being transferred to the ASA.

Step 13

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 14

(For multi-context mode) After the admin context and the security contexts boot, you may see that the security contexts display the message, "New certificate detected." If you see that message, accept the certificate for all security contexts. Accept any other changes caused by the upgrade.

Step 15

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 16

If you created and activated a change request label, remember to clear it so that you don't inadvertently associate other configuration changes with this event.

Upgrade Multiple ASAs with Images from your own Repository

Procedure

Step 1

Review ASA and ASDM Upgrade Prerequisites for upgrade requirements and important information about upgrading ASA and ASDM images.

Step 2

(Optional) In the left pane, click Security Devices.

Step 3

Create a change request label to identify the devices upgraded by this action in the change log.

Step 4

Click the Devices tab.

Step 5

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

Step 6

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

Step 7

In the Device Actions pane, click Upgrade.

Step 8

In step 1, click Specify Image URL, enter the URL to the ASA image you want to upgrade to in the In the Software Image URL field, and click Continue. See Custom URL Upgrade for URL syntax information.

Note

The picture below shows an HTTPS URL in the Software Image URL field. You can retrieve the images from your repository using any of these protocols: FTP, TFTP, HTTP, HTTPS, SCP, and SMB. See Custom URL Upgrade for URL syntax information.

Step 9

In step 2, click Specify Image URL, enter the URL to the ASDM image you want to upgrade to in the In the Software Image URL field, and click Continue.

Step 10

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

Step 11

Click Perform Upgrade when you are ready.

Note

If the upgrade fails, Security Cloud Control displays a message. Often the reason for a failed upgrade is a network issue preventing the ASA and ASDM images from being transferred to the ASA.

Step 12

Step 13

Step 14

Step 15

If you created and activated a change request label, remember to clear it so that you don't inadvertently associate other configuration changes with this event.

What to do next

Upgrade Notes

You can also monitor the progress of the batch of upgrades by opening the Security Devices page and viewing the Configuration Status column in the table.
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. Security Cloud Control takes you to the Device Upgrade page for that device.

Upgrade ASA and ASDM Images on a Single ASA

Follow this procedure to upgrade the ASA and ASDM images on a single ASA.

Procedure

Step 1

Review ASA and ASDM Upgrade Prerequisites for upgrade requirements and important information about upgrading ASA and ASDM images.

Note

If you are upgrading an ASA 1000 or 2000 series device, be sure to read Configuration Prerequisites for 1000 and 2000 Series.

Step 2

In the left pane, click Security Devices.

Step 3

Click the Devices tab.

Step 4

(Optional) Create a change request label to identify the device upgraded by this action in the change log.

Step 5

Select the device you want to upgrade.

Step 6

In the Device Actions pane, click Upgrade.

Step 7

On the Device Upgrade page, follow the instructions presented to you by the wizard.

In step 1, click Use Security Cloud Control Image Repository to select the ASA software image you want to upgrade to, and click Continue.

Note

When upgrading your ASAs and ASDMs to images stored in your own repository, select Specify Image URL and enter the URL of the ASA or ASDM image in the Software Image URL field. You can retrieve the images from your repository using any of these protocols: FTP, TFTP, HTTP, HTTPS, SCP, and SMB. See Custom URL Upgrade for URL syntax information.

(Optional) 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 Schedule Upgrade.

In step 2, select the ASDM image you want to upgrade to. You are only presented with ASDM choices that are compatible with the ASA you can upgrade.
In step 3, confirm your choices and decide whether you only want to download the images to your ASAs or copy the images, install them, and reboot the device.

Step 8

Click Perform Upgrade when you are ready.

Step 9

What to do next

Upgrade Notes

If you select an image to upgrade to, and you change your mind, check the Skip Upgrade check box associated with the software image. The image will not be copied to the device, nor will the device be upgraded with the image.
In the Perform Upgrade step, if you choose only to copy the images to the ASA, you can return to the Device Upgrade page later and click "Upgrade Now" to perform the upgrade. After the copying task is complete, you will see the message "Ready to Upgrade" for that device on the Security Devices page.
You cannot take action on a device during the process of copying the image, installing it, and rebooting the device. Devices that are installing the image and then rebooting are shown as "Upgrading" in the Security Devices page.
You cannot take action on a device during the upgrade process; that is, installing the image and rebooting the device.
You can take action on a device if you choose only to copy the images to the device. Devices that are copying images are shown as "Copying Images" in the Security Devices page.
Upgrading devices that have self-signed certificates may experience issues; see New Certificate Detected for more information.

Upgrade ASA and ASDM Images in a High Availability Pair

Before you upgrade your pair of ASAs in active/standby failover mode, review the prerequisites below. If you need more information about how ASAs are configured and work in failover mode, see Failover for High Availability in the ASA documentation.

Want to see a demo? Watch a screencast of this procedure.

Prerequisites

Review ASA and ASDM Upgrade Prerequisites for requirements and important information about upgrading ASA and ASDM images.
The primary (active) and secondary (standby) ASAs are configured in active/standby failover mode.
The primary ASA is the active device in the active/standby pair. If the primary ASA is inactive, Security Cloud Control will not perform the upgrade.
The primary and secondary ASA software versions are the same.

Workflow

This is the process by which Security Cloud Control upgrades the active/standby pair of ASAs:

Procedure

Step 1

Security Cloud Control downloads the ASA and ASDM images to both ASAs.

Note

Users have the choice of downloading ASA and ASDM images but not upgrading immediately. If the ASA and ASDM images were downloaded previously, Security Cloud Control will not download them again; Security Cloud Control continues the upgrade workflow with the next step.

Step 2

Security Cloud Control upgrades the secondary ASA first.

Step 3

Once the upgrade is complete and the secondary ASA returns to the "Standby-Ready" state, Security Cloud Control initiates a failover so that the secondary ASA becomes the active ASA.

Step 4

Security Cloud Control upgrades the primary ASA, which is now the current standby ASA.

Step 5

Once the primary ASA returns to the "Standby-Ready" state, Security Cloud Control initiates a failover so that the primary ASA becomes the active ASA.

Warning

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

Upgrade ASA and ASDM Images in a High Availability Pair

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Select the device you want to upgrade.

Step 4

In the Device Actions pane, click Upgrade.

Notice that the failover mode of the device is Active/Standby:

Step 5

On the Device Upgrade page, follow the instructions presented to you by the wizard.

Note

Upgrade an ASA or ASDM Using Your Own Image

When you upgrade your ASA with new ASA software and ASDM images, you can either use images that Security Cloud Control stores in its image repository or you can use images that you store in your own image repository. If your ASA does not have outbound access to the internet, maintaining your own image repository is the best option for upgrading your ASAs using Security Cloud Control.

Security Cloud Control uses ASA's copy command to retrieve the image and copy it to the flash drive (disk0:/) of your ASA. In the Specify Image URL field you are providing the URL portion of the copy command. For example, if the whole copy command would have been:

 ciscoasa# copy ftp://admin:adminpass@10.10.10.10/asa991-smp-k8.bin disk:/0

You are providing:

ftp://admin:adminpass@10.10.10.10/asa991-smp-k8.bin

in the Specify Image URL field.

Security Cloud Control supports http, https, ftp, tftp, smb, and scp methods of retrieving the upgrade image.

URL Syntax examples

Here are examples of URL syntax for the ASA copy command. For the sake of these URL examples, assume the following:

Image repository address: 10.10.10.10
Username to access the image repository: admin
Password: adminpass
Path: images/asa
Image filename: asa991-smp-k8.bin

http[s]:// [[ user [ : password ] @ ] server [ : port ] / [ path / ] filename ]

https://admin:adminpass@10.10.10.10:8080/images/asa/asa991-smp-k8.bin 
HTTP[s] example without a username and password: 
https://10.10.10.10:8080/images/asa/asa991-smp-k8.bin

ftp:// [[ user [ : password ] @ ] server [: port ] / [ path / ] filename [ ;type= xx ]]â€”The type can be one of these keywords: ap (ASCII passive mode),an (ASCII normal mode), ip(Defaultâ€”Binary passive mode), in (Binary normal mode).

ftp://admin:adminpass@10.10.10.10:20/images/asa/asa991-smp-k8.bin 
FTP example without a username and password: 
ftp://10.10.10.10:20/images/asa/asa991-smp-k8.bin

tftp:// [[ user [ : password ] @ ] server [ : port ] / [ path / ] filename [ ;int= interface_name ]]

tftp://admin:adminpass@10.10.10.10/images/asa/asa991-smp-k8.bin outside 
TFTP example without a username and password: 
tftp://10.10.10.10/images/asa/asa991-smp-k8.bin outside

Note

The pathname cannot contain spaces. If a pathname has spaces, set the path in the tftp-server command instead of in the copy tftp command. The ;int= interface option bypasses the route lookup and always uses the specified interface to reach the TFTP server.

smb:/[[ path / ] filename ] - Indicates a UNIX server local file system.

smb:/images/asa/asa991-smp-k8.bin

scp:// [[ user [ : password ] @ ] server [ / path ] / filename [ ;int= interface_name ]]â€”The;int= interface option bypasses the route lookup and always uses the specified interface to reach the Secure Copy (SCP) server.

 scp://admin:adminpass@10.10.10.10:8080/images/asa/asa991-smp-k8.bin outside 
SCP example without a username and password: 
scp://10.10.10.10:8080/images/asa/asa991-smp-k8.bin outside

The complete copy command with URL syntax in the Cisco ASA Series Command Reference, A - H Commands guide.

See ASA and ASDM Upgrade Prerequisites for more information about upgrading ASA and ASDM images using a custom URL.

Managing Secure Firewall ASA 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

Special Consideration for Connecting an ASA to an SDC

Example ASA Commands

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

Specify a Default 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

ASA Support Specifics

Cloud Device Support Specifics

Onboard ASA Devices

Onboard ASA Device to Security Cloud Control

Before you begin

Procedure

Onboard a High Availability Pair of ASA Devices to Security Cloud Control

Onboard an ASA in Multi-Context Mode to Security Cloud Control

About Multi-Context Mode

About Security Contexts

About Admin Contexts

About System Configuration

Onboarding Prerequisites for Security and Admin Contexts

Onboarding ASA Security and Admin Contexts