I went on a journey to figure out features and workflows that I’ve never done before, or that were hard to do. This is one that I worked on to help understand how the various features are used for Secure Access’ mobile device capabilities. Especially on the Zero Trust Access (ZTA) side of things, where you can access private applications without the legacy Remote Access VPN (RAVPN) technology. Up until this point, I’ve worked with the platform only from a clientless or client-based approach using a laptop or a virtual machine. Needless to say, we are getting more and more mobile at work and we need to start considering ZTA from the mobile devices as well.

The components that I used were:

• Meraki Systems Manager
  • For mobile device management, configuration and application compliance
• Cisco Secure Access
  • For data center connectivity, policy enforcement, and compliance checks
• Old iPhone
  • Wifi-only
  • Using Cisco Security Connector App and Cisco Zero Trust Access App

Prior to setting this up, the user and resource access integrations and policies were already configured. This typically occurs during the initial configuration workflow or during ongoing operations as additional private resources are being added.

Mobile Device Management

Using Meraki SM, I have my iPhone registered with Meraki and being managed by it, as shown here.

Creating application lists and configurations in Meraki SM, I have the Cisco Security Connector and the Cisco Zero Trust Access applications. The Cisco Security Connector provides the Umbrella type functionality, servicing our DNS and web requests and redirecting them to Secure Access for inspection. From this perspective, Umbrella and Secure Access have similar functionality, with Secure Access having a more robust inspection capability.

The Zero Trust Access application brokers our private resource connections and allows us to use the ZTA access capabilities that come with Secure Access. This enables really cool capabilities and functionality for our mobile devices to be able to connect to the private apps wherever the device is.

Speaking of the Zero Trust Access app, let’s check out the configs! This is pretty simple, as a lot of the policy configurations will be added after enrollment inside of the application.

And for the Cisco Security Connector…connectivity to the Internet! This is what’s going to be able to give us the Umbrella-type features, like DNS filtering and web security protections.

Cisco Clarity is part of the content filtering as well, but from Cisco Secure Endpoint. This is the application that’s used to provide the EDR capabilities on the iOS devices.

So that’s it’ from an MDM perspective. My iPhone is enrolled, and the applications were pushed to it.

Enrolling Mobile Devices

Hey look, I’m enrolled! I didn’t show that workflow, but once the apps were pushed I opened it. Then I clicked on the “enroll” button, and it redirected to my Cisco Duo tenant. This is what I have set for my enrollment IdP in Secure Access. So my user credentials were used to login, and I was enrolled in the platform.

Testing and Validation

As you can see here, after enrollment, my configurations and policies synced to the app. You’re able to manually sync and unenroll if needed.

Let’s take a look at this from the Cisco Secure Access side of things. This is where the DNS/Web/VPN/ZTNA profiles will come from, and we’ll configure everything from our access policies to our users inside of there.

Cisco Secure Access

After enrolling my device into the platform, I can see it under the Roaming Devices menu. We can customize the iOS notification settings, but as you can see, we can identify relevant profiling information in this view.

What’s really cool about this, is that we can create posture profiles for device compliance. These can be used for ensuring that certain levels of security are configured on the devices prior to connecting to a resource. We create a posture profile, configure the various posture checks, then tie the profile to an access control rule. In this posture profile, I’m only allowing iOS 18 to access my resources.

Now inside of the actual access control rule for the access, we have our actions, identities for the rule, and the various requirements. The requirements are where we tie in the security and posture profiles that we would like the endpoint to use when connecting to the resources. In the destinations, I have a private resource group with my web server configured as a web resource that is able to be connected to in a certain way.

Seeing the Private Resource Access

As you can see, in the example use case, we can connect to the private resource from anywhere. What’s cool about this is that I can use an internal FQDN because of the Zero Trust Module that’s on the device. So from anywhere with an internet connection, I can access my private resources in the datacenter. The address webserver1.phoenixlab.dev isn’t publicly resolvable, it’s internal-only. And, it uses micro-segmentation! This is possible through QUIC and MASQUE…topics for another day.

What other topics do you want to see with regards to Secure Access? Let me know in the comments!