Device Trust in a Zero Trust World
Alex Marshall
•
Jun 2, 2021
When we introduced our vision for identity-first networking last quarter, we explained why we’re challenging the decades-old assumptions baked into the networks we use today. One of the core assumptions is that connecting to a network gives users the right to access network resources. For decades the industry has been unable to shake this thinking, which is rooted in network design decisions that pre-date the modern Internet. Twingate enables our customers to begin to move beyond this paradigm, and today we’re unveiling the next foundational cornerstone towards building a modern network.
Attaching stable user identity to every network packet is an essential part of that foundation, but the device the user connects with is an equally important part of securing and authorizing network access. Unlike identity—which is inherently a portable concept and has spawned a wide range of technologies to evaluate identity across systems from LDAP to OAuth—device trust is a more fluid concept that requires a different approach.
Device trust is a dynamic state, but rarely treated as such
User identity has the benefit of being a focused problem: establishing that a single person can prove their identity to a high level of confidence. Establishing whether a particular device is sufficiently trustworthy at a particular point in time, however, is a more complex problem. A user may use many different types of devices in different circumstances, and the state of any device will change over time, too. This makes device trust a process of dynamic evaluation rather than a static designation. The question that admins should be asking isn’t, “Can I trust this device?‚, but rather, “Can I trust this device right now and for this network connection?‚
These are some of the challenges with evaluating device trust today:
Device state changes constantly. To name just a few examples, a new OS security patch may be made available, a user may connect to an unsecured network, or a device may move to a new geography. Any of these events are triggers to re-evaluate device trust.
Different internal resources require different levels of trust. Most existing solutions to device trust are an all-or-nothing affair. Either use an approved device, or lose access to all resources in your network, regardless of sensitivity.
Existing approaches are rarely operating system agnostic. The majority of our customers support users on at least three different operating systems and have neither a single view into devices being used nor a framework for auditing and enforcing access.
Solutions to date have focused on building walled gardens where a subset of applications and data are partitioned off from the device’s native environment. You’ll notice that this approach derives from the same all-or-nothing thought process that permeates existing networking security. While effective in theory, this approach increases user friction, adds significant admin overhead, and is rarely implemented without significant compromise.
Twingate’s device trust framework
A forward-looking solution that acknowledges the messy user-device-resource reality of today’s workforce needs to satisfy the following requirements:
Provide visibility across any operating system and platform. If your users use it, you need to know about it and have access to that information from a single location.
Collect device context from as many sources as possible. Device trust depends on many factors, so it’s important that the system evaluating trust has access to as much data as possible. This can range from EDR assessment data to geolocation to whether a company-issued certificate has been deployed to the device.
Treat device trust as a dynamic, calculated status. Device trust assessment must not only react to changes in device context, but also to the specific network request being made. Device context sufficient for access to your company’s wiki is unlikely to be acceptable for access to production systems.
Because Twingate runs on any platform and authorizes network routing decisions directly on users’ devices, we’re in a unique position to both provide fully centralized network and device visibility and implement the controls to keep your network safe. We do this with virtually no user friction and straightforward admin management.
Device Details: What you can’t see can hurt you
The first step is understanding what devices are being used to access your network. With Twingate, you can already ensure that only known identities are accessing protected resources on your network, and our Device Details functionality now supplements this information with rich device information across all platforms.
At a glance, you are now also able to see what devices are connected to Twingate, detailed information about devices, and whether the device is trusted. This information can also be sorted, exported, and summarized in a new Devices table view in the Twingate Admin console.
Over time we will be expanding the range of device information that we collect, both via the Twingate client application and from 3rd party integrations with MDM and EDR products our customers already have deployed. We will also be enriching our existing identity-based network analytics information with collected device information to continue to provide our customers with the most complete picture of network activity.
Security Policies: One identity, many trust contexts
Twingate’s Security Policies framework is our next step towards providing increasingly refined controls for user access to your network resources. Security Policies currently give you granular control over the identity provider to use for authentication, authentication session lifetime, 2FA requirements, and operating system restrictions. This product area is one that we will be making significant investments in going forwards, and we’ll talk about the latest extension to this functionality, Trusted Devices, in the next section.
Because device context information can be pulled from many sources including EDR, MDM, and via the Twingate client app itself, you will see the Security Policy framework start to incorporate controls that take these systems into account. Our status as a neutral collection point for this information will not only allow Twingate to provide you with the most complete picture of your environment across any device in any location, but also allow you to create custom policies for your environment that take this dynamic information into account.
Trusted Devices: When identity isn’t sufficient
The Trusted Device functionality that we’re launching today is a very first step towards building the dynamic trust status that we defined in our device trust framework.
Starting today, admins will now be able to mark devices as trusted, which will allow defining Security Policies that take this status into account. This policy requirement can be enforced for any device, on any platform, and in any location with nothing but the Twingate client app required.
While this trusted/untrusted status is suitable for many scenarios where access must be restricted to known devices, we see this functionality as a fundamental building block for more nuanced policies in the future. We will soon be extending this concept to make device trusted status be conditional on a number of factors, including the destination resource that is being accessed, 3rd party reporting from MDM and EDR systems, and additional context collected from the Twingate client application itself.
Our newest customers
We’ve invested heavily in automation at Blend and Twingate is a powerful platform that allows us to programmatically deploy and maintain a zero trust approach to our infrastructure.
- Paul Guthrie, Information Security Officer at Blend
We’re excited to welcome a number of great companies to the Twingate customer family. Since our launch, we’ve been humbled by the reception we’ve received from some of the most innovative, fastest-growing companies around the world.
Companies like Blend, bitpanda, Hippo, and others are quickly recognizing the value of a modern zero-trust architecture based on Twingate’s model of Identity-First Networking. Our customers report increased user satisfaction, seamless deployment and administration, and a markedly improved security posture. As an added bonus, most of our customers also realize significant cost-savings with Twingate versus their existing VPN, especially when considering the amount of time spent managing and troubleshooting VPN problems.
In addition, one of our recent product launches that our customers are most excited about is our new Twingate Terraform Provider. We’ll be covering this in more detail in a future blog post, but this integration now allows our customers to deploy and update their Twingate configuration at the same time that they make changes to their internal network. It’s no longer necessary to manually deploy and update your Twingate configuration to stay up to date with infrastructure changes. All of this is taken care of automatically via our Provider, which uses our public Admin API.
Stay tuned
Today’s product launch is just the tip of the iceberg around what we see as an incredibly rich product area around device trust that has long been underserved. We’re moving quickly, and we can’t wait to show you what we’re working on next.
Give Twingate a try for free today. We’d love to hear what you think.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Device Trust in a Zero Trust World
Alex Marshall
•
Jun 2, 2021
When we introduced our vision for identity-first networking last quarter, we explained why we’re challenging the decades-old assumptions baked into the networks we use today. One of the core assumptions is that connecting to a network gives users the right to access network resources. For decades the industry has been unable to shake this thinking, which is rooted in network design decisions that pre-date the modern Internet. Twingate enables our customers to begin to move beyond this paradigm, and today we’re unveiling the next foundational cornerstone towards building a modern network.
Attaching stable user identity to every network packet is an essential part of that foundation, but the device the user connects with is an equally important part of securing and authorizing network access. Unlike identity—which is inherently a portable concept and has spawned a wide range of technologies to evaluate identity across systems from LDAP to OAuth—device trust is a more fluid concept that requires a different approach.
Device trust is a dynamic state, but rarely treated as such
User identity has the benefit of being a focused problem: establishing that a single person can prove their identity to a high level of confidence. Establishing whether a particular device is sufficiently trustworthy at a particular point in time, however, is a more complex problem. A user may use many different types of devices in different circumstances, and the state of any device will change over time, too. This makes device trust a process of dynamic evaluation rather than a static designation. The question that admins should be asking isn’t, “Can I trust this device?‚, but rather, “Can I trust this device right now and for this network connection?‚
These are some of the challenges with evaluating device trust today:
Device state changes constantly. To name just a few examples, a new OS security patch may be made available, a user may connect to an unsecured network, or a device may move to a new geography. Any of these events are triggers to re-evaluate device trust.
Different internal resources require different levels of trust. Most existing solutions to device trust are an all-or-nothing affair. Either use an approved device, or lose access to all resources in your network, regardless of sensitivity.
Existing approaches are rarely operating system agnostic. The majority of our customers support users on at least three different operating systems and have neither a single view into devices being used nor a framework for auditing and enforcing access.
Solutions to date have focused on building walled gardens where a subset of applications and data are partitioned off from the device’s native environment. You’ll notice that this approach derives from the same all-or-nothing thought process that permeates existing networking security. While effective in theory, this approach increases user friction, adds significant admin overhead, and is rarely implemented without significant compromise.
Twingate’s device trust framework
A forward-looking solution that acknowledges the messy user-device-resource reality of today’s workforce needs to satisfy the following requirements:
Provide visibility across any operating system and platform. If your users use it, you need to know about it and have access to that information from a single location.
Collect device context from as many sources as possible. Device trust depends on many factors, so it’s important that the system evaluating trust has access to as much data as possible. This can range from EDR assessment data to geolocation to whether a company-issued certificate has been deployed to the device.
Treat device trust as a dynamic, calculated status. Device trust assessment must not only react to changes in device context, but also to the specific network request being made. Device context sufficient for access to your company’s wiki is unlikely to be acceptable for access to production systems.
Because Twingate runs on any platform and authorizes network routing decisions directly on users’ devices, we’re in a unique position to both provide fully centralized network and device visibility and implement the controls to keep your network safe. We do this with virtually no user friction and straightforward admin management.
Device Details: What you can’t see can hurt you
The first step is understanding what devices are being used to access your network. With Twingate, you can already ensure that only known identities are accessing protected resources on your network, and our Device Details functionality now supplements this information with rich device information across all platforms.
At a glance, you are now also able to see what devices are connected to Twingate, detailed information about devices, and whether the device is trusted. This information can also be sorted, exported, and summarized in a new Devices table view in the Twingate Admin console.
Over time we will be expanding the range of device information that we collect, both via the Twingate client application and from 3rd party integrations with MDM and EDR products our customers already have deployed. We will also be enriching our existing identity-based network analytics information with collected device information to continue to provide our customers with the most complete picture of network activity.
Security Policies: One identity, many trust contexts
Twingate’s Security Policies framework is our next step towards providing increasingly refined controls for user access to your network resources. Security Policies currently give you granular control over the identity provider to use for authentication, authentication session lifetime, 2FA requirements, and operating system restrictions. This product area is one that we will be making significant investments in going forwards, and we’ll talk about the latest extension to this functionality, Trusted Devices, in the next section.
Because device context information can be pulled from many sources including EDR, MDM, and via the Twingate client app itself, you will see the Security Policy framework start to incorporate controls that take these systems into account. Our status as a neutral collection point for this information will not only allow Twingate to provide you with the most complete picture of your environment across any device in any location, but also allow you to create custom policies for your environment that take this dynamic information into account.
Trusted Devices: When identity isn’t sufficient
The Trusted Device functionality that we’re launching today is a very first step towards building the dynamic trust status that we defined in our device trust framework.
Starting today, admins will now be able to mark devices as trusted, which will allow defining Security Policies that take this status into account. This policy requirement can be enforced for any device, on any platform, and in any location with nothing but the Twingate client app required.
While this trusted/untrusted status is suitable for many scenarios where access must be restricted to known devices, we see this functionality as a fundamental building block for more nuanced policies in the future. We will soon be extending this concept to make device trusted status be conditional on a number of factors, including the destination resource that is being accessed, 3rd party reporting from MDM and EDR systems, and additional context collected from the Twingate client application itself.
Our newest customers
We’ve invested heavily in automation at Blend and Twingate is a powerful platform that allows us to programmatically deploy and maintain a zero trust approach to our infrastructure.
- Paul Guthrie, Information Security Officer at Blend
We’re excited to welcome a number of great companies to the Twingate customer family. Since our launch, we’ve been humbled by the reception we’ve received from some of the most innovative, fastest-growing companies around the world.
Companies like Blend, bitpanda, Hippo, and others are quickly recognizing the value of a modern zero-trust architecture based on Twingate’s model of Identity-First Networking. Our customers report increased user satisfaction, seamless deployment and administration, and a markedly improved security posture. As an added bonus, most of our customers also realize significant cost-savings with Twingate versus their existing VPN, especially when considering the amount of time spent managing and troubleshooting VPN problems.
In addition, one of our recent product launches that our customers are most excited about is our new Twingate Terraform Provider. We’ll be covering this in more detail in a future blog post, but this integration now allows our customers to deploy and update their Twingate configuration at the same time that they make changes to their internal network. It’s no longer necessary to manually deploy and update your Twingate configuration to stay up to date with infrastructure changes. All of this is taken care of automatically via our Provider, which uses our public Admin API.
Stay tuned
Today’s product launch is just the tip of the iceberg around what we see as an incredibly rich product area around device trust that has long been underserved. We’re moving quickly, and we can’t wait to show you what we’re working on next.
Give Twingate a try for free today. We’d love to hear what you think.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Device Trust in a Zero Trust World
Alex Marshall
•
Jun 2, 2021
When we introduced our vision for identity-first networking last quarter, we explained why we’re challenging the decades-old assumptions baked into the networks we use today. One of the core assumptions is that connecting to a network gives users the right to access network resources. For decades the industry has been unable to shake this thinking, which is rooted in network design decisions that pre-date the modern Internet. Twingate enables our customers to begin to move beyond this paradigm, and today we’re unveiling the next foundational cornerstone towards building a modern network.
Attaching stable user identity to every network packet is an essential part of that foundation, but the device the user connects with is an equally important part of securing and authorizing network access. Unlike identity—which is inherently a portable concept and has spawned a wide range of technologies to evaluate identity across systems from LDAP to OAuth—device trust is a more fluid concept that requires a different approach.
Device trust is a dynamic state, but rarely treated as such
User identity has the benefit of being a focused problem: establishing that a single person can prove their identity to a high level of confidence. Establishing whether a particular device is sufficiently trustworthy at a particular point in time, however, is a more complex problem. A user may use many different types of devices in different circumstances, and the state of any device will change over time, too. This makes device trust a process of dynamic evaluation rather than a static designation. The question that admins should be asking isn’t, “Can I trust this device?‚, but rather, “Can I trust this device right now and for this network connection?‚
These are some of the challenges with evaluating device trust today:
Device state changes constantly. To name just a few examples, a new OS security patch may be made available, a user may connect to an unsecured network, or a device may move to a new geography. Any of these events are triggers to re-evaluate device trust.
Different internal resources require different levels of trust. Most existing solutions to device trust are an all-or-nothing affair. Either use an approved device, or lose access to all resources in your network, regardless of sensitivity.
Existing approaches are rarely operating system agnostic. The majority of our customers support users on at least three different operating systems and have neither a single view into devices being used nor a framework for auditing and enforcing access.
Solutions to date have focused on building walled gardens where a subset of applications and data are partitioned off from the device’s native environment. You’ll notice that this approach derives from the same all-or-nothing thought process that permeates existing networking security. While effective in theory, this approach increases user friction, adds significant admin overhead, and is rarely implemented without significant compromise.
Twingate’s device trust framework
A forward-looking solution that acknowledges the messy user-device-resource reality of today’s workforce needs to satisfy the following requirements:
Provide visibility across any operating system and platform. If your users use it, you need to know about it and have access to that information from a single location.
Collect device context from as many sources as possible. Device trust depends on many factors, so it’s important that the system evaluating trust has access to as much data as possible. This can range from EDR assessment data to geolocation to whether a company-issued certificate has been deployed to the device.
Treat device trust as a dynamic, calculated status. Device trust assessment must not only react to changes in device context, but also to the specific network request being made. Device context sufficient for access to your company’s wiki is unlikely to be acceptable for access to production systems.
Because Twingate runs on any platform and authorizes network routing decisions directly on users’ devices, we’re in a unique position to both provide fully centralized network and device visibility and implement the controls to keep your network safe. We do this with virtually no user friction and straightforward admin management.
Device Details: What you can’t see can hurt you
The first step is understanding what devices are being used to access your network. With Twingate, you can already ensure that only known identities are accessing protected resources on your network, and our Device Details functionality now supplements this information with rich device information across all platforms.
At a glance, you are now also able to see what devices are connected to Twingate, detailed information about devices, and whether the device is trusted. This information can also be sorted, exported, and summarized in a new Devices table view in the Twingate Admin console.
Over time we will be expanding the range of device information that we collect, both via the Twingate client application and from 3rd party integrations with MDM and EDR products our customers already have deployed. We will also be enriching our existing identity-based network analytics information with collected device information to continue to provide our customers with the most complete picture of network activity.
Security Policies: One identity, many trust contexts
Twingate’s Security Policies framework is our next step towards providing increasingly refined controls for user access to your network resources. Security Policies currently give you granular control over the identity provider to use for authentication, authentication session lifetime, 2FA requirements, and operating system restrictions. This product area is one that we will be making significant investments in going forwards, and we’ll talk about the latest extension to this functionality, Trusted Devices, in the next section.
Because device context information can be pulled from many sources including EDR, MDM, and via the Twingate client app itself, you will see the Security Policy framework start to incorporate controls that take these systems into account. Our status as a neutral collection point for this information will not only allow Twingate to provide you with the most complete picture of your environment across any device in any location, but also allow you to create custom policies for your environment that take this dynamic information into account.
Trusted Devices: When identity isn’t sufficient
The Trusted Device functionality that we’re launching today is a very first step towards building the dynamic trust status that we defined in our device trust framework.
Starting today, admins will now be able to mark devices as trusted, which will allow defining Security Policies that take this status into account. This policy requirement can be enforced for any device, on any platform, and in any location with nothing but the Twingate client app required.
While this trusted/untrusted status is suitable for many scenarios where access must be restricted to known devices, we see this functionality as a fundamental building block for more nuanced policies in the future. We will soon be extending this concept to make device trusted status be conditional on a number of factors, including the destination resource that is being accessed, 3rd party reporting from MDM and EDR systems, and additional context collected from the Twingate client application itself.
Our newest customers
We’ve invested heavily in automation at Blend and Twingate is a powerful platform that allows us to programmatically deploy and maintain a zero trust approach to our infrastructure.
- Paul Guthrie, Information Security Officer at Blend
We’re excited to welcome a number of great companies to the Twingate customer family. Since our launch, we’ve been humbled by the reception we’ve received from some of the most innovative, fastest-growing companies around the world.
Companies like Blend, bitpanda, Hippo, and others are quickly recognizing the value of a modern zero-trust architecture based on Twingate’s model of Identity-First Networking. Our customers report increased user satisfaction, seamless deployment and administration, and a markedly improved security posture. As an added bonus, most of our customers also realize significant cost-savings with Twingate versus their existing VPN, especially when considering the amount of time spent managing and troubleshooting VPN problems.
In addition, one of our recent product launches that our customers are most excited about is our new Twingate Terraform Provider. We’ll be covering this in more detail in a future blog post, but this integration now allows our customers to deploy and update their Twingate configuration at the same time that they make changes to their internal network. It’s no longer necessary to manually deploy and update your Twingate configuration to stay up to date with infrastructure changes. All of this is taken care of automatically via our Provider, which uses our public Admin API.
Stay tuned
Today’s product launch is just the tip of the iceberg around what we see as an incredibly rich product area around device trust that has long been underserved. We’re moving quickly, and we can’t wait to show you what we’re working on next.
Give Twingate a try for free today. We’d love to hear what you think.