Preparing for a BeyondCorp world: Understanding your device inventory
In my last post, I discussed the key first steps in moving to a system of trust based on people and devices, rather than one based on networks. We do this at Google, and it didn’t just spring up overnight, it took the work of many teams over many years. Today, I’ll go into more detail on what we did and why, with an eye toward how you can prepare your own company to move to a context-based access world.
Know your devices
First, you want to get an authoritative list of all the computers your employees are using. This is probably already contained in your existing management tools, whether Active Directory or others, and if you’re like us, it might actually be spread across multiple tools. You may have procurement or asset tracking systems that know about devices based on purchase and end-of-life cycles. Then, you have active management through centralized systems such as Active Directory. On top of that you might be using local tools to get data about current machine state, such as OS Query. Add to the mix your support and troubleshooting tools, network logs and access point records, and certificate authorities, and you could be looking at 10 or more sources of data about a single device.
Do they all agree? Probably not. Now the challenging part starts.
To infer trust from device state, you’ll need to have some confidence in your device data. Inevitable disagreements between these different systems will require you to establish policies about integrating, corroborating and resolving conflicts in the pipeline. Which specific fields matter most? Which are the most authoritative for you? What happens when you can’t get all the data you want?
Start with new devices
All of the data collection has to start somewhere, so identify your earliest process that can bring you complete and reliable data about devices, and go from there through the lifecycle. What’s the first thing that happens with a new machine? Where is it touched, which systems interact with it, and what will be tracked or reported earliest?
Next, you should consider what information matters most to you about these devices. This will be a process of setting policies with Security and IT teams, to settle on key items, possibly including:
Who bought it?
When did it last check in?
When was it last patched?
Is the screen lock or password set?
Is the disk encrypted?
What’s installed on it?
Do you still have it (e.g., not stolen or lost)?
Once you have a short list of key data, and you understand where it comes from, you can figure out your process to handle data problems. Human errors, reporting gaps, or even third-party shenanigans with MAC address or serial number re-use can cause inconsistencies or conflicts, and you’ll need clear policies to handle them.
All of this will likely require change at various parts of your organization, from teams to process, so you’ll want to roll out gradually. Figure out what works and what doesn’t, and put in place ways to debug when data are wrong or trust decisions are made incorrectly.
If it feels like a lot of work, start small, getting your systems with the most device coverage. Whip them into shape, so that they give you reliable and accurate information, and then look for integration points with other systems so you can start corroborating information and basing the master data on more than one source. With a clear picture of your fleet, you can start to make access and authorization decisions with more confidence, and shift to access anywhere, based on context.
