What is Zero Trust Security?

The traditional castle-and-moat IT security framework depends on a secure perimeter surrounding a trusted network accessed by trusted users with trusted devices. But the complexity of the modern information ecosystem turns that sense of trust into a severe security risk. Increasingly, companies are turning to a zero-trust framework to address the complexity of today’s security risks.

What is Zero Trust Security?

In 2009, Google’s BeyondCorp initiative pioneered the corporate application of zero-trust security after state-sponsored cyberattacks revealed the limitations of castle-and-moat approaches to security. The company concluded that undocumented zero-day flaws, phishing, infected flash drives, and other cyberattack vectors make the internal network just as insecure as the public internet. BeyondCorp sought to redefine the concept of trust in IT security.

Zero-trust security, as its name implies, assumes that every network, every resource, every user, and every device is a potential security risk. Rather than drawing the perimeter around the network, zero-trust security draws a perimeter around every resource. Those resources are set to deny access by default.

Access to a resource is only granted once a user and the user’s device passes identity authentication and access control policies for that resource. It does not matter which network the user connects through. Access requests from the on-premises network at headquarters or from an airport WiFi hotspot are treated with the same level of suspicion.

The zero-trust framework offers several benefits for information security. Both on-site users and remote users fall within the same security infrastructure and access control system. Since security is not managed at the network level, administrators do not have to control access through complex systems of sub-networks. If a network is compromised, the breach does not compromise resources deployed on that network. Likewise, if one resource is compromised, the breach does not extend to other resources.

Remote Access: Zero Trust Vs. VPN

Once a secure solution for remote access to corporate networks, VPNs now make network security policies more brittle and reduce company productivity. 

In the traditional framework, VPNs are the portals trusted employees pass through to access resources within the perimeter. But if one is compromised then the attacker has full access to the network. To reduce the threat surface, companies split the network into subnets and divide their cloud resources among separate private networks. Each subdivision gets its own VPN gateway which administrators must maintain and keep up-to-date. End-users must switch between gateways within their VPN client and may even have to juggle multiple VPN clients.

In a zero-trust security system, the network architecture no longer matters since access happens at the resource level. Google’s approach takes this to the extreme by deploying every resource to the public internet. Per-user-per-device access control policies prevent unauthorized access without the complexity imposed by VPN technology.

Another VPN limitation is the bottleneck gateways create within a company’s network. All of the data passing between a remote user and a resource must pass through the VPN gateway. That path could be thousands of miles long even if the user and the resource are only a few blocks apart. Besides impacting user productivity, VPN backhaul issues force administrators to balance performance with the cost of infrastructure upgrades.

Zero-trust security deployments avoid these performance hits. The authentication and permissions happen on central controllers with little bandwidth overhead. The data flowing between the user and the resource pass through direct, encrypted tunnels that can follow the most efficient network path.

Twingate Zero Trust for DevOps

Although the IT community sees a lot to like about zero-trust security, companies have been slow to adopt the new framework. BeyondCorp’s approach required a complete re-engineering of Google’s IT infrastructure — as well as changes in company culture. Even with the deep pool of talent and resources at Google’s disposal, the BeyondCorp migration took a decade to complete. Most zero-trust solutions providers focus on these enterprise-scale transformation projects.

Twingate takes a different approach by addressing the needs of internal teams that can benefit most from zero-trust security. DevOps teams, in particular, are best suited to adopt zero-trust practices. Teams consist of both employees and a constantly-changing population of contractors. More often than not, those teams are geographically dispersed, use managed and unmanaged devices, and are accessing resources over the public internet. The brittle security policies and backhaul limitations of VPN solutions interfere with DevOps productivity.

By contrast, zero-trust makes the DevOps environment much easier to manage using the company’s existing security stack. And remote employees do not have to tunnel through a VPN chokepoint to access cloud-hosted resources.

How Twingate Works

Twingate’s approach to zero-trust security uses a framework called the software-defined perimeter (SDP). Unlike Google’s BeyondCorp, in which resources advertise their presence on the public internet, Twingate operates on a need-to-know basis that hides all resources no matter which network they are deployed to.

The Twingate Client does not have any information on the resource a user wants to access. It only knows about the company’s Twingate Controller. The Controller receives the Client’s connection request and determines whether both the user and the device should be allowed access. Administrators do not need to create a parallel set of access control policies since the Controller integrates with most authentication and access control systems.

Once the Controller approves the connection, it hands the Client to the Twingate Access Node. Positioned between the resource and the network, the Access Node does not advertise its presence publicly. Neither does it respond to connection requests — unless the Access Node receives the request from the Controller. In that case, the Access Node creates a secure, encrypted connection directly between the resource and the Client. Once the session ends, the Client loses everything it knows about the Access Node and its resource. The only way to reconnect is to go through the Controller all over again.

Twingate simplifies life dramatically for DevOps teams. End-users can self-provision the Twingate Client by following a consumer-like journey. Twingate supports all TCP and UDP traffic so no changes are needed to the end-users’ devices. Similarly, administrators do not need to reconfigure resources. They can deploy each Access Node using a single Docker command. And the Controller’s management console lets administrators onboard/offboard users with a single click.

From a business point of view, adopting Twingate zero-trust security does not require changes to the company’s existing security infrastructure. DevOps teams become more productive while providing stronger security for the company’s most important information resources.

Contact Twingate to learn more about zero-trust security and its benefits for your DevOps team.