Zero Trust, Device Context and the Chrome Zero-Day Vulnerability

When thinking about Zero Trust security, there are two predominant characteristics that get the most attention: least privileged access and authentication before connection. It makes sense when you think about it—both are the exact opposite of the behavior we are used to from legacy, perimeter-based private network solutions.

I used to work for a VPN company in the early 2000s. When we described a VPN to people unfamiliar with what the technology did, we would say, “Think of it like a really long Ethernet cable that you could plug into the LAN port at your desk at work and now, remotely, you have access to everything on the network, just as if you were at the office.” We now know what a horrible approach this is if an organization cares at all about security, because once a user authenticates, they likely have access to most of the network.

The concept of least privileged access just makes sense when giving an employee and their device access to resources on a corporate network. In fact, it makes so much sense that organizations benefitting from Zero Trust security for remote workforces are also implementing Zero Trust for users in the office.

Similarly, the concept of authentication prior to connection is turning the legacy paradigm on its head. If you had a traditional VPN concentrator in your environment, your users’ credentials would be stored on that device, and you would have to allow connections to it and allow it to be visible on the public Internet. We have learned why this is a security concern. 

My favorite metaphor is this: imagine you are sitting at home with the family one Friday night watching a movie. The doorbell rings so you hop up, go to the door, open it, not having any idea who is there. You invite the person in, close the door and then say, “Hi! Who are you and what can I do for you?” You would NEVER take that approach to identity and intent. You would verify those things prior to them entering your home. You should similarly verify identity and intent prior to giving someone or something access to your protected applications and resources.

Context matters too

As Zero Trust matures, we are recognizing the importance of another Zero Trust principle: context. For example, little is known about the just announced vulnerability in Google Chromium—the open source browser that forms the basis for the Chrome browser and other browsers like Microsoft Edge—other than it relates to V8, Chromium’s JavaScript engine.

This event provides a powerful example of why context matters. Your Zero Trust system may be able to verify that I am who I say I am when attempting to connect and, after granting me access, can limit my access to only the applications and resources I need to do my job. 

But other questions remain. Can it identify a security concern with my device? Many systems can do this with a posture check. Is an anti-virus process, like CrowdStrike, running? Is my traffic originating from an IP address that correlates with where I should be on the planet? Has my device been updated to a version of its OS that is acceptable to the organization? These can all be critical checks that a system can investigate prior to allowing a connection.

But what does your organization do about users not updating their browser after a vulnerability like the one in Chromium is identified? Is that on your list of available posture checks from your Zero Trust Network Access (ZTNA) provider?

The power of Appgate SDP

It is in circumstances like these where Appgate SDP, our industry-leading ZTNA solution, really shines. Our developers have already released extensions that customers can deploy in their Appgate collectives to check a user’s version of Chrome on that user’s device, whether it be Windows, macOS or Linux. If the user has not updated their browser, our customers can limit or deny user access to protected resources. This is the power of a software-only security solution that is mature and adaptable. 

If you are an Appgate customer reading this post and want to enable Chrome browser version checking on your collective, you can find implementation instructions from our Knowledge Base here.

If you are not an Appgate customer and want to learn more about how Appgate SDP can protect your environment, please reach out to us via the “Talk to an Expert” button at the top of this page. We’d be delighted to speak with you.

Additional Zero Trust resources

Appgate SDP Overview
Blog: How Zero Trust Network Access mitigates risk from insider threats
Blog: Implementing your Zero Trust security journey