Connect Your Device

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.


Note

Super Administrator user role is required to create a Secure Device Connector and Secure Event Connector.

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:

  • A device with SSH access.

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://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://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://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://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://security.cisco.com, allow inbound access from the following IP addresses:

  • 52.34.234.2

  • 52.36.70.147

Connecting Security Cloud Control to SDC

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

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

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

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

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

  1. Follow the steps below to download the VMware image provided by Security Cloud Control.

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

  1. In the Security Cloud Control platform menu, choose Products > Firewall.

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

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

  4. Click Download the SDC VM image. This opens in a new tab.

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

  6. Log in to your VMware server as an administrator using the vSphere Web Client.


    Note

    Do not use the ESXi Web Client.

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

  7. When the setup is complete, power on the SDC VM.

  8. Open the console for your new SDC VM.

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

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

  2. Start the host configuration by running the command:

    sudo sdc host configure

  3. When prompted for the password, enter adm123 for the Security Cloud Control-provided VM or whatever admin password you chose for your own VM.

  4. Follow the prompts to configure the sdc user.

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

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

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

  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.

  9. Install the latest security patches, some requires os tools and Docker server.

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

  11. 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 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 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 Firewall in Security Cloud Control 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.

  • 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 Security Cloud Control platform menu, choose Products > Firewall.

Step 3

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

Step 4

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

Step 5

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

Step 6

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 7

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

Step 8

Configure a DNS (Domain Name Server) server.

Step 9

Configure a NTP (Network Time Protocol) server.

Step 10

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

Step 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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 21

Change directories to /usr/local/CDO.

Step 22

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 23

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 24

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 25

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 26

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

Bootstrap a Secure Device Connector on the Deployed Host

Procedure

Step 1

In the Security Cloud Control platform menu, choose Products > Firewall.

Step 2

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

Step 3

On the Services page, select the Secure Connectors tab, click the + icon, and select Secure Device Connector.

Step 4

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

Step 5

SSH into your VM using the admin user, typically cdo, and your chosen password.

Step 6

Switch to the sdc user using the command: 

sudo su - sdc

Step 7

Bootstrap your new SDC using the command:

sdc bootstrap <paste-your-bootstrap-data-here>

Step 8

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 9

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 Firewall in Security Cloud Control 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

Register instance_id as an output in your Terraform code: 

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

Firewall in Security Cloud Control'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:

  1. Download the new VM image here.

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

  3. Deploy the VM you just downloaded.

  4. Note the static IP address or FQDN you assigned to the new VM.

  5. Using SSH, log in to the new VM as the cdo user.

  6. 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:

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

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

  3. Run the following command and follow the prompts:

    sudo sdc migrate now

Verification:

  1. Log in to your Security Cloud Control tenant.

  2. 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:

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

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

  3. Run the following command and follow the prompts:

    sudo sdc eventing migrate

  4. 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:

  1. Log in to the new VM and switch to the SDC user.

  2. Ensure the SDC is not currently running on the new VM using the command:

    docker ps

  3. If the SDC is running, run the command:

    sdc stop

  4. Confirm that the SDC has stopped running by executing docker ps again.

  5. Log in to the old VM and run the command:

    sdc migrate revert

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

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

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

Step 2

In the Security Cloud Control platform menu, choose Products > Firewall.

Step 3

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

Step 4

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

Step 5

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

Step 6

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 7

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

Step 8

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 Manage > Security Devices.

Step 2

Click the ASA tab.

Step 3

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

Step 4

In the Device Actions pane, click Update Credentials.

Step 5

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

Step 6

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

Note

 

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

Rename a Secure Device Connector

Procedure

Step 1

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

Step 2

Select the SDC you want to rename.

Step 3

In the Details pane, click the edit icon next to the name of the SDC.

Step 4

Rename the SDC.

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

Update your Secure Device Connector

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

Procedure

Step 1

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

Step 2

Log in to the SDC as the admin user, typically cdo.

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, Manage > 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.