Zero Trust - Device Security
“Do you read me, HAL?”
In my previous article on Zero Trust for Applications, I concluded with how we need to focus on ZT approach for code compile/build and for application execution. Next, let’s take a look at the workloads/devices on which these applications run. The movie quote from this article is taken in reference to HAL 9000 , an AI that goes rogue in “2001: A Space Odyssey”. Rogues AIs are an interesting question, but the implication from the movie remains the same for a rogues device on the corporate network. How do you trust a device that has broad access and control on your corporate network. The answer is… you don’t.
The ZT approach for devices could be summed up by asking:
- How do we classify the device as a “known” / “unknown” asset?
- How do we determine if the device meets the required security posture to access protected data?
- How do we implement least access for the device? — Although, this question may be better answered by with “ZT for Network Access”.
- How do we contain the device in the event of breach detection?
“Device” and “Workloads” are interchangeable for this topic and refer to servers, endpoints, IoT devices or any device that can run an application and access data. Answering the questions above can lead us to the technology solution that applies the ZT architecture to devices. Fortunately, vendor solutions have made it much easier to answer these questions without building such capability in-house from scratch.
“Known” Assets and Device Authentication
A known device can be classified as a device that’s has been identified and catalogued by corporate IT. This can be either through a device management solution or by installing a device X.509 certificate on an unmanaged device (this link provides a good overview of what that may look like ). The latter case comes into play when the device does not run a supported OS on which a device management platform can be installed. If all else fails, it is possible to identify a device based on it’s MAC address , though this is far from a secure option and is easily spoofed .
The goal is to have a way to authenticate the devices that are expected to be connected to the network or devices that are expected to access data even when offline. This gives the ability to then limit access of “unknown” devices that don’t meet the criteria used for known devices.
It is important to note that “authenticated” devices does not equate to “trusted” devices. All devices are untrusted in the initial state, whether they be managed known devices or whether they be unknown devices. This state is useful for blocking or treating unknown devices with a different set of rules that can be broadly applied at any layer of your defense-in-depth strategy.
Device Security Posture
Too bad that in “2001: A Space Odyssey”, the astronauts didn’t have a separate system to verify that HAL had gone rogue even though it was indicated by the disparity in results from the twin-HAL on earth. An external agent always helps validate a system’s integrity,
Most modern Device Management platforms now enable a near real-time security and compliance check on a managed device via agents (Microsoft Defender ATP does one better and and instead of agents uses telemetry built into the Windows OS ). Thus it is possible to take policy decision on whether to allow device access to the network or data at the time of access. Common decision criteria for device posture check are
- Is AV running?
- Is AV definition up-to-date?
- Is Firewall enabled?
- Is OS patched?
- Does device have corporate machine certificate installed or is machine domain joined?
- What was the last checkin date to the MDM platform for the device?
For unmanaged, or BYOD scenarios where installing an agent is not possible, modern browsers can provide information like CPU architecture, Device Type and Browser engine version. Many banks and financial institutions are already enforcing controls when they detect outdated browsers to protect their customers. Organizations can enable similar checks to block browsers that would not meet their required compliance standards. Eg: If the organization does not use Apple devices, then web app access can be blocked for all Apple devices.
A device that passes the required checks can then be considered trusted and policies for access can be applied to that device.
Device containment
A key capability required for effective Zero Trust control is continuous monitoring. The intent is to detect a change in the device’s state of trust. Thus, if a device that passed all previous checks and is now connected to a protected resource has an event that causes the security posture to be weakened or broken, the continuous monitoring should trigger a containment action and mark the device as untrusted.
For example, a malicious actor may be able to use compromised credentials on a corporate device to validate and logon to the corporate network. However, to initiate any malicious activity, it is often required to disable the device’s security features. Such as to disable AV real-time protection to run scripts like Mimkatz that are detected and blocked by most antivirus programs. A network access agent on the device can immediately cut off connectivity when such an event is detected (assuming its the AV + EDR capability that was bypassed).
Another aspect that is derived from applying zero trust to the access governance is that when the inevitable compromise occurs, the “blast radius” of the breach is contained. This means that since the compromised device only had access to certain protected resources and not a broad swathe of the network. The device containment can lock this down further, while enabling access to security tools like EDR (Endpoint Detection and Response) and NAC (Network Access Control) which enable SOC teams to investigate and take further actions.
In conclusion, the ZT approach to device security, the following aspects are required
- Every device needs to be treated as untrusted initially before it clears the required checks
- wherever possible, device authentication should be leveraged to identify devices that are considered managed or “known” by the corporate
- Unmanaged devices should have additional controls / restrictions to protect the network and data
- Continuous monitoring of the security posture of a device must be implemented to ensure quick response and containment in the even of breach
Recommended Reading:
https://cloud.google.com/blog/topics/developers-practitioners/devices-and-zero-trust https://www.kuppingercole.com/blog/singh/device-authentication-and-idot-for-iot https://docs.microsoft.com/en-us/azure/active-directory/devices/overview