Secure your devices, and theirs: BYOD and device management
To make good decisions about access, you need to gather data about all the devices your employees will use.
In my last post we explored shifting from perimeter security to context-aware security, and now we’ll dig into the device aspect of that context. There are many approaches to securing devices (including completely ignoring device security… yikes), with many companies choosing some variant of bring-your-own-device (BYOD) policies.
These policies allow companies to reduce their spending on hardware for employees, and can offer flexibility for folks to use the computers or tablets that they prefer. But the challenge of securing your corporate data and applications requires a shift in how you think about trust, and measurement.
How healthy are those devices?
For all the convenience of BYOD, the big open question remains: how do you know these devices are safe? Many probably have malware, unpatched operating systems, backdoors or custom Minecraft mods. And now they are looking at your corporate data. Yikes!
The care and safety of these devices is solely up to their owners.
That might work out for your savviest employees, but the rest of the company doesn’t know how to maintain a secure device. Maybe not the best place to put your trust, as you admit these devices to your network and your applications. When your employees use a laptop to access the internal customer relations tools, or codebase, you probably have some hijackers along for the ride, gathering keystrokes or screenshots every step of the way. Might be for fun, might be for profit; doesn’t matter, we need to stop them.
BYOD on its own isn’t enough.
You need a way to check on the health of the devices.
Virtual devices
Many companies meet this challenge by deploying extensive virtual desktop infrastructure (VDI) and then force all connections through a VPN. While this feels safer, it’s really creating extra bottlenecks while still leaving major paths for attackers to still get what they want. When a compromised computer connects to the virtual desktop the connection may be secure and yet still allow critical data to be viewed by a malicious screen reader or remote control exploit.
If we can’t trust the device that your employee is coming from, we can’t trust their connection at all. So we have to base trust on the answers to these two foundations:
Trust in the person and trust in the device.
Trust in the person comes from proper authentication, preferably with a phishing-resistant second factor. I’ll cover that in a later post. But what about the device? You must observe and then enforce, so start by gathering the data
Device observation
The Security team at Slager Bank & Trust demanded a better solution, knowing that BYOD wouldn’t work by itself. So the IT team turned to Google, and started learning about Google’s Endpoint Verification service. Now, through either a Chrome extension or native app installed on each BYOD device, the Slager platform management team can gather data and check on the state of employee devices, using that information to make good decisions about access and permissions.
Once you turn on Endpoint Verification for your domain (start at admin.google.com, go to Device Management then Setup then Endpoint Sync), you can start collecting information about Chrome OS, macOS and Windows devices, showing you information about:
- Compliance with device management policy
- Username and email
- Sync status
- Password status
- Encryption status
- Device ID, Serial, Type, OS and more
This gives the Security and IT teams the information about the devices, the first key step. Next they use Access Context Manager to craft policies around what criteria are needed to access each of the applications or resources they run in GCP. Getting each device, whether BYOD or company-issued, set up with Endpoint Verification meant the Slager IT and Security teams now have visibility into device state.
That visibility lets them enforce access based on their device security policies. They’ve got a full list of devices, and they focus their security efforts on OS version and encryption status, to minimize the risk of data loss. Let’s look at a few of the policies they made, and why.
Access policies and conditions
With knowledge about the devices, and some long conversations about what the ideal access policies are (including the Legal & Compliance teams, along with other leadership) the Slager IT team can craft their policies and restrictions. They want to start with a simple test, so they begin with restricting access to their customer ticketing system to only Chrome OS devices with an up-to-date operating system:
- devicePolicy:
osConstraints:
- osType: DESKTOP_CHROME_OS
minimumVersion: 70.0.3538The policies can easily be more complex and nuanced, utilizing IP ranges, URLs, and more. In the future they plan to use these conditions to control access to specific projects, classes of resources (e.g. storage) or specific types of cloud assets (e.g. compute instances). If you don’t meet the criteria for access, you get one of these:
Putting it all together
Once they got their policies set up, and their employees’ devices all reporting in to Endpoint Verification, the Slager Bank & Trust team flipped the switch and began testing more broadly. To expand usage, they decided to limit access to their case management tools next, requiring Chrome OS devices with up-to-date versions of the OS. Success is invisible to their employees, the application just works (in this case just showing Hello, World).
This helps them prevent a dangerous potential loss of customer data to a compromised Windows laptop. Now that they’re protected from OS vulnerabilities they can shift to focus on keeping their operations and applications secure. But that’s a topic for another post.
You can take these tools for a spin today, by installing the Endpoint Verification client and then creating some access levels of your own.
