How to Achieve Zero Trust Security by Leveraging Your Existing Security Investments

Kristin:
Hello, everyone. This is Kristin Huber and on behalf of Banyan Security and 451 Research I would like to welcome you and say thanks for attending today’s webcast titled, How to Achieve Zero Trust Security by Leveraging Your Existing Security Investments.

Leading off today’s discussion will be Garrett Bekker, who is Principal Analyst at 451 Research. Joining Garrett will be Tarun Desikan, who is the Co‑Founder and Chief Operating Officer at Banyan Security, and closing off the discussion today will be special guest, Sadiq Khan, who is Chief Information Security Officer at BlueVoyant.

Just a few housekeeping items before we get started. To ask a question, simply type it in the question box on your screen and we’ll get to as many as we can. The presentation slides are available for download in the resources section on your screen, and finally, please check back for the on‑demand version of this webinar after the conclusion of the live event, and with that I’ll turn it over to Garrett.

Garrett:
Thanks, Kristin, and thanks everyone for joining us. Yes, so just before we start a few words about me. I’ve been at 451 for five and a half years and one of roughly six analysts on our security team currently, and my two primary coverage areas are identity and access management and data security and those two controls are pretty popular in newer areas like cloud and IoT security so I get pulled into those quite a bit.

In the past year or so I’ve spent a lot of time researching what’s known as Zero Trust phenomenon and the different vendors within Zero Trust and really taking a deep dive on Zero Trust, which is going to be the focus of our conversation today.

Very briefly for those of you who may not be aware of us, we were founded in 2000. We’ve got about 250 employees, 125 analysts like myself, gathered all over the globe. One of the things we do I’d say that’s maybe different than other firms, we write a lot of individual reports on individual vendors. And just for reference there are now about 3,000 - I heard as many as 3,500 - security vendors alone which compares to about 800 when I started five years ago so it’s quite a lot to cover. I also get asked pretty often, where does the name 451 come from so if any of you are science fiction fans that may have guessed Ray Bradbury in the science fiction novel “Fahrenheit 451” you would be correct.

So agenda today - a few key points I really want to wrap the discussion around; one, is really a focus on Zero Trust, and specifically on the evolution of Zero Trust and how we’ve gotten to this point after ten years. I also think before we do that I think we need to spend some time on definitions and some basic terms. We’ll talk a little bit about the old perimeter model and why that’s no longer working and we’ll look at some of the different terminology out there that’s been sort of conflated with Zero Trust, and then we’ll have some high level takeaways before I turn it over to Tarun and Sadiq.

So this is sort of becoming almost a cliché in security these days to talk about the perimeter being dead but it’s certainly not a very controversial statement, but I think it’s a good place to start out. This is a scene from “Monty Python and the Holy Grail” if anybody remembers that movie and the basic idea is security has historically been about building walls.

We put a perimeter or boundary around our networks and we assume that anything on the inside is trusted and anyone on the outside untrusted, and then that serves as the basis for determining what resources and applications we can access. Now, this idea is very slowly being eroded. I wouldn’t say it’s completely dead but a number of things are going on.

Obviously, there have been a lot of insider breaches in the past few years; Edward Snowdon is a prominent one but a lot of others, so you can make the point that network security is a lot less affected than it used to be. Nowadays there is a lot of phishing and social engineering going on that allows people to get in fairly easily.

But I think maybe the bigger issue is that I would argue the perimeter is becoming less and less relevant. You take a very extreme example, thanks to things like cloud and mobile and IoT and users as well - you know, you may have users who may or may not be employees, right, they could be contractors or partners, they may be temporary workers, they may or may not be in your corporate directory or your HR system, they may be in the office or outside of the office. They could be in a Starbucks; they could be accessing applications that are SaaS apps from an unmanaged device. And the point is that at no time will any of this cross the traditional corporate network so it’s really hard to apply policy to what your users can and can’t do in those types of situations.

Now the last point I want to make, and this is an interesting one, is we still seem to spend most of our money on network security. In fact, we do a fair amount of survey work at 451 and we consistently find that network security still has the highest spending plans and the highest budgets of all security technology, so that’s something that needs to change, in my opinion.

So next slide, what is Zero Trust? It’s pretty clear we need to move beyond the perimeter approach. Again, I don’t think it will be completely gone away but I think it’s safe to say that it’s not enough. We’ve heard a lot of attention in the past year or so specifically around this concept of Zero Trust, but it’s really been around for quite some time, certainly since the early 2000s; I’ll come back to this a little bit later.

But I just came back from the Black Hat conference a few weeks ago; in fact, Tarun and I ran into each other there, and I think the one takeaway is - two takeaways - there is a lot of interest in the concept of Zero Trust. Even more importantly, there’s a lot of confusion about exactly what it means. People are a little bit unclear, there are different definitions floating around that we’re going to talk about very soon.

To me, Zero Trust means a few things. One, we’re doing away with the old perimeter‑based model where everything on the inside is trusted and everything on the outside is untrusted. We’re getting to a point where access should really be more on who you are and not where you are. Again, where you are may matter but it’s not the primary thing that determines what you can access.

Another concept I like to think about is about the principle of least privilege and the idea is that you only grant users access to those things that they specifically need to do their jobs and nothing more. Up until now we - except for certain pockets - we’ve pretty much taken the opposite approach where we basically let everything in by default and then you try to filter out the bad stuff, but obviously we’re learning very quickly and painfully that that’s no longer working.

So the point of this slide is really to go over some of the different terminology out there, and again, I’ve come to the view that Zero Trust is really not about a specific technology. It’s not like - you know, if you’re in the sim space and that’s about a specific way of doing things or even an endpoint, they’re very specific technologies. To me, Zero Trust is really a collection of different technologies that really help us achieve a framework or a way of thinking about security or a philosophy of security, as it is about a specific technology.

Here are some of the different names that you may hear floating around that are not specifically 100 percent similar, but they’re very similar, somewhat adjacent. BeyondCorp is one; that’s the name that was put forward by Google; it’s become pretty popular. Conditional access is used by Microsoft. We’ve got an Identity‑Aware proxy that’s also used by Google, so lots of different names floating around but for our purposes we’ll stick to Zero Trust for this talk.

So the point of this slide is - in addition to different names there are a lot of different pieces to the Zero Trust puzzle and it really depends to a large degree on how you define it. One of the challenges I ran into when I wrote my report earlier, is if you define it very narrowly you’ve got probably 25 or so, certainly less than 50 vendors that could arguably be called Zero Trust.

Now, there are a lot more - there are other terminologies floating around these days that tend to broaden the definition. The problem you run into there is that just about any security vendor could make some sort of a claim to being a Zero Trust vendor.

But again, to simplify things I think really three key things for me that really are the essence of Zero Trust. One is, again, who are you? What you can access is more dependent on who you are. It’s important to note that it’s not just for humans. It can be users and employees but increasingly it’s non‑human factors. We’re talking about applications, we’re talking about devices; we’re talking about services as we get into the micro services framework, which Tarun may talk about.

And this implies a strong role for authentication technologies, whether it be multi-factor authentication on the device side - you can do things like IP addresses or MAC addresses, device fingerprinting so we tend to [unintelligible 00:10:08] - we’re getting a little background noise there so maybe somebody could go and -

The second piece - once you’ve figured out who you are, you need to determine what you’re allowed to access, and this implies a role for policies. So you need some sort of rules to determine, okay, what can you access once you’ve been authenticated, and this points to a role maybe for single sign on or directory services, certainly in user groups, or maybe a privileged access management service.

And then the last big piece we really need is a way to basically enforce those rules, okay? We’ve figured out who you are; we’ve figured out what you should be allowed to access. Then we need to enforce that, so that’s either allowing access, blocking access, maybe stepping up and requiring a stronger form of authentication and it also implies a role for segmentation and micro‑segmentation that we’ll talk about a bit in the next few slides.

So in my view they’re really getting into the heart of things - there are five things that are really important, five phases if you look at the evolution of Zero Trust. And this is a little bit messy; not always clear, hard and fast; there are some of these vendors that arguably could belong to multiple categories, but for the most part I think they hold pretty well.

I’d say the first part to start out is with segmentation and as I mentioned earlier Zero Trust is a concept that really goes back to the early 2000s. There were a bunch of security practitioners that got together in a thing called the Jericho Forum where they tried to deal with the potential impact of cloud computing and de‑perimeterisation, so that’s where a lot of the conceptual routes started. The actual term Zero Trust was probably put forth around ten years ago, so it’s been around longer than perhaps some people may realize, although it’s starting to really become popular now.

The basic idea of segmentation - and this actually goes back to the early 1980s when VLANs were first technically developed. They really became popular in the early 2000s when the firewall vendors started really pushing VLAN, but the basic idea is in the old perimeter model you had a flat network so once you were granted access you can pretty much go wherever you want.

Now that we’ve learned in the past few years that’s problematic people can move laterally to go after different targets once they get in, so one of the advantages of VLANs you could virtually segment your network. So maybe you set up a VLAN for different departments like HR or finance or for your developers and that will somewhat limit the amount of things you can access.

Now, a newer phenomenon is micro‑segmentation. There are some vendors that address that, and it basically takes this concept to the extreme where you can have virtual network segments reduced down to the specific servers or even actual individual workloads. One of the drivers for this was when we started having changes in the organization and we had a lot more non‑employees accessing our networks; you know, contractors and suppliers and partners. This is one way to limit what they could access and not just give them free rein to our entire network.

The second big phase is pretty much known as software‑defined perimeter, SDP, and in my view what an SDP does, is it effectively shrinks the perimeter down to a single application. So instead of being able to access the entire network or segment you get access to specific applications. And the way the SDP vendors initially did this was through some form of a combination of client software, a controller, or maybe a gateway device that could be used as an alternative to a VPN.

So if you had remote workers who need access to a specific app, you can give it to them within SDP, without needing to spend the money on a VPN and setting up the client software and what have you. Most of that - again, it was a lot of on‑prem hardware and software that typically consisted of proxies and whatnot that would typically sit on your internal network in front to your applications, your directories, your servers and what have you.

I won’t spend too much time on this one but a lot of the identity‑based vendors like Duo or Okta - there’s a typo there, sorry, it should be Duo - or even Microsoft are basically leveraging their authentication, multi-factor authentication, single sign on capabilities to deliver a Zero Trust experience.

The next one I think is getting very popular right now but the CDN players, vendors like Akamai, Cloudflare have gotten in this space which is a logical move, given they have very highly distributed networks and it’s fairly straightforward to use their cloud‑based architecture to allow employees and partners to access internal applications.

We call it Man in the Middle Cloud because essentially they almost function like a cloud‑based proxy. To access your applications you go through their cloud and then you apply policy, and then if everything passes they will then forward you down to the target applications. Again, this is an alternative to a VPN and the difference with the initial SDPs is that you totally don’t need a lot of on‑prem hardware; much of it just sits up in the cloud.

Lastly, what we’ve come to call the cloud-integrated Zero Trust providers, and I would put Banyan in this category, I would say the essential difference from the prior group is that the cloud-integrated Zero Trust providers basically can leverage your existing cloud infrastructure.

Years ago many folks didn’t have many cloud resources; nowadays almost every enterprise has some degree of cloud infrastructure. They’ve invested in AWS and Google Cloud and Azure or likely all three of them. They’ve got SaaS apps, they’ve got virtual private clouds, etc, so the cloud-integrated approach allows you to achieve Zero Trust remote access by leveraging those investments you’ve already made in cloud, rather than going through a proprietary cloud from a CDN provider.

So getting near the home stretch on my section, some of the benefits of Zero Trust; obviously there better be some benefits because otherwise there’d be no reason going through the effort, but I’d say obviously one of the main benefits of doing Zero Trust is to greatly reduce, if not eliminate your alliance on VPNs for remote access and that’s something I think Tarun will talk about in a little more detail.

Google; great example - Google came up with their BeyondCorp model a couple of years ago. One of the things they wanted to do is try to get rid of phishing attacks, and one of their stated goals is to have every Google employee work from an untrusted network, so any network, anywhere, trusted or not. Just do away with this notion of trust and do so without using VPN.

Now, another key benefit of reduced attack surface - one of the advantages of doing a Zero Trust architecture or an SDP is that you can you access applications without exposing them to the public internet. So if the bad guys can’t probe or basically can’t see your applications then they can’t attack it, which certainly makes it a lot harder.

Potentially lower cost; there may be some initial upfront costs or at least the theory is that over time you can reduce some of your costs by getting rid of your dedicated hardware and what have you.

Now it won’t necessarily be easy. Cost is one of the potential benefits; it’s also potentially a drawback, at least upfront, and one great example is Google, mighty Google with all their financial and technical resources - it took them three years to design their BeyondCorp model so I think for a lot of firms this is really unrealistic so we really need to think about ways we can achieve some of the benefits of Zero Trust with leveraging what you have and without necessarily ripping apart your entire infrastructure.

This is an issue we hear over and over from enterprises, have a lot of conversations about this. A couple of weeks ago at Black Hat, particularly in areas like financial services and healthcare and oil and gas where there are potentially millions, hundreds of millions of dollars invested in legacy equipment that’s not going away any time soon.

Complexity is another big issue. There can be many pieces to a Zero Trust architecture as we discussed earlier, so making sure they all work together is not always trivial. There are certainly no vendors out there that I’m aware of that sell the entire Zero Trust framework in a single solution or in a box. It just doesn’t exist. When you get into really micro‑services and you’ve got instances spun up and down very rapidly and you’re doing micro‑segmentation things can get pretty complicated, pretty quickly, so certainly there is a role for automation to be played here.

And the last one, perhaps the most important, the user experience. User experience is one of the main reasons we’re doing this, but if you don’t get it right, you know the first time you have an executive who can’t access a sensitive application there are certainly going to be some blowback and some complaints, so certainly we need to minimize disruption and what have you.

So really the point of this is we don’t really need to achieve this all overnight and think of it really as a journey. I know that sounds like a cliché in security, but certainly there can be some quick wins early off without, again, ripping everything apart. One of the things you might be able to do is identify one or two really risky applications or very sensitive applications that have a big impact on worker productivity.

Start out there, enable Zero Trust and maybe your apps like Jira or Confluence - you know enable access to them without a VPN; that could certainly be a good way to start. Or you could do a similar thing where you pick out one or two very risky applications - you keep your VPN but you supplement it with SDP or Zero Trust to help you reduce the risk and make it more secure as, I guess, almost a defense and [desktop] approach.

Certainly just enabling more MFA would be a big win for a lot of firms. Our data shows just over 50 percent of enterprises actually use multifactor authentication, so just deploying MFA more broadly, in my opinion, would actually be a win here. But again the point is, let’s think about Zero Trust as a journey and an ongoing process rather than a big bang, quick fix.

So that’s basically it from my section; a few key points to leave you with. We’re very early in the days of Zero Trust so there are going to be a lot of new developments in the next few years, but I do think despite all the hype this could be one of the biggest developments to hit security in years, certainly in the way we think about security.

We’re probably going to see a lot of M&A. We’ve seen some already with some of the bigger vendors like Cisco and Verizon getting involved. I think that’s certainly going to continue, so I think with that, I’ll turn it over to Tarun and Sadiq to [argue] out their perspectives of Zero Trust.

Tarun:
Thank you very much, Garrett; I appreciate the info. My name is Tarun Desikan and I am a Co‑Founder of a company called Banyan. I’ve spent about 20 years in the network and security space so some of the evolution that Garrett talked about really resonated with me; pretty much all the different phases. And it’s really exciting for me to talk to you guys about how Banyan sees the Zero Trust problem and how we have companies deliver Zero Trust access to their sensitive resources. Just a little bit more about Banyan - we are what Garrett describes as a cloud‑integrated Zero Trust platform so we have been built from the ground up for today’s model and multi‑cloud and hybrid environment. We are deployed across enterprises, today across all verticals from finance to healthcare, as well as technology and companies use us primarily to either replace their VPNs or create a new security model, a new Zero Trust model for themselves; their own flavor of Zero Trust leveraging their investments.

As Garrett describes Zero Trust is a framework; it’s not just a single silver bullet and so many organizations need to figure out exactly what specific tooling, what specific investments they have and how they can use those investments to rollout Zero Trust for their employees and their applications, and that’s where Banyan comes in. So when we look at why Zero Trust evolved it actually comes down to how a traditional VPN was deployed. Now I was a VPN guy myself and so VPN was a great technology but it essentially went unchanged for about 20 years, and it was created for an environment where you had a trusted corporate network where office workers accessed corporate applications.

When you needed the office worker to go home and still have access to those applications or for remote workers you created a VPN, so the remote worker would essentially tunnel into the corporate network and then access the applications they needed to do their job. Once we started having contractors we introduced the concept of segmentation, so certain applications could be accessed by employees, others by contractors and so on.

Now, if you look at the world today it’s not that simple anymore. A lot of infrastructure has migrated to the cloud and it could be on Azure or DCP, so people have started extending their VPNs in there. Some companies have also started doing cloud native development using Docker and Kubernetes and you start extending your VPNs in there.

And finally, a lot of your applications are actually not running on infrastructure you control anymore. It might be running on SaaS platforms like Salesforce and [unintelligible 00:24:54] but that’s on the infrastructure and the application side.

What we see on the user and the devices side is that bring your own device is a real thing; pretty much every employee, every company has to deal with executives and workers who want to work on their iPhones and their iPads. Then the pool of employees and workers who need access has also changed, so suddenly what was a fairly simple, remote access problem that was dealt with, with a VPN and a trusted network, you know it just becomes very, very challenging and problematic.

So security concerns around broad access; you know, a contractor here can just get access to a sensitive application in the cloud, down to something like how complicated it is to deploy all these physical and virtual appliances that were designed for a simpler time have become really, really challenging.

So when we at Banyan think about Zero Trust, we think of Zero Trust as a model to address the deficiencies in distrusted network models. And as Garrett described Google’s BeyondCorp is probably one of the best articulated solutions where what they essentially did was create an access control engine by looking and aggregating user inventory devices and inventory policies, all the different applications into a centralized framework. Of course, as Garrett described it took them three years to do this.

And what we have realized is that many organizations want this level of security but they also do not have the resources to essentially build something like this from scratch, and so that’s where Banyan comes in. Banyan helps organizations leverage their existing security tooling to rollout Zero Trust. So specifically the way we do it is we no longer rely on the concept of a trusted network. Instead we have a cloud‑integrated solution where we provide what we call our intelligent access mesh that manages traffic into all your applications.

The access mesh is deployed close to your applications - it doesn’t matter where they run - it could be on‑premise, it could be in the cloud, it could be SaaS, and then when it comes to the entities that require access we integrate with your identity providers, ensure all access. It comes through single sign on, multifactor authentication and from a device that is both trusted and registered.

We combine all of this into a concept we call a trust score, so this is not just are you authenticated; it uses your context to figure out how trusted are you? You know, we know your location, we know exactly what kind of application you’re trying to access and what kind of device from which you’re trying to do that, and that determines a number from zero to 100 on how granular your controls need to be.

And finally, we provide a cloud command center that ties all this together, so we tie together the entities that need access, as well as the applications that you’re looking to get access into, and so from the user perspective there is just a single button, direct access into that application that you’re seeking to have.

So security teams like Banyan because the cloud command center gives them the ability to write granular policies and in real time enforce the activity that’s going on. This is something you did not get with the VPN because it’s a very static way of delivering access. The trust scoring, again, uses user context and user short lived credentials, users cartography, so some of the modern security principles are used to mediate access into applications.

The operations teams really value how quick it is to set up Banyan. A difficult installation is about ten to 15 minutes, leverages your existing cloud presence, so no new kind of complex integrations are required, and finally users, because they get direct access, are given a great user experience.

So one of the ways Banyan is able to enable organizations to quickly rollout Zero Trust is by integrating with their existing tools, so we integrate with tools such as your identity provider, so this could be Okta or Active Directory or all of those other kinds of players. We integrate with your device managers, which could be AirWatch or Jamf and so on, integrate with entity analytics tools like Splunk, and finally antivirus and EDR tools like Carbon Black or CrowdStrike, and we use all these integrations to compute a trust score for the entity that requires access.

On the deployment side our access mesh integrates with whichever cloud platform, be in Amazon or Azure or DCP or something on‑premise like VMware or Citrix; integrate with all of these to manage access into your applications. And the net result is that when a security professional comes to the cloud command center they can write simple, human readable policies in terms of my engineering team or this is the level of trust that the entity requires to get access.

So organizations that use Banyan typically end up writing three types of Zero Trust policies; one is what we call a global rule. This is a high level policy, a high level Zero Trust policy that applies to all your services, all your resources. It could be something that says, hey, if a device is at a low trust level you cannot submit source code, so this is a simple policy that an IT administrator can write and will be enforced globally across all your different applications.

You can also start getting more and more granular. You can write something on a specific service that says if you’re a finance application you can only be accessed by members from the finance team. And finally, because of the way Banyan is deployed you can actually write API level policies, and this is very useful for some development services that have sensitive data that needs to be accessed only by very specific team members.

So just in summary then what we have worked on at Banyan is to enable enterprises to provide BeyondCorp‑like security, integrated with your own tools, your own existing enterprise investments without having to build in any of them from scratch. So this both enhances security and user experience and best of all we’ve made it so that it’s simple and easy to deploy, so with that I’ll hand over to Sadiq who will talk about a real world scenario where a real world enterprise went through their Zero Trust journey and how they have been able to configure their environment rollout Zero Trust.

Sadiq:
Thanks for that, Tarun; I appreciate it and thank you all for attending the webinar today. As Tarun mentioned, my name is Sadiq Khan; I am the CISO here at BlueVoyant and come from a consulting background where I spent time both at Deloitte and Booz Allen Hamilton really refining the approach to data security, working with numerous Fortune 500 companies and helping them architect their security program and building an operational approach to defense in depth.

So a little bit about BlueVoyant - our mission here is to really democratize security for the 99 percent in today’s ecosystem, given the challenges and costs around sourcing and building an advanced security capability. That privilege is usually selected for just the 1 percent of organizations that have the ability to build that robust of a security program.

Our goal here is to deliver advanced security capabilities to the masses, along with organizations to effectively defend against the ever evolving threat landscape.

That mission really starts with our managed security services line of business where we offer a host of services centered around detection and containing attacks before they impact your business. We’ve built an [extend] orchestration engine that integrates with various technologies in your stack and allows us to really extend those advanced cyber controls to businesses of all sizes.

That’s further complemented by our threat intelligence line of business where we have unparalleled visibility and we offer that to customers both in forms of identifying threats that directly impact your business, your footprint, your attack service, but also looking at your broader third party ecosystem and helping you identify attacks that are impacting your vendors, that may end up impacting you down the line.

We also have a professional services line of business that’s led by a team of [XSDI] cyber‑crime and special agents where we have a great deal of experience helping organizations manage and respond to breaches, while also providing a breadth of professional services.

So a little bit about BlueVoyant and our growth story - we were established two years ago where we acquired a couple of entities and our initial seed round was $125 million, which really allowed us to accelerate the development of our new MSS and threat intelligence platform. So operationally what that meant was we rapidly expanded from a user‑based perspective, but also from a geographical perspective.

So BlueVoyant is now a multinational entity that has employees all over the world and customers all over the world. What that meant was we had a lot of challenges that I’m sure a lot of organizations can resonate with in terms of we had a growing user base where roles and responsibilities become a challenge to define, especially in organizations where you have rapid restructuring and reorganization.

Based on my experience that happens in organizations both small and large, right, so being able to proactively and dynamically respond to those organizational shifts is a real challenge when trying to architect these Zero Trust stories. Then you add customers, that sort of thing, products and services that you’re building as well, and that adds an additional layer of access that has to be managed and controlled, and basically adds to the complexity of securing their infrastructure.

On top of that, given the three lines of businesses, we also had distinct technology stacks that our developers and engineers were operating on, were building for each line of business. So when thinking about how to holistically build a security program that encompasses all of those you then have to start thinking about interoperability and integration challenges that you have when you’re really trying to centrally manage all of these things.

And so those were some of the challenges that we were thinking about when we sought out to build a security program that not only protected BlueVoyant, but also made sure we were securing the sensitive information that we collect for all of our customers.

And so when thinking about that you start in any security journey by defining the threat model, right, and so the goal of Zero Trust, from a threat model perspective, is to be able to defend against all attacks by opportunistic attackers that are just wanting to attack and seeing what sticks.

But it’s also targeted attacked by adversaries that maybe are using spear phishing campaigns, and also by insiders, right, where you have a host of trusted and untrusted insiders that are going to be accessing your systems from a variety of different locations and a variety of different devices.

And so the goal of Zero Trust is being able to standardize your approach to brokering assets so that attacks from any one of these threat actors can be easily identified and easily remediated. And so to be able to then build controls around that specific threat model you then have to ask yourself three basic questions. Do you understand your users? Do you have control of all assets connecting to your environment, and do you actually have a comprehensive view in your infrastructure.

And so when we talk about user and access management in a traditional setting we heard Garrett and Tarun both mention the concept of least privilege, right, but in a pragmatic, operational setting the first month you define your identity management program, where your architecture rolls and you architect the entitlement that you grant your roles.

It may look great in month one, right, because you took the time to run the analysis and figure out what people actually needed to get access to, but over time privileges add up. Users change teams, they may not be fully transitioned, they start wearing multiple hats and so privilege builds up and you lose more and more of that granular enforcement of least privilege.

And so really defining these static policies doesn’t help in terms of enabling the Zero Trust approach, right, so it’s really about being able to effectively understand our users as they grow over time, as their roles change and really integrate that into a system that’s integrated with your HR, with IT, with security, so you have this feedback loop that’s continuously refining your understanding of who is accessing your systems.

Now the second part of that equation is then understanding what assets are being used to connect your infrastructure. Do you know exactly what they are, do you know who is using them and do you have a centralized inventory of those assets so that you’re able to feed that telemetry into your authorization decisions.

And then the third part of that is how am I going to control my environment in an era where we have multi‑cloud infrastructures, where we have SaaS applications that we use, where we still have on‑prem applications that we’re deploying and using. Being able to visually define what your inventory looks like so that you’re able to architect control around that is critical for enabling the Zero Trust approach.

And so it’s not only about being able to identify what hosts you have in your environment and what servers you’re managing, but it’s also what’s running on those servers. Do you have an idea of all the applications running, do you have an idea about the software versions that those applications are running on those instances, and so all of these questions are things that were factored into our decision around how we architect the security program and how we leverage all of these different sources of telemetry and these risk factors in enabling intelligent authorization decisions.

Now that sounds great from a conceptual perspective, being able to completely understand our users, identify your devices, know what your infrastructure looks like and being able to seamlessly string those altogether. But we know in reality that that’s not a magic bullet, if you will, right; there is no one solution that you can purchase off the shelf that’s going to give you all of those things and then also enforce Zero Trust access controls for you?

And so it’s really about establishing core tenets of your security program, right, and that’s the approach that we took when setting off on this journey two years ago. These are controls that you’ll see in any security program that’s built on defense and [dump] principles, right, so being able to curate threats that impact your business, both from an external perspective but also an internal perspective, right, so running those vulnerability scans and being able to feed those to your security and operations teams so that you’re effectively patching your devices, you’re prioritizing which vulnerabilities you should remediate, and at the very least you have a robust understanding of all the vulnerabilities across your environment.

And then from an identity and access management perspective we talked about how critical this was in terms of enabling the Zero Trust approach. And just to focus on that a little more, it’s my opinion that this is probably one of the most important parts about the Zero Trust equation, right, because as we talked about being able to define roles and attributes in a dynamic environment is extremely challenging. The approach we’ve taken is to automate as much of that based on a tight integration with your HR information security system.

And so when a user is onboarded, when a contractor in onboarded you absolutely must have a gate there that allows HR to feed certain attributes to the rest of the environment. Where the new hires are going to be located, what teams are they on, who do they report to, what types of functions will they be performing, and you really need to create automatic rule‑based attributes that dynamically populate your backend engine so that any change that’s made to a user’s profile automatically flows down to the rest of your source system, and then is effectively used when making risk‑based access decisions.

Endpoint protection is the first gate here, if you will, when you think about Zero Trust equation. The first Zero Trust equation, the first thing that gets evaluated is what device is trying to connect to my environment. And so being able to layer in defenses from an endpoint perspective is critical here as well.

Do I have a way to enforce - all my endpoints are patched? Do I have a way to discover all of the applications running on my endpoint? Do I have a way to broker how privileges are [leased] from my endpoint, right; we really shouldn’t be giving away local admin, for example, so you need some sort of solution that helps you lease elevated privileges and allowing you to implement a robust, auditing capability for when those privileges are invoked.

And going down the line here there are several controls that you’re going to implement across your security apparatus to give you that defense and depth posture. The challenge really here is how do I integrate all of those and how do I build those into my authorization flow so that we’re automatically and intelligently responding to threats as they come up in our environment.

And so typically organizations that have the funding, that have the resources may embark on doing them themselves. You constantly refer back to the buy vs. build decision , especially for your large Financial institutions, for example, that may have - that may be averse to purchasing third party technology, but that’s sort of the major blocker in my opinion in terms of organizations really embarking on this advanced Zero Trust journey and being able to integrate all of these different solutions when brokering access.

And so that’s sort of the position we were in about a year ago where we implemented these several layers of defenses. We had a VPN connecting into our private infrastructure in the cloud. We had certain on‑prem applications that we were hosting that were also protected by the VPN. But what we really realized was that we weren’t effectively building a Zero Trust environment, right, because VPN, you authorize once into your network and that’s really it.

Sure, you can implement certain things like hit checks and usual TLS with two factor authentication, but again, once that authentication is performed you really don’t have a way to continuously monitor what’s happening on the device and whether or not you should be taking action within an existing session, right, and that’s one of the focal points of Zero Trust, and so if you don’t have a way to implement that you’re kind of lost in terms of being able to achieve a true Zero Trust environment.

The second big operational complexity to a traditional VPN approach, from our experience is again, once you’ve strayed away from your initial design it becomes - every addition to a network zone, every change to a user’s role and attribute is a process. It takes a village to kind of come together, look at your entire network architecture again just to make a simple change.

And so really trying to enforce some of these concepts with a traditional VPN‑based solution becomes a headache, especially once you start dealing with multiple business lines, multiple zones, multiple cloud environments; it really doesn’t allow you to move at an agile pace.

As Garrett mentioned and Tarun mentioned, there are also several companies trying to do this and the way they implement their solutions provides some challenges when thinking about how to layer these defenses. So you may have a CASB solution that you’re using to track down your shadow IT, you may have a VPN solution that you’re using right now to provide access to your private cloud environment, and then you may try to introduce just third Zero Trust controller to help broker access to certain things, and the more, and more you try to layer network security access‑based solutions it becomes a gigantic architectural mess being able to tie all those together. So that’s where, you know, if we give any advice it’s really finding the right technology vendor that’s going to meet you where you are and allow you to make changes in small ways that then works to really build this true Zero Trust enterprise.

So that’s really what we found in Banyan when we started this conversation earlier this year; we presented the challenge that we had with Banyan in terms of we weren’t able to continuously evaluate authorization decisions. We had difficulty integrating a lot of these trust signals from the various tools that we’ve implemented across our environment, and when we were evaluating multiple tools that was really one of the main factors we were looking for in a solution, was being able to seamlessly tie all these together and make those continuous authorization decisions based on our existing security investment.

Banyan was by far the leader in terms of being an extensible technology vendor that allows you to accomplish all the goals of implementing a Zero Trust program while leveraging your existing technology suite. So the approach we took was, we weren’t going to completely rip and replace our VPN solution; what we were going to do was a model similar to what Google had, to build this access proxy or this security Zero Trust environment in parallel and give users the opportunity to realize the efficiencies and the benefits of using this Zero Trust environment, while giving us the confidence that we were actually evaluating authorization decisions and making intelligent response decisions based on telemetry that we were seeing in the environment.

And so we were able to loop in our Active Directory service where we have that robust, automated attribute‑based mapping. We were able to loop in all of our device and configuration management information where we have a complete understanding of what OS versions are running on an application - sorry, what OS is running on a device, what sort of logging services are enabled, is full encryption turned on; those types of factors that we’d want to check for any secure device.

Being able to combine those with telemetry that we were getting from tools like CrowdStrike or Carbon Black, process monitoring tools like OS Query and some additional investment information that we were getting from environments like Splunk, feeding those into Banyan to continuously evaluate authorization decisions is what we were able to accomplish. Again, from our perspective Banyan is one of the only providers right now that is truly extensible in a way that allows you to leverage what you already have in place, to quickly enable a Zero Trust environment.

If I had to share any tips in terms of how to effectively go about this approach, it’s really defining and then trusting the process. And so when you think about Zero Trust, again the idea is you want to enable secure access in this dynamic, ever shifting technology landscape, right, and so when you present this to a leader or a tech manager and tell them, hey, I want to take GitLab or Jira behind VPN, offer VPN so that you can access it directly they’re going to think you’re crazy and they’re going to think you actually don’t know security or you’re not actually doing your job.

But the idea is you want to invest in building a culture of security, right, where users aren’t only an additional source of telemetry where they’re recording phishing attempts where they’re reporting suspicious things that they may observe during their day to day business, but they also understand the architecture that you’re trying to build. They understand what you’re trying to achieve with this Zero Trust approach and they start buying into the concept, so user awareness and training is key here by effectively helping them understand the efficiencies they’re gaining through the process, is also very important.

The second part of that is - you know Garrett mentioned you can start with one or two apps that are really sensitive. I would offer going even smaller than that. Focus on one protocol or one application. So what we did was - we mentioned MSA isn’t often available for things like SSH or RDP access, right, so it’s figuring out some champions that you can identify in your development organization that can really get onboard, understand the security benefits that you’re getting from achieving things like MSA with SSH or RDP, and allowing them to champion how much this enables them to do their job in a secure way.

As we mentioned, we’re rolling this out with VPN in place and so it’s really not a rip and replace; it’s enabling access through a more secure method and a more secure channel and as users gain trust over time you can then focus in on honing the technologies that you’re using to broker access.

Again, really being able to focus on the user experience here is key. Being able to put in stringent competitive IP and security controls is always going to be the easy way out, but the more you make it harder for your users to do their job, the more they’re going to work to evade your controls and your defenses and actually end up being a negative for your security program. So working with solutions like Banyan that make Zero Trust easier to roll out, easy for users to adopt is imperative to a successful Zero Trust journey, so with that I will turn it back to Kristin.

Kristin:
Right; thank you so much, Sadiq. It’s now time for our Q&A session and as a quick reminder, if you have a question just type it in the box on your screen, and it does look like we have time maybe for one or two quick questions that have come in. First question - I think it’s going to be geared towards Garrett, so here goes - our leadership has decided we need to migrate to a cloud‑based Zero Trust solution. What are the pros and cons of the different approaches and what are the risks in delivering our sensitive corporate data through the cloud?

Garrett:
Sure, thanks, Kristin; so I think, and certainly Tarun and Sadiq can jump in too if they want, but I think it depends on your architecture, right, and one of the problems with I think the early SDP approach was very geared towards on‑prem architecture. I think one of the reasons people are maybe doing Zero Trust is they want to get away from that, but that would potentially be one.

Now there may be firms that are running [unintelligible 00:52:48] that may want that solution, but I would think that generally the advantages of having a cloud‑based architecture are pretty solid, particularly if you could do like a mesh‑based approach which I think is really relevant these days.

You know, as I mentioned earlier users are everywhere, applications are everywhere, devices are everywhere and I think having a gateway‑based approach which is essentially what a VPN is, or even a proxy, starts to get really cumbersome, really fast where you’re putting gateways everywhere so that would be the one issue.

I think the risk in delivering sensitive data through the cloud - you know my view is I think - so let me back up a bit. One of the biggest objections still in all the survey work we do at 451, the biggest objection to moving workloads to the cloud is still security. That said, it is declining and I think people are getting more and more comfortable with moving things to the cloud. It’s not perfect but I would certainly argue that, for the most part, what the cloud providers do and what you can get through the cloud is actually more secure than what most enterprises can do on their own. I don’t know if anyone else has anything to add to that, but that would be my view.

Tarun:

Maybe Garrett I would just add one comment to that, which is when you move to the cloud - you know of course as Banyan we are biased - but we firmly believe you should move to the cloud that you are investing in. Most companies, most enterprises we talk to today are investing in Azure or AWS or IBM or one of those clouds, and each of these clouds, even though they have different capabilities, they have more than enough capability to provide you secure access using the Zero Trust philosophy. And so that’s our bias; is when you move to the cloud use your cloud. Don’t necessarily go buy somebody else - yet another cloud essentially.

Garrett:
Great point.

Kristin:

Great; well, I think for the sake of time I think we’ll close off the webinar, so that concludes the webinar for today. Thank you so much, Garrett, Tarun and Sadiq. On behalf of Banyan and 451 Research thank you so much for attending today and have a great day; thank you.

Garrett:
Thanks, everyone.