The word “identity” has always made us think of a person’s identity. However, over the past 20 years the meaning of the term has evolved subtly. This evolution focused mainly 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. Out of excitement I gladly obliged. The issue of 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.
Historically (the pre-2000s), almost all applications, computers, and users were hosted inside a firm’s own networks. Access to a firm’s 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 pipe dream. 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 meant that the corporate network we once trusted so well was, well, increasingly not the network we were on. 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 of, 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 a 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, I 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.
This 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: 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 assessment 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 five 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 while leaving the other four active so the user remains productive.
We secured the certificates and enabled tamper detection. The result was that our devices had their own identity, tied to the user, but still independent.
The icing on the cake was a team we created focused on Security Intelligence. The key objective for this team was to create 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. 😉
About the Author: Den Jones is currently the Chief Security Office at Banyan Security. Den most recently served as Senior Director of Enterprise Security at Cisco, and prior to that as the Director of Enterprise Security at Adobe. Under his management, Den’s teams delivered proactive enterprise-wide security services as well as customer-facing Directory and Authentication platforms. Den is a well-respected member of the security industry community. He serves on the Customer Advisory Board for Identity Defined Security Alliance and is a member of Microsoft’s Cyber Security Council.
