800+ IT
News
als RSS Feed abonnieren📚 Establishing device trust in a Zero Trust architecture
💡 Newskategorie: IT Security Nachrichten
🔗 Quelle: twingate.com
Although Zero Trust has been around for decades, it’s still a frequently misunderstood concept. At Twingate, we’ve had thousands of customer conversations about Zero Trust, and we’ve developed a simple, easy-to-understand definition of that framework. In practice, Zero Trust boils down to a simple question that’s asked on every access attempt:
While the question is straightforward, answering it accurately and consistently is tricky. First, how do you judge if a user or device is legitimate? And second, how do you apply consistent access requirements across multiple platforms, tools, and systems?
We’re excited to announce new Device Security capabilities that make it easy to consistently and securely establish “device trust” as part of a Zero Trust framework. This feature set will allow companies to define what constitutes a trusted device and incorporate these definitions into access policies. This way, admins can be sure that only users on secure devices are accessing your most protected resources.
To explain our approach and vision, we’ll start with a review of the categories of devices out in the wild today and the complicated ecosystem required to define a trusted device. We’ll end with our take on solving device security and how this vision shapes our future roadmap.
Devices in the workplace
While every organization’s environment is different, one pattern we’ve consistently heard from our customers is that their organizations have three categories of devices:
- Company-managed devices used by employees
- Personal devices used by employees
- Non-managed devices used by third parties (e.g. contractors, auditors)
There are different sets of identifying characteristics and challenges to determining the security posture for each device type.
Not surprisingly, company-managed devices tend to be the most controlled. Their serial numbers are typically recorded and tracked, they may have device management or endpoint detection software installed, and their security settings are often locked and reviewed continuously. From an IT security perspective, these devices are in great shape - they’re locked down, controlled as needed, and admins can take action if something suspicious arises.
For personal devices used by employees, there’s much less control. Even if organizations want to guide employees away from using their personal devices, the reality is that it’s practically unavoidable in today’s mobile, distributed work environment. While some organizations will require their end users to install software in order to access company resources, most take the approach of trusting their employees to do the right thing. Instead of imposing stringent requirements on installed security software, employees are given leeway and taught best practices on how to keep corporate information safe.
And finally, devices used by third parties are often the wild card. Organizations typically don’t have visibility into these devices and have little control over what these third parties are doing. Out of necessity, there’s a fair amount of implicit trust in these third parties, and admins are left with relying primarily on identity authorization to determine access.
Defining device trust
What it means to be a “secure” and “trusted” device for these different categories of devices will vary. The highest level of security and trust can be achieved with company-managed devices, as companies can utilize software, certificates, or other mechanisms to ensure trust. But personal and third-party devices are trickier.
For company-managed devices, the tools available to assess device trust generally fall under one of the following categories:
- Endpoint detection and response (EDR) software: ensures compliance with set device standards and requirements
- Mobile device management (MDM) software: enables IT to easily manage end user devices, including applications and configurations, policies and certificates, etc.
- Certificates: verifies the device identity and are managed by IT
However, there are significant challenges when attempting to use these tools to establish a consistent view of device trust.
The first problem is that these tools aren’t consistent across platforms. Some tools cover desktop but not mobile devices, tools may only support a single platform, and certificates need to be individually managed and pushed across each device type. While this allows a high level of customization, it also means a higher level of complexity for IT to manage.
The other issue is that these tools exist outside of user identity systems, making it challenging to connect device context with user identity for access control policies. The tools can pull significant amounts of data from the devices themselves, but substantial additional work is required to connect all that data to the end user’s identity. As such, tracking which trusted device belongs to which user means having to manage another system altogether.
And for personal or third-party devices, these tools can’t be implemented as the organization doesn’t own the devices. MDM strategies work when all devices are company-issued, but that’s not feasible given today’s mobile and ephemeral workforce. Instead, many organizations turn to device posture checks to provide some coverage.
The unfortunate result is that device posture requirements are hard to standardize and manage for most environments, given the diversity of devices and resources. It’s difficult to track the nuances between the various approaches that platforms take to security, including OS version updates and password settings. Additionally, when device posture is used as the primary method of validating devices, it frequently has to be configured per resource or application. This makes it even harder to manage across various services, inevitably opening up more avenues for errors and issues to arise.
Twingate’s approach to device trust
Twingate is well-positioned to manage device security as a component of broader IT security by acting as a single platform that bridges all resources and the network. The information we ingest and process enables us to apply device security requirements comprehensively, consistently, and granularly.
“Comprehensively” means that organizations can take into account a wide variety of inputs - user, device, resource, and network - to determine when access should be allowed (or blocked). Additionally, because we control the actual connection to the resource, we can complete these checks repeatedly both at the start of and throughout a session.
“Consistently” means bringing together different tools, systems, and device posture checks across platforms. By pulling in various device details as well as integrating with trusted device assessment methods (e.g., EDR, MDM, certificates), Twingate can offer a single place where admins can define what it means to be trusted across their organization’s different device types. A second component of consistency again builds on the fact that Twingate serves as the layer that determines whether network traffic is allowed to hit protected resources: this allows Twingate to apply controls and checks regardless of the application or where it is.
“Granularly” means that our models are flexible enough to support the various use cases in organizations today, from different levels of protected resources to various employee groups to unique device categories. Twingate enables policies to be configured and applied that are specific to users, devices, and resources, ensuring that we’re continually taking each into consideration and adhering to Zero Trust principles.
Introducing Device Security
Our belief is that admins should be able to define trusted devices however they want for all the cases they need, and that these definitions should be easily incorporated into security policies. To make this vision possible, we’re excited to announce Device Security, which we’ll be rolling out over the next few weeks. This enables our customers to define what it means to be a trusted device and then incorporate these definitions into security policies across their environment.
The base-level configuration allows admins to identify the minimum device requirements to access Twingate. These checks, using native device posture details from Twingate’s desktop and mobile applications, can require hard drive encryption, screen lock passwords, etc. Only devices that meet these per-platform requirements will be able to access Twingate and associated protected resources.
On top of these initial foundational requirements, admins can configure specific Trusted Profiles that grant access when more security is required. For these, admins can select to layer on additional native device posture checks and require a Trust Method. The Trust Method identifies devices that meet a more stringent device verification method beyond the native device posture checks. Today, we support devices manually or programmatically marked as Trusted to meet this requirement.
Over the course of the year, we’ll continue to expand on our Trust Methods, enabling customers to define trust however they see fit. This means that we’ll be rolling out further integrations with EDR and MDM software, adding to our native device posture checks, and incorporating certificates to verify devices.
In addition to creating Trusted Profiles, Twingate Device Security allows these profiles to be associated with Resource Policies to ensure that only the right, trusted devices can be used to access more sensitive resources. This makes it easy for admins to get specific regarding which resources need higher levels of protection and verification.
We’re excited to make consistent, straightforward device security a reality for our customers, a crucial part of our mission to make it easy to adopt Zero Trust principles.
...