Secure Connect to Secure Access Manual Migration Guide

Authentication 

Most common IdP providers have capability to be connected to different systems.  Similarly your current IdP connected to Secure Connect, can be easily integrated with Secure Access at the same time without any interruptions to the existing working environment. 

• For SAML authentication, exchange metadata between Secure Access and the IdP. Please follow Configure Integrations with SAML Identity Providers documentation to integrate your IdP with Secure Access organization. 

Resources and Applications 

To migrate Resources and Applications from Cisco Secure Connect to Private Resources in Cisco Secure Access, follow these key steps: 

• Create private resource groups in Secure Access. 

API available:  https://developer.cisco.com/docs/cloud-security/create-resource-group/ 

• Define private resources in Secure Access by specifying the resource name, internally reachable addresses, protocols, and ports. 

API available:  https://developer.cisco.com/docs/cloud-security/list-private-resources/ 

• Configure endpoint connection methods, enabling VPN connections and/or Zero Trust connections as needed. 

• Add the newly created private resources to previously configured resource Connector Groups 

API available:  https://developer.cisco.com/docs/cloud-security/secure-access-api-reference-connector-groups-overview/ 

• Repeat this for each private resource you need to migrate, ensuring the details match those previously configured in Secure Connect. 

Resources: Manage Private Resources 

Posture Profiles 

There are 2 posture profiles types that require migration to Secure Access: 

1. Zero trust network access endpoint posture profiles 

• Client-based 

• Browser-based 

2. VPN access posture profiles 

 

• From the Secure Access portal, create new endpoint posture profiles defining the compliance criteria for user devices. 

• Posture profiles can include checks for operating system, firewall, disk encryption, endpoint security agents, certificates, and other attributes. 

• All elements of posture configuration should be exactly copied.  

• Secure Access VPN Profiles have additional posture configurations that allow for more granular control. These are not required for the migration, and can be left at default as "not required" 

• In Secure Access, configure VPN profiles to reference the created posture profiles. 

 

Resource: Endpoint Posture Profiles  

Remote Access VPN End User Connectivity 

To migrate remote access configuration from Cisco Secure Connect to end user connectivity in Cisco Secure Access, follow these key steps: 

1. Configure IP Pools and Regions in Secure Access: 

• Navigate to Connect > Essentials > End User Connectivity. 

• Under the Virtual Private Network tab, add IP Pools for each user region to optimize connectivity. 

• Assign DNS servers and system IP pools ensuring no overlap with VPN IP pools. 

2. Create VPN Profiles: 

• In Secure Access, add VPN profiles under Connect > End User Connectivity > Virtual Private Network. 

• Configure profile settings such as display name, default domain, DNS servers, and assign IP pools. 

• Select VPN protocols (IKEv2, SSL) and enable posture profiles if needed. 

• Profiles define authentication methods, traffic steering, and posture enforcement for remote users. 

3. Deploy Profile to Cisco Secure Client: 

• Download the new Cisco Secure Client VPN profile XML from Connect > End User Connectivity. 

• Upload the new XML file to the Secure Client workstations using device management system 

• Multiple XML files can exist on the same workstation, giving user the ability to select a profile to connect to.  

Resource: Manage Virtual Private Networks 

Umbrella Core Identities and Policy Components 

Before configuring policies, we must first verify and resolve any additional settings that might be configured within the Umbrella dashboard. 

• Navigate to Umbrella dashboard and open Deployments and Policies 

• Move though each tab and verify there is no configuration 

• In case any of the tabs are configured, navigate to the same element in the Secure Access and configure it the same way. The table below indicates matching elements between Umbrella and Secure Access Dashboards. 

Umbrella API available: https://developer.cisco.com/docs/cloud-security/umbrella-api-reference-deployments-overview/#umbrella-api-deployments-endpoints 

Secure Access API available: https://developer.cisco.com/docs/cloud-security/secure-access-api-reference-deployments-overview/ 

 

Umbrella Dashboard	Secure Access Dashboard
Deployments > Networks	Resources > Registered Network
Deployments > Network Devices	Resources > Network Devices
Deployments > Roaming Computers	Connect > End User Connectivity > Internet Security
Deployments > Mobile devices	Connect > End User Connectivity > Internet Security
Deployments > Chromebook Users	Connect > End User Connectivity > Internet Security
Deployments > Network Tunnels	Will be covered below
Deployments > User and Group	Covered under Authentication section
Deployments > Domain Management	Connect > End User Connectivity > Internet Security
Deployments > Internal Networks	Resources > Internal Networks
Policy > IPS Signature Lists	Secure > IPS Profiles
Policy > Destination Lists	Resources > Internet and SaaS Resources
Policy > Content categories	Resources > Internet and SaaS Resources
Policy > Application Settings	Resources > Internet and SaaS Resources
Policy > Tenant Controls	Resources > Internet and SaaS Resources
Policy > Security Settings	Secure > Threat Categories
Policy > Block Page Appearance	Secure > Notification Pages
Policy> Selective Decryption List	Secure > Do Not Decrypt Lists

 

Policy and Connectivity Validation 

Please note policy evaluation and structure of policies in Secure Access is different when compared to Secure Connect. For example, Secure Access does not expose specific policy types like Secure Connect does today. Below are steps how to migrate each type of policy individually. Note that some policies could possibly be merged together and optimized, which will not be focus of this document. We will migrate policies as they are represented in Secure Connect. 

Since policies are executed top down, it is extremely important to maintain order of policy that will ensure no policy will be skipped. In organization with DNS, Firewall, Web, Zero Trust Policies we will need to make sure policies are ordered from top down as following: 

 

1. Zero Trust Access 

2. Deny DNS policies 

3. Deny Firewall policies 

4. Deny Web polices 

5. Allow policies 

6. Default policies 

  

This will match the policy execution path and no policy will be skipped causing unwanted results. 

Note that we did not migrate any DNS Allow policies nor Firewall allow policies. These are not needed as the next policy engine will do inspection. If Secure Connect has only DNS policy then all DNS policies should be migrated. 

Example:    Let's consider the following policies in Secure Connect: 

1. DNS Allow social media 

2. Web Block Facebook 

Those two policies will have the same effect as “Web Block Facebook”, therefore there is no need to include “DNS allow social media”, as it is redundant. 

 

Example Mapping Table: 

Secure Connect Policy Type	Example Secure Connect Rule	Secure Access Policy Equivalent
DNS	Block *.example.com in DNS Policies	Block *.example.com
Firewall	Allow TCP 443 from 10.0.0.0/8	Allow TCP 443 from 10.0.0.0/8
Web/SWG	Allow social media category in Web Policies	Allow ‘Social Media’

 

Umbrella API available:  https://api.umbrella.com/policies/v2 

Secure Access API available:  https://developer.cisco.com/docs/cloud-security/about-access-rule-attributes/#about-access-rule-attributes 

https://developer.cisco.com/docs/cloud-security/about-access-rule-settings/ 

 

1. Zero Trust Access Polices 

• Navigate to Secure Connect > Policies > Zero Trust Access 

• Navigate in Secure Access to Connect > End User Connectivity > Zero Trust Access and create Zero Trust Access Profile to match User Groups, Private Resources and Posture from the Secure Connect Zero Trust Access Policy 

• Configure each policy as Private Access Policy with matching users or groups access to the private resources or resource groups, with matching posture. 

Example: Secure Connect Zero Trust Access Policy: 

 

 

Secure Access Zero Trust Access Profile: 

 

Secure Access Zero Trust Access Policy: 

 

 

 

2. DNS Policy 

• Navigate to Secure Connect > Policies > DNS which will land you to DNS policies page 

• Open each policy and create matching Internet Security Profile and Internet Access Policy utilizing below table as a component guide  

• In the case of a DNS Policy that has both Block and Allow destination lists configured, two separate Secure Access Policies must be configured. 

• DNS policies that use Network Devices as an identity will have to be migrated at a later time. See “Onboarding to Secure Access” section. 

 

Umbrella DNS Policy	Secure Access Internet Security Profile	Secure Access Internet Access Policy
Identities Affected		From (Source)
Destination List Enforced		To (Destination)
Security Settings	Threat Categories
File Analysis	File Inspection
Content Settings		To (Destination)
Umbrella Block Page Applied	Notification Pages	Notification Pages
Application Settings		To (Destination)
Intelligent Proxy	N/A	N/A
SSL Decryption	Decryption
Allow-only Mode	N/A	N/A
Safe Search	SafeSearch
Logging		Logging

 

Example: Secure Connect DNS Policy: 

 

 

 

 

Secure Connect Destination List: 

 

Secure Access Threat Categories: 

 

Secure Access Destination List: 

 

Secure Access Security Profile: 

 

Secure Access Policy Rule: 

 

 

 

3. Firewall Policy 

• Navigate to Secure Connect > Policies > Cloud Firewall 

• Create matching Security Profile and Access Policy for all Private and Internet policies utilizing the table below as a component guide 

• There are two special identities in Secure Connect that require adjustments as they are not available in Secure Access: 

• Branch Access orgid: can be configured as ALL tunnels 

• Remote Access orgid: can be configured as ALL user IP ranges for ALL VPN profiles 

• Apply any required security inspection profiles such as IPS. 

Cloud Firewall Rule	Secure Access Security Profile	Secure Access Policy Rules
Sources		From (Source)
Destinations		To (Destination)
Schedule		Schedule
Logging		Logging

 

Example: Secure Connect Cloud Firewall Policy: 

 

Secure Access Network Objects: 

 

Secure Access Policy Rule: 

 

 

 

 

4. Web Policy 

• Navigate to Secure Connect > Policies > Web which will land to Web Policy page 

• Open each policy and create matching Internet Security Profile and Internet Access Policy utilizing below table as a component guide  

• Each Ruleset Rule will translate to single policy in Secure Access 

Umbrella Web Policy	Secure Access Internet Security Profile	Secure Access Internet Access Policy
Rule Identities		From (Source)
Rule Destinations		To (Destination)
Block and Warn Pages	Notification Pages
Schedule		Schedule
File Analysis	File Inspection
File Type Control	File Type Blocking
HTTPS Inspection	Decryption
Ruleset Logging		Logging
SafeSearch	SafeSearch
SAML	SSO Authentication
Security Settings	Threat Categories

 

Example: Secure Connect Web Policy: 

 

 

 

Secure Access Security Profile: 

 

Secure Access Policy Rule: 

 

 

 

Onboarding to Secure Access 

After all configurations are completed in the new Secure Access organization, we can move to the final migration step which does require scheduled downtime.   

• During your maintenance window:  

1. Verify and upgrade all your sites to 19+ firmware (Documentation) 

2. Disconnect All Sites from Secure Connect 

3. Remove Secure Connect from Meraki org (Requires support) 

4. Integrate Meraki org with Secure Access (Documentation) 

5. Enroll your sites and devices into Secure Access regions (Documentation) 

6. Move and reconfigure any 3rd Party IPSec tunnels to Secure Access (Documentation) 

7. DNS API integration 

• Create new Secure Access key for DNS API integration  

• Navigate to Meraki networks with DNS Integration and add new API keys 

• Add necessary DNS policies with Network Devices as source identity that were not migrated during DNS Policy configuration stage.