In our previous blog post introducing the BeyondCorp concept, we also discussed what organizations should think about when trying it for themselves. The steps may not happen in sequential order, but they are generally:
- Enrolling your users and their endpoints
- Marking trusted devices with certificates
- Setting up the access proxy and its policies
In this post, we’ll talk about enrolling users and their endpoints.
What Does Enrollment Involve?
Enrollment usually involves a combination of inventory, inspection and verification. You create a list of entities to be entered into the system that you’ll use to authenticate them and grant them access (in this case, a list of authorized users and a list of endpoints they’re using). You can use bulk enrollment — that is, you can use the list to create entries for each one without your users having to do anything — or you can use self-enrollment, where the users make contact and supply shared data so that you can recognize them.
Inventory: What corporate-owned or managed endpoints do you have, and who are the authorized users? What other endpoints are you going to allow?
Inspection: Does it conform with our security requirements? (Note: enrollment isn’t the only time you’ll inspect the endpoint; it should happen automatically with every access decision.)
Verification: Is this the known user who is presenting the endpoint for enrollment? Is this the same endpoint that we have in our inventory?
Start with what you know you have. Regardless of whether you pre-enroll the devices you know about or whether you let users enroll them individually, the process needs to have controls in place so that you have visibility over which assets you expect to see. Starting with a basic list of hardware tags (or phone numbers) and assigned users will let you recognize corporate systems as opposed to personal ones. For best coverage, plan to start with bulk enrollment, and then fill in the gaps with self-enrollment, because you’ll need to plan for ...
An important issue within the inventory process is discovery. Are you sure you know all your users and all their endpoints? How will you handle new or forgotten users? How will you deal with changes in endpoints? One way to handle this is to put discovery into the enrollment workflow, and place it where the users have to go in order to access something important. Make sure they will access it early and often. Everyone accesses an HR system sooner or later when they need to download their tax forms, but that will only be once a year; it’s better to place discovery in front of something they use all the time, such as email, reference wikis, or directories.
Don’t neglect discovery. Here at Duo, we have had customers who had policies against using personal devices on the corporate network, but they found out through our Device Insight that literally hundreds of users were doing it anyway.
The Power of Puzzle Pieces
What do you do about enrolling shared devices? Remember that it’s the combination of user and endpoint that you decide to trust, so you can’t just decide to trust all devices independently of the users; an attacker could take control of a given endpoint and leverage any other known username and password to get access. To avoid this, you need to enforce user-device pairs by adding multi-factor authentication.
In order to break in, the attacker would need to have the username, password, access to the second factor (such as the Duo application on a phone), and the endpoint — making it more difficult to get unauthorized access with every piece you add to the puzzle.
So make sure that you have an entry only for those combinations of user and device that you expect to see. Sharing may not happen that often, but when it’s needed, the enrollment process should accommodate it.
It would be great if the user’s endpoint were in a known clean state when it was enrolled, but this isn’t always possible. At the very least, you can decide on what hygiene and configuration settings you want to see: no known dangerous apps installed, encryption and lock screen turned on, and updated operating systems and plugins. If you already have an agent installed on the endpoint, you can get whatever data it provides you; if you don’t, or if this is the first time you’re seeing the device, Duo can perform a hygiene check without an agent.
As we discussed above, it’s the combination that earns the trust, so you need to make sure to authenticate the user during self-enrollment. From that time forward, the user will be re-authenticating (with more than one factor!) to the access proxy, along with that user’s assigned endpoint.
How do you uniquely identify an endpoint? It’s harder than it sounds, particularly when hardware components and their IDs get replaced. Google’s BeyondCorp paper describes how it used a combination of observed and prescribed data to do this. Organizations will probably end up using whatever data they can most easily obtain and match, for example from Active Directory or a management system such as JAMF; whatever you do, aim for consistency.
Google ended up deciding that it would be the certificate that was the arbiter of endpoint identity: if the certificate didn’t match what was enrolled, it didn’t matter whether any of the system components matched. Identifying devices through certificates is another key component of the BeyondCorp framework; we’ll talk about using them to mark your trusted endpoints in the next blog entry, “If You Liked It, You Should Have Put a Cert On It.”