Cisco Defense Orchestrator has two types of secure connectors, the Secure Device Connector (SDC) and the Secure Event Connector (SEC). If you're looking for instructions for specific tasks, skip to the Related Topics at the end of this article.
Secure Device Connectors
All communication between Cisco Defense Orchestrator (CDO) and the devices it manages passes through a Secure Device Connector (SDC). CDO and the devices it manages do not communicate directly.
SDCs can be deployed in the cloud or in your network with the following methods:
- Cloud Secure Device Connector. The CDO support team deploys a cloud-based SDC for every tenant when the tenant is created. Only the CDO support team can deploy and service a cloud-based SDC.
- On-Premises Secure Device Connector. The on-premises SDC is a virtual appliance installed in your network. You can create your on-premises SDC by using an image provided by CDO or you can create your own VM and install the SDC on it. The on-premises SDC virtual appliance includes a CentOS operating system and runs on a Docker container. For CDO-managed devices that are non-perimeter based, do not have a public IP address, or an open port to the outside interface, we recommended you use the on-premises SDC which enables onboarding, accessing, reading, and writing to those devices using internal IP addresses.
Both SDC deployment models use secure communication messages signed and encrypted using AES-128-GCM over HTTPS (TLS 1.2) to communicate with CDO. 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, whether cloud or on-premises, has access to the device credentials. No other CDO service has access to the credentials. See Connect to Cisco Defense Orchestrator using Secure Device Connector for information explaining how to allow communication between between an SDC and CDO.
At any time, customers can choose to leverage either the Cisco-managed cloud deployed SDC or the customer-managed, on-premises, SDC. All requests can be completed by contacting your Cisco account manager or opening a support case from the Contact Support page.
For desired CDO-managed devices that are non-perimeter based, do not have a public IP address, or an open port to the outside interface, we recommended you use the on-premises SDC which enables onboarding, accessing, reading, and writing to those devices using internal IP addresses.
Click here to troubleshoot your SDC.
Using Multiple SDCs on a Single CDO Tenant
Deploying more than one SDC for your tenant allows you to manage more devices with your CDO tenant 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.
Additionally, because you can deploy more than one SDC, you can manage devices in isolated network segments with the same CDO tenant. Up to 5 network segments could have their own on-premises SDC. These SDCs would connect the devices in those network segments to the same CDO tenant. Without multiple SDCs, you would need to manage the devices in isolated network segments with different CDO tenants.
CDO support deploys 1 cloud SDC for every tenant and customers can install 4 on-premises SDCs for a maximum number of 5 SDCs per tenant. You cannot have more than one cloud-based SDC per tenant. Customers can also ask CDO support to remove the cloud SDC their tenant is originally provisioned with and replace it with an on-premises SDC.
Having more than one SDC does not imply load-balancing or a high-availability configuration between the SDCs. However, if you have more than one SDC, you can manually move ASA, AWS VPC, and Meraki MX devices from one SDC to another.
The procedure for deploying a second or subsequent SDC is the same for deploying your first on-premises SDC. You can create the on-premises SDC using an SDC image that CDO provides or you can install a virtual machine or appliance from scratch and install the on-premises SDC. The initial on-premises SDC for your tenant incorporates the name of your tenant and the number 1. Each additional on-premises SDC is numbered in order.
Secure Event Connectors
The Secure Event Connector (SEC) receives events from ASA and FTD devices and forwards them to the Cisco cloud. CDO displays the events on the Event Logging page so that administrators can analyze them there or by using Cisco Stealthwatch Cloud, depending on their licensing.
SECs can be installed on a tenant with a cloud or on-premises SDC. If you have an on-premises Secure Device Connector, your first SEC is installed on the same VM as that SDC. If you have a cloud SDC, your first SEC is installed on an on-premises VM that you maintain in your own private cloud. In either the cloud SDC case or the on-premises SDC case, your second, third, or subsequent SEC is installed on a VM that you maintain in your own private cloud.
Click here to troubleshoot your SEC.
The SEC ID is a detail that is displayed on the Secure Connectors page. From the user menu, select Secure Connectors and then click on the SEC you wish to identify. The SEC ID is the ID listed above the tenant ID. This information may be needed by Cisco Technical Assistance Center (TAC) or other CDO Support.
- Connect Cisco Defense Orchestrator to the Secure Device Connector
- Deploy an On-Premises Secure Device Connector Using CDO's VM Image
- Deploy an On-Premises Secure Device Connector on your own VM
- Troubleshoot an On-Premise Secure Device Connector
- Update your On-Premises Secure Device Connector
- Cisco Security Analytics and Logging for ASA Devices
- Cisco Security Analytics and Logging for FTD Devices
- Remove an On-Premises Secure Device Connector
- Install the Secure Event Connector on an On-Premises SDC Virtual Machine
- Install Multiple SECs for Your Tenant Using a CDO VM Image
- Install Multiple SECs for Your Tenant Using a VM Image you Create
- Remove the Secure Event Connector
- Deprovisioning Cisco Security Analytics and Logging (SaaS)