Thank you for joining us today.
My name is Jacob Davidson,
and I'm the lead engineer for Mac
at Cisco.
My name is Lila Blum,
and I'm the zero trust application
and adoption lead.
Today, we're gonna share with you
some details of Cisco's
enterprise implementation of zero trust
and how we used Jamf Pro in our rollout.
Zero trust is a security framework
built around the concepts
of never trust implicitly, always verify,
and assuming breach both from inside
and outside the network.
Zero trust is a newer concept
in the security industry,
and companies are interpreting
and implementing it in different ways.
Some are leaning heavily
into network micro segmentation
or even adding more encryption.
However, Cisco's zero trust
for the workforce program
focused on more granular controls
both at the user device
and at the application.
As a leader in the security field,
Cisco endeavors to provide
innovative security strategies
and technologies for our clients.
Those strategies are piloted
within our organization
so we can work out the kinks in the system
and drink our own champagne.
By that, I mean we advise our clients
to adopt these strategies
and technologies that we produce,
so we want to adopt the same technology
internally to really understand
the benefits and drawbacks
as well as be able to provide
best practices to our clients
for their own implementations.
With the zero trust architecture
we've deployed at Cisco,
we've added more layers
to our security defense in-depth methods
by moving to a per app
authentication strategy.
We've paired these increased
security measures
with an additional borderless access
authentication route
for zero trust secured applications.
By borderless, I mean without VPN.
So that in turn allows our workforce
to work not only securely,
but also more conveniently
when they're remote.
Let's talk more about the technology
we deployed to make this happen.
When the user tries to access
an application
via the zero trust authentication flow,
the controls we've put in place
check the trust level of the user
and the device.
Yes, I did just say trust.
Remember, zero trust is not about
never trusting any users or devices,
but rather never trusting them implicitly.
By implementing several layers
of controls,
we establish explicit trust in only
the users and devices we deem secure.
We've implemented the following controls
to achieve that objective.
Password-less primary authentication
via Single Sign-on.
Two certificates that attest
to the user identity
and device management status.
That user identity certificate enables
the password-less primary authentication,
which has been one of the benefits
of our zero trust architecture.
And we also automatically fall back
to typed credentials
if, for any reason, that certificate
isn't working correctly.
The next control we invoke is the device
posture assessment using our application
called Duo Device Health.
This application verifies several elements
of device posture and reports them
to a Duo--a cloud-based policy engine,
which then reports the posture status
to the authentication prompt,
where a healthy report
allows the offload to continue
and an unhealthy report results
in a denial of entry.
Finally, the user
re-verifies their identity
using Duo multi-factor authentication.
If an authentication request
passes all these gates,
the user is allowed borderless access
to the application.
You can imagine how popular
borderless access has been since employees
started largely working from home.
Thanks for that explanation, Lila.
Now I'm gonna show you
what zero trust experience looks like
when I search for my profile
in our internal search tool.
As you watch, take note that my laptop
is connected to personal Wi-Fi,
VPN is off, and notice
that I am not prompted
for a username and password
because of the user identity certificate.
Let's see it in action.
First, the user identity certificate
is accepted.
Next, I approve
the MFA challenge offscreen.
Then the device certificate
is accepted by Duo.
Finally, Duo Device Health
checks the device security posture,
looking for an updated OS,
a system password running anti-malware,
enabled disc encryption,
and enabled device firewall.
And now I've been granted access
to the site without entering
user credentials or connecting to VPN.
To better visualize
what we're talking about here,
take a look at this architectural design.
Using management software represented
in the leftmost column,
we've deployed the certificates
and other components
we've mentioned so far.
We'll deep dive into those components
in later slides.
We've used SCCM
and, later, Microsoft Intune
to deploy configurations
to the Windows fleet.
We use Cisco Meraki systems manager
to deliver configurations
to mobile endpoints.
And, of course, we use Jamf Pro
for our Mac fleet.
Then in the next column to the right,
you see the off-premise endpoint,
meaning it's not connected
to the corporate VPN.
It's on your home Wi-Fi
or at Starbucks or on the airport Wi-Fi.
The authentication request
is initiated at this off-premise endpoint.
When the off-premise endpoint
tries to access an on-premise application
internal to the corporate firewall,
the request first hits the Duo
network gateway, a reverse proxy
hosted in the Cisco network DMZ.
The Duo network gateway
triggers the Duo Device Health app
to check device posture
against the controls
set in the Duo policy cloud
and then forwards that request
through the corporate firewall
to the application being requested.
The application single sign-on policy
checks whether a session cookie is present
and, if not, then sends the request on
to our identity provider
to complete primary authentication,
either via the password-less
user certificate
or via form authentication
with credential input.
Finally, the request is pushed
to the Duo API,
which invokes the second factor
of authentication.
After the MFA challenge is approved,
the device can connect to the application.
It sounds like a lot of steps,
but as you just saw in Jacob's demo,
this is all pretty quick.
Just a quick glance here,
but you can see that the Duo network
gateway is not used for borderless access
to our cloud-hosted applications.
Though the Duo network gateway invokes
the control policies
for an on-premise internal application,
we instead invoke those policies
at the identity provider
for all other application infrastructures.
I'm gonna hand it over to Jacob now
to talk more about what we achieved
with Jamf Pro specifically.
You've seen what it looks like
for a user
and how the architecture is designed,
but what does it take on the device
to achieve the secure
zero trust experience?
We've broken it down
into three main pillars
of managed components on the devices.
First is enforcing security posture
using Jamf Pro
to configure the following items.
Device password.
We use Enterprise Connect
and the Kerberos SSO extension
to synchronize user passwords
with Active Directory.
This is managed via configuration profile.
We also developed a set of services
around Enterprise Connect
and then Kerberos SSO extension
to ensure password policy
on managed devices.
Cisco Secure Endpoint,
formerly Cisco AMP for endpoints
is our anti-malware solution.
Secure Endpoint has its own
management cloud,
but the installation is enforced
with Jamf Pro,
which I'll share more details
about in the next slide.
FileVault encryption.
Enablement and recovery key escrow
are enforced by and to Jamf Pro.
We only use personal recovery keys,
and we developed a service
to watch for machines
that have been booted with recovery key
in order to enforce single use
recovery keys.
Device firewall enabled.
Enable and settings are enforced
via Jamf Pro.
We don't set extensive rules,
nor do we stop users
from setting their own.
We just want to ensure it is enabled.
Second are the Duo components
that are delivered via Jamf Pro.
Duo Device Health verifies then attests
to device posture during authentication.
Duo Trusted Endpoint Keychain houses
the Duo trusted endpoints certificate.
Duo Certifier
assists with identification
and reporting of the Duo trusted
endpoint certificate in the browsers.
Lastly, the user identity certificate.
This enables password-less authentication.
We'll now take some time
to begin looking more closely
at some of these components
starting with our deployment of Cisco
Secure Endpoint,
our anti-malware solution.
The Secure Endpoint installer
is generated from the cloud console
as a PKG inside of a disc image.
And while it would be easy enough
to upload this into Jamf Pro
for every version we want to deploy,
that is not what we do as that would
be time-consuming and repetitive.
Instead, our enforcement script
is supplied via installer URL
as a script parameter in Jamf Pro,
allowing us to use
the same script for multiple
Secure Endpoint versions and policies.
The same enforcement script checks
to make sure not only
that Secure Endpoint is installed,
but also that its services
are running properly.
If they are not,
it will trigger a reinstallation,
ensuring devices stay secure.
As with many other security products
for MacOS,
Secure Endpoint needs full disc access,
which is provided by a privacy preferences
policy control profile via Jamf Pro.
We also configure the system extension
and content filter
that Secure Endpoint use
with Jamf Pro configuration profiles,
suppressing all approval dialogues,
allowing for a solid installation.
Next, let's explore the Duo components
installed on our managed endpoints
by Jamf Pro.
Similar to the installation strategy
for Cisco Secure Endpoint,
we use a scripted install
for Duo Device Health.
Because Duo publish a static URL
that always provides the latest version
of their installer,
we can use a script to download
this installer just in time
and then install on the device.
This saves packaging maintenance
and ensures devices always start
with the latest version of the software.
The Duo Trusted Endpoint Keychain
houses the Duo trusted
endpoint certificate
and is managed by a script
provided by Duo as part of the product.
This script runs as part of a policy
in Jamf Pro.
Since our initial rollout internally,
Duo now offer a Jamf API-based integration
that removes the need
to deploy the certificate.
We have the solution
and testing internally,
and we will be moving to it
in the near future.
As mentioned previously, Duo Certifier
assists with the identification
and reporting of the Duo trusted
endpoints certificate and the browsers.
It is installed by a script,
functionally identical
to how we install Duo Device Health.
Now let's look at what makes up
the user identity certificate
used for password-less authentication.
We use a skep configuration profile
from Jamf Pro to deliver
a certificate to managed devices.
The certificate contains
the hardware UUID of the device,
added via Jamf Variable,
tying the certificate
to the device for validation.
The same account name of the user,
added via Jamf
extension attribute variable.
This is what ties the certificate
to the user.
And the identity preference.
This tells Safari to use the certificate
when the IdP requests one
so the user is not prompted to select one.
It wasn't all perfect, though.
I wanted to touch
on some of the device challenges
we've run into during this rollout.
We use Jamf Pro
to deliver the user identity
certificate to the user channel.
However, if the device
is enrolled into Jamf Pro
without an MDM-capable user,
Jamf cannot deliver the certificate.
Prior to Apple's rollout
of user-approved MDM,
we could have used Jamf Pro
to silently refresh the MDM profile
and create an MDM-capable user
if one were missing.
However, between that change
and big source additional changes
around MDM profile refresh,
we found the only real solution
to this problem was for a device
to be re-enrolled into Jamf Pro.
As noted in some of the other slides,
a device is required to have
Cisco Secure Endpoint installed
to pass zero trust posture checks.
Cisco Secure Endpoint relies on system
extension and privacy preferences
policy control profiles
delivered via Jamf Pro
to function properly.
In turn, those profiles require the MDM
on the device to be a user-approved
MDM state.
To tackle both issues, our data solution
and insights teams
have been able to leverage
the Jamf API to generate dashboards
while our project management
and communications teams
use our WebEx platform to specifically
communicate remediation instructions
to those users for their affected devices.
At the beginning of the rollout,
roughly 17% of our enterprise fleet
was in a fault state
with Cisco Secure Endpoint.
Using enforcement and awareness campaigns,
we've reduced that number to 4%.
Meanwhile, we also reduced
the number of machines
missing an MDM-capable user by 70%.
Let's look at some more statistics
to give you a better idea
of the scale of what we achieved
and how quickly we delivered it.
In four months, July to November, 2020,
we delivered and tested a proof of concept
of our architecture
and the Duo network gateway infrastructure
in dev, stage, and production life cycles.
We convinced ten major application teams,
including the highest traffic
internal platform at Cisco,
that zero trust was secure and convenient
for their end users,
and then we onboarded their applications
to the architecture.
By January of this year,
we rolled out the configurations
Jacob detailed to 140,000 employees
using 170,000 managed devices.
And we onboarded
another five applications.
As of this recording,
in terms of adoption,
we have 94 applications
using the zero trust architecture
generating 2.6 million device
health checks per month.
Finally, out of all of those users
accessing our applications borderlessly,
less than 1% have contacted the help desk
for zero trust-related issues.
When you consider the scale
of what we achieved
and our speed of delivery,
zero trust on an enterprise scale
sounds fanciful,
but let's look at what made
the program execution successful.
First, we had strong support
from our executives.
Our management were able to tell
the story and communicate
the potential of zero trust
for the workforce in a way
that made executives want more executed
and delivered very quickly.
So a lot of potential obstacles
were avoided.
This is a lesson that a program
needs servant leader managers
dedicated to crushing roadblocks
and selling the story to leadership
in order to be successful.
Because of the timelines leaders
asked us to meet,
the zero trust program team
had to set very specific priorities
and deliver on those
even if the implementation wasn't perfect.
So for some components of our delivery,
we had to give a minimum viable product
and then iterate towards perfection
in additional sprints.
The lesson here is, perfection is nice,
but execution is a must.
We did multiple rounds of analysis
at different phases
to determine which applications to onboard
to zero trust as strategic priorities.
We had VPN logs and IdP logs to determine
the highest traffic applications
and go for a breadth approach.
But we also asked multiple business groups
for their help getting us data to enact
a vertical or persona-based strategy
in which we could enable every application
one set of people tends to use
on most days.
Both strategies have their benefits
and drawbacks,
but if we had been able to use
a more automated technical strategy
using whatever DNS callers are out there,
we could have had even faster success
with onboarding and adoption.
The lesson here is to find
and execute a strategy
that works best for your organization.
On fleet health, it's a common problem
at large organizations that devices
aren't always in perfect health.
And unfortunately, device posture
sometimes relies
on governing user behavior.
That's not the case anymore
with zero trust.
You either have a secure device
or you don't get access.
Of course,
during the general access rollout,
that meant that we had a few
unhappy people who had previously made
some one-off changes to their devices.
We learned from this issue
that next time we'd do well to look
at the device requirements ahead of time
and start acting on them in conjunction
with the endpoint groups very early on
instead of waiting until people
are blocked from accessing
some applications or features.
Changing circumstances during our
execution also created some difficulty.
In a large organization,
you often deal with things
like changing policies, org restructuring,
and competing priorities
on cross-functional teams.
So in order to deliver on our commitment,
we had to be flexible enough
that we could change our expectations,
change our strategies, and still deliver.
The message here is flexibility.
The landscape of employee
access requirements has and will continue
to change, requiring us
as organizations to keep up.
While we want to deliver
convenient access to employees,
we must manage the accompanying risks.
With zero trust, you can achieve
both competing objectives.
Zero trust is the secure solution
to the ever-changing landscape
of remote work.
Thank you.