Endpoint security is a pain, because doing it well is difficult. It’s desperately tempting to come up with a strategy that focuses on backend security and just accepts that endpoints might be compromised. But as I’ve said before, the problem is that anything the legitimate user of an endpoint can do, so can an attacker who’s compromised that endpoint.
Indeed, the UK National Cyber Security Centre’s recent advice on BYOD includes the words: “You cannot do all your organisation’s functions securely with just BYOD, no matter how well your solution may be configured. If you’ve given BYOD users admin access to company resources, revoke that access immediately, then come back.”
The reality though is that BYOD is convenient and endpoint security is difficult. What’s to be done?
Well, good technologies (like robust web isolation!) are required to deliver good endpoint security. But we should be realistic that not all endpoints need, or will have, the same level of security. Some users need local admin rights, the ability to set up ad-hoc VMs, or install experimental software. What’s critical – as per the NCSC’s guidance – is that these lower-security endpoints don’t have access to the most sensitive systems and data.
In today’s cloud-centric world, that’s actually really hard to achieve because many of the SaaS services we all rely on simply don’t incorporate the concept of endpoint security. What we want is that user joe.bloggs@example.com has privileges X within the SaaS service if they access from their secured, managed corporate device – but lower privileges Y if they access from a lower-security device (for example, a BYOD one). What do we end up doing to try and achieve this?
If you run a traditional corporate network with VPN access, then one option that’s supported by some cloud services is IP locking – allowing access to the service only from the “corporate” IP address. Then we can use on-premises tools to ensure that only secured, managed devices are able to connect to the corporate network and thus appear on that IP address.
But not everybody has a traditional corporate network, and not every cloud service supports IP locking. Our next alternative is then to give Joe Bloggs multiple different identities, so that IDAM will only authenticate joe.bloggs@example.com from a secured, managed device but will authenticate joe.bloggs@less-secure.example.com from a less secure device (practically speaking, this would probably be a different domain with different device policies). That sort of works but can cause all manner of follow-on problems: the fundamental idea of a user identity is that it’s supposed to identify a user – and ensuring a consistent set of policies for a single user across multiple different user identities can be hard. Not to mention the pain we can cause those users if we require them to log on multiple times with different identities.
What I’d like to see is an extension of standards such as SAML and OAuth to include some standardised representation of verified device security level alongside verified user identity. Or they could include some representation of verified device identity, with information about device security level being retrievable from this, perhaps using an extension to SCIM. With that in place, we could start asking our SaaS providers to use that information as part of their privilege management. Perhaps we could call it REBAC – Role and Endpoint Based Access Control.
Am I reinventing the wheel here? Is anyone else looking at this?