Zero Trust incorporates many security principles, and assessing device trust by using device identity and posture is one of them. So how is this done and what are some of the frameworks to keep in mind?
While the concepts of device identity and device posture assessments have been around for many years, it really started to become top-of-mind with Gartner’s Continuous Adaptive Risk and Trust Assessment (CARTA) framework. Gartner also published a document named “Zero Trust Is an Initial Step on the Roadmap to CARTA” to further message that user and device behavior should be continuously monitored for abnormal activity to ensure that trust and authorization go hand in hand.
The OpenID Foundation and the Identity Defined Security Alliance (IDSA) have been working together to develop a new standard called Continuous Access and Evaluation Profile (CAEP) which uses a concept called Shared Signals and Events. Yes, they are using the acronym SSE. CAEP was initially introduced by the Google Cloud Identity team in 2019. Like CARTA, this concept isn’t new and is based on integrations between various vendors that are “device aware”. CAEP uses a publish and subscribe model and is used to establish trust between parties that either provide information (publishers) or consume information (subscribers). These communication channels use peer-authenticated TLS to ensure authenticity, privacy, and integrity.
Identity Versus Device Posture Assessment?
While most organizations message these capabilities as a single item, they are two separate items that are used for different purposes.
Device identity may be used to identify the “source” of the system to apply different policies. For example, a device that issues from IT may have “watermarks” that help identify it as corporate-owned. Common watermarks include IT-created files in specific paths and IT-created keys in the Windows Registry. When these two factors are found, it is very likely that the system is one that came from IT. The organization can create a policy that says if the factors are missing, the system is BYOD and a different authorization policy may be applied.
Device identity may also be used to authorize access to resources. For example, connecting to a Windows Remote Desktop Server from an iPhone doesn’t make much sense since it would be hard to use. A policy can exclude mobile devices from RDP access.
Device posture assessments may be used to ensure that the end user’s device is in a “safe” state. This may be unrooted Android devices or a macOS laptop with Auto Updates enabled. It may also mean running software, such as Antivirus, that the organization has installed and is using to not only protect the system but also to get additional system information from it.
How Are These Checks Done?
These checks range from very simple to more integrated. An example of a very simple device identity source is the user-agent string from a browser. However, simple sources like that are very easy to fake and shouldn’t be used alone.
A client running on a device is the ideal method for getting lots of factors, in some cases hundreds. There are also integrations with various other sources such as domain-joined Windows machines using Windows Management Instrumentation (WMI). Having a client on the end-user device may also mean the ability to perform remote device remediation when it goes out of compliance. Integrations with Endpoint Detection and Response (EDR) and Mobile Device Management (MDM)/Unified Endpoint Management (UEM) area also very popular.
When Should These Checks Be Done?
The simple answer is always, however, we know that not all vendors do this. Most vendors do checks when a connection is initiated. Ideally, you’ll want to know the state of the device even when it’s not connected. Moreover, most vendors check incrementally, usually every 15 or 20 minutes. Again, ideally, the checks, for critical factors, should be instant. An example of this is an EDR can detect the running of malware in real-time. The EDR should notify the solution and the appropriate resource, signaling that a reduction in authorization should happen immediately. Waiting 15 minutes can mean that a lot of damage and malware propagation can occur.
To learn more about how Banyan handles Device Trust and how Continuous Authorization addresses threats in real-time, visit https://www.banyansecurity.io/device-trust/.
