TL;DR
So, the quick summary and main points:
- Users, devices, and applications no longer exist solely on your corporate network
- Remote working now means that public networks are part of your ecosystem
- Attacks these days are resulting from your corporate network security being bypassed
- Access is provided to your data even though you knew little about the device posture
What we explain in this article is how important a device identity is, why we need posture check, risk or trust scores. Then how this can improve user experience as well as our security posture.
Introduction
The word “identity” has always made us think of a person’s identity; however over the past 20 years there’s been subtle evolution. Mainly the evolution focused on the shift from a human identity to privileged identities and then to generic accounts and application-based accounts. But the last five years or so have seen the rise of device-based identities; especially with the IoT (Internet of Things) explosion. Even my fridge wanted its own Twitter account, and that was in 2014. Which, out of excitement I gladly obliged. The issue is securing the sprawling identity explosion is both a personal and corporate nightmare. For the purpose of this discussion we’ll focus on corporate computers used by employees to do their job.
Problem
Historically (the pre-2000s) almost all applications, computers, and users were hosted inside our networks. Access to our LANs and WANs was very rare and in the early days access to the internet was also rare. A 56k modem was blazing fast and voice over IP was a pipedream. Anyway, I digress…
By the year 2016 we had evolved to the point where more people were working remotely and accessing applications in the cloud. This means that the corporate network we once trusted so well was, well, we were increasingly not on it. So while we knew who the user was that logged into the application we had no idea if they were on a network we had visibility, control over, or trust in.
So, we’re now at the point where the only real security check being performed is to verify that the user presents valid credentials. We can of course layer on Multi-Factor Authentication (MFA) and more advanced user authentication, but the fundamental issue remains: humans are the weakest link in any security chain. How do we add a layer of security in a world where VPNs and other network tools do not adequately protect our data or users?
So, What should we do? Enter … Device Identity
While leading Enterprise Security in a previous role responsible for delivering our zero trust strategy, we followed a line of thinking that said we needed more than just user identities – we also needed device identities.
Of course, this really becomes a discussion about risk posture and trust scoring. We even debated which term was the right one to use. I think in the end we used both, as in:
- Trust score: based on the posture/configuration and what security tooling is on the device we award a trust score. Which starts simple, but improves with each satisfied condition:
- Up To date OS?
- OS patched?
- IT Managed (MDM/UEM)?
- Endpoint security software installed (malware protection)?
- DLP software present?
- Some other magic?
- Risk posture: Would be a combination of the user’s behavior, the device posture, and the sensitivity of the application or resource being accessed.
Of course these terms are not as important as the outcome – we simply wanted to ensure that it was a combination of the user, device, and application.
With this in place and a good zero trust platform you have the ability to deny access to applications if the device’s posture doesn’t meet your requirements. It was easy to create policies that took into account user, device, and applications.
In our implementation at a previous company, we also included a device certificate which would include the user’s identity. This would mean that if a user had 5 devices there were five unique certificates; each tied to the user ID and respective device. This enables revocation of a single certificate if one of the devices is compromised; but leaving the other four active so the user remains productive.
We secured the certificates and enabled tamper detection. The result being our devices had their own identity, tied to the user, but still independent.
The icing on the cake was we created a team focused on Security Intelligence. The objective being that they created a UEBA platform to ingest data related to authentication, users, devices, applications and some other magic to ensure we knew when a user or device was misbehaving.
We also formalized application identities, leveraging service accounts and short-lived credentials, for inter-service communications. Now, applications could communicate with each other without needing to be on the same trusted network; they could authenticate and authorize just as human users did.
Looking back, I think we enjoyed a few well-iced cakes. The other was enabling users to see their devices via a portal, details related to their authentications and what their scores were and how to improve them. The team even rolled this up to the CEO level with execs being able to see the scores of their peers – funny how no-one wants to be bottom of that table 😉 “let the games begin.”
Benefits?
At the end of the day, saying you actually delivered some zero trust doesn’t matter. Unless as a leader you demonstrate some business benefits, frankly no one cares. So, combining the device identity, using certificates, and delivering security intelligence, enabled:
- No more need for passwords during the authentication process
- No more changing passwords every 90 days
- Far fewer (orders of magnitude) help desk tickets related to passwords
- Being able to enforce access based on device trust score and UEBA
- Knowing more about all devices that access your data
- Revoking access to a single device during compromise without killing the user’s productivity
I guess I could have added accessing applications without the need for VPN, but wasn’t six wins already enough?
The hard part here is people often want to lump everything into “Zero Trust” program wins; which we often did. For example, we removed the need to change passwords every 90 days; which isn’t really a zero trust play. However, as a result of not using passwords due to our zero trust work we could then argue zero trust was a huge enabler. Your mileage may vary. It usually comes down to how you’re funding the work, setting the expectations, who the primary beneficiary is, and how you’re explaining the results and benefits.
Conclusion
From a business perspective if you don’t know what’s on your network, then you absolutely need to know about the users, devices, and applications they are connecting to.
From a personal perspective I realized I didn’t care about reading Twitter from my fridge, a realization that came to me during my visit to the IoT village at DefCon. 😉
