Why “Zero Trust” Networks Are Important to Securing Your Hybrid Workforce

Peter: Sure, my name is Peter Alm, I'm based out of the west coast of Sweden. I'm the CTO and Chief Architect for Blastwave. Before joining Blastwave. I spent about 20 years building Deep Packet Inspection appliances for carriers. 

Alyssa: Awesome, Peter. Thank you. We'll move on to Charl.

Charl: Hey! Hi! Good morning, everyone. My name is Charl. I'm a South African based in Cape Town, South Africa. I work as the Head for Security Research at Orange Cyberdefense. Orange Cyberdefense is the cybersecurity division of Orange networks. I don't know how well the brand is known in the US but Orange Cyberdefense is probably the biggest pure-play security product and services provider in Europe. And I should also introduce my six-year-old son who's sitting just behind my computer. His job is to google things if you ask difficult questions that I don't know the answers to. 

Alyssa: Indentured servant… I love it Charl, thanks! Tom, why don't you go ahead and introduce yourself to everybody.

Tom: Sure, my name is Tom Sego. I'm the Co-founder and CEO of Blastwave. Blastwave is a company that helps protect and prevent cyberattacks using Zero Trust principles. I spent a decade at Apple and one of the missions of the company was to try to bring Apple's First Principles of Ease of Use and Simplicity to cybersecurity and that's what we're doing.

Alyssa: Awesome! Thanks, Tom. And Wicus! Why don't you go and introduce yourself as well?

Wicus: Good day, everybody. My name is Wicus. I'm also in Cape Town, South Africa. Part of Orange Cyberdefense’s research team, a colleague of Charl and, yeah, it's just me and my green screen so you don't have to worry about anything, hopefully. I'm also part of the research team there and I get to look and prod at interesting things that Charl allows me to.

Alyssa: Awesome, awesome, Wicus, so, nothing on the green screen. No idyllic field of flowers or anything like that. 

Wicus: I had enough tech issues this evening so I'm just going to keep it simple.

Tom: Nothing like the screen that Alyssa is showing right now which is… 

Alyssa: Hey this is real, Tom. This is real. Don't confuse me. Keao, you want to go and introduce yourself, we've saved the best for last.

Keao:My name is Keao Caindec. I'm a Principal Analyst here at Farallon Technology Group and we work with industrial companies, cybersecurity companies to help them navigate digital transformation and security across IT and OT from embedded to DevSecOps. So, looking forward to the discussion today.

Alyssa: Thank you so much everyone and all of you know me. I'm Alyssa Knight. I am a recovering hacker and we'd need a whole show for everything I'm involved in so I'll leave it at that. So, why don't we go ahead and get started on today's conversation. We know that everyone hates powerpoints and hates being talked to so we're just gonna all nerd out today on Zero Trust, we're gonna nerd out on all these things regarding Microsegmentation, Software Defined Networking, ZTNA and what this all means. Now, one of the things I want to talk about.. and just point the pink elephant out in the room, You know, the idea of this “Castle and Moat” sort of security infrastructure is – let's face it – it's so 90s, it's so 2000 but, you know, it's just… it's antiquated and, you know, the castle… I'm always saying, the castle has left the moat, right? Data is everywhere and people are everywhere. The pandemic has radically transformed how we do business today. Now, the first VPN… Let's talk about ZTNA first. Zero Trust Network Access. The first VPN was introduced by Microsoft in 1996. You know and since then there have been vulnerabilities and breaches as a result of VPNs. Organizations are still using them. Now, we're not only just talking about… historically, about a dissolving perimeter, but now we're even talking about the dissolving internet and, you know, questions there are raised… What's more appropriate for, you know, an organization that is just now extended to everyone's home network, you know, with people working at home? So, with that being said, Peter, can you start us out and just demystify – What the heck is ZTNA?

Peter: So, ZTNA kind of comes in a lot of different flavors depending on who you ask, but it's a way of doing security mode access with the least amount of privileges that you need – Zero Trust. In every step of the way you need to verify who's doing what. Previously, with VPN solutions and so on, you might have Echos, VLAN set on subnets or whatever. With ZTNA architecture, everything is verified. You only have access to the things that you need and nothing beyond that.

Alyssa: Forgive me if this is a dumb question but is VPN Zero Trust Network Access? or would you not even consider – I know this is a religious debate but would you consider VPNs to be a Zero Trust Network Access?

Peter: So VPNs, typically, are a trusted network access solution. I mean they like you sign on to your VPN then you have the trust to access anything you like. In some cases, you might have, like really coarse limitations based on a subnet or something like that, but it's really… you're really trusting the user with the traditional VPN setup.

Alyssa: Yeah, I agree. Not only just trusting users but you're trusting this device that they're on. You're trusting the data, trusting that they have authorization to even access that data and a lot of – and I'm sure you can attest to this, Peter – a lot of organizations don't even configure their VPNs properly. Once you actually authenticate with the VPN concentrator, you usually have access to everything behind it.

Peter:  Yeah, I mean… and usually, you even have things such as admin interfaces, and so on, available from the public Internet and then there’s someone who developed this VPN appliance 10 years ago made a mistake in some validation of input and then you have a wide open security vulnerability that people just try to scan for and exploit widely.  

Alyssa: Yeah and I want all of our panelists to feel free to just interrupt me at any time. But Keao I'm going to pick on you next. What makes managing VPN so difficult? Why are organizations having so much trouble managing their VPNs? 

Keao: Oh my gosh. I mean the – and I know Tom is religious about this as well but – you know VPNs have been around for such a long time and they are such a pain for companies ongoing. Whether you're talking about a remote-access VPN or a site-to-site VPN. You know, we initially started out with managing hardware-based virtual appliances. So, you have to manage those. You have to configure those and even once you do that, you have to configure all of the microsegmentation behind it because VPNs allowed you access to everything. But even in today's world where we have a whole complex set of users, devices and destinations they're trying to reach. You think about users applications, containers, workloads running all over the place at every part of the edge and IOT devices, right. All of those need some secure communication, connectivity and companies are using different types of VPNs for them. They could be using an SDN that they have as a provider, they might be using an SD WAN for their site-to-site WAN, they could be using a CASB provider to access their cloud and all of these together make it very complicated for organizations to manage VPNs. Not to mention the fact that employees sometimes choose their own VPN client to connect into a network. I would say the final thing that makes it a huge pain is the amount of effort you need to put into managing digital certificates. Easier when you have a small company, right? or a handful of people or a dozen people and you're managing their certificates for their laptops, but impossible when you're an organization managing a hundred thousand plus different IOT devices, people become very complicated to manage that. So I mean that's just the first things that comes to mind. 

Charl: Alyssa, sorry, something just occurred to me, you know, at the start of the pandemic, Wicus and some of my team spent some time researching VPN security. You know, in the context of now everyone's working from home and like, do these VPNs actually solve the problems? One of the things we did is we set out to define, well what is the problem, actually? What is the security problem that the VPN is supposed to solve? And, to your point about 1996, one of the things that occurred to us is that, in 1996 there was a technical threat which was really to do with people intercepting data on the wire. You know, your ISP or someone on the internet would sniff things. and like, VPNs, at that time, were conceptualized to solve that problem. And one of the things that occurred to us in examining that question was that, firstly, that actually, the evolution of the sort of VPN product space had been in response to user requirements rather than in response to the threat landscape. Does that make sense? So there was this initial security problem that we wanted to solve. People started selling it starting with Microsoft in 1996. And then, they had problems like, How do we handle the users? How do we deal with different operating systems? You know, how do we reset passwords when they're offside?  et cetera  et cetera  et cetera.  And then the kind of evolution was all along those things rather than keeping step with what the actual threat landscape was doing and, I think, in answer to your question, that's maybe another way of thinking about how we ended up where we are because, I think conceptually, the technology isn't fit for what the threat landscape looks like today anymore.

Tom: Charl, I just want to add something else to that. When you think about in fact the exact technologies that are being created today, oftentimes these are convenience types of features and products as opposed to security products. If you think about… let's just take Octa and all the single sign-on types of solutions today. What do they really do? Well, they take a federated set of permissions and identities and they group those together so you can access all of your applications through a single sign-on mechanism and that doesn't, in and of itself, enhance security. In fact it makes it less secure. So, what does it actually do in terms of security? Well, it does have this little feature where it, oftentimes, can enforce Multi-Factor Authentication, which is important. But that's it. The single sign-on mechanism is really around convenience and I think that evolution that you say has been driven by users as opposed to security requirements?

Alyssa: I think it's a great point and, you know, I love how Charl mentioned that we all… this all really started as VPN clients on the endpoint, then it evolved, you know… the fact that VPNs and evolved into one new pizza boxes and you know, what was always interesting to me over the last 20 years was how organizations are now being breached, leveraging security controls as the pivot point into the network! I can't believe that it was ever a thing! You know, and I want to say that the first time I've heard of that is, you know, I think it was Defcon or Blackout where someone talked about being able to push policy to checkpoint firewalls from the internet as a hacker, you know. Just like the idea and concept of a VPN being used to breach a network. You know, Tom, you know that just as well as I do. In 2000, I published the first vulnerability on hacking VPNs because the VPN provider hard coded the root password into the SSH binary for the VPN implants. They're just as vulnerable as a server can be, right? So, speaking about that, Tom. So, why are organizations still using VPNs today? It's, you know, we've got this concept of Software Defined Networking, we've got this concept of, you know, SDP or Software Defined Perimeter, right? And with SDP, not only do you get that secure remote access that VPNs were scratching the itch for, previously, but you also have the ability to implement software defined microsegmentation and get away from flat networks. Why are organizations still using VPN, is it “If it ain't broke, don't fix it”? Is it laziness? What is it?

Tom: Yeah, well, I think it's really, maybe there's three big reasons for this and I think one is that human beings, in general, are kind of, more reactive as opposed to proactive and I think we don't change very quickly either. If you look around your house, you may see some things that you know have existed for a long time and you really haven't thought that maybe I should upgrade that. And in the case of VPN, I think it's just been one of these legacy things that, oftentimes, is something they know they might need to change, they might need to clean that up, but it never may reach the threshold of this is going to be on the list. It needs to get done this year or this month.  So, I think that's one of the issues. I think there's also this thing where the world is changing in multi-dimensions all the time. And, you know, if you think about this first generation of VPNs, it was really having these users, as people talked about, trying to connect to a local area network. And that was just providing connectivity, encrypted connectivity transport and then as more and more applications moved to the cloud, there was this imperative to provide connectivity to those applications and services as well as on-prem.  And I think that evolution brought the advent of, you know, Cloud Access Service Brokers, SASE (Secure Access Service Edge) and those things have really helped enable people to access, again, encrypted connectivity between those applications and services. But what's missing though is tying it all together in a single, unified fabric that's peer-to-peer based and and I think that is something that we're trying to do at Blastwave but I think it's something that can help a lot of users in many ways. I'd love to hear Wicus. Kind of your take on, kind of, the Zero Trust origin and how that took so long to take off because I know you've done some research in this area.

Wicus: Well, thank you, Tom. It's quite a deep history in Zero Trust. If you really want to go back as far as the mid-2000, to where the Jericho Forum started publishing information about when they believe the perimeter –  classic perimeter, the trusted-untrusted network, is a flawed concept in the way that you can't really defend your network sufficiently against that because once you cross over from the perimeter into the trusted network, everything is accessible. And even back then they realized that there's something has to be done about that. And then as you move forward a couple of years later, people like John Kindervag of Forrester, he published his take on what is now deemed Zero Trust in many cases and this has evolved over time. So from 2010, we've seen that this idea has been propagated. Now the concepts that's used inside Zero Trust, is nothing… I wouldn't say “nothing new.”  It's just very well-refined ideas that have evolved actually, believe it or not, from the late 1980s, late 1990s. We joke and laugh about VPNs, but the idea of how they… how these tunnels are created and how these concepts are used. Proxies, for one example, firewalls or the ability to have an access control mechanism. All those ideas have just been increasing sophistication and pushed forward. Several incidents has happened over time since the Jericho Forum and since John Kindervag has published his works, but these just accelerated these things into where we are now. Zero Trust concept is actually, you know, pretty much, I think there's a lot of effort and a lot of thought being put into this, but it's a distillation of what we've already known into just practical ways of saying, “Well, break things down into smaller bites and pieces that can be managed, can be inspected, can be verified, can be rooted to only where it needs to be on a per-session basis and given access.” Now, these ideas have taken new shape and forms in product that people put forward. But I think, Zero Trust, what people need to realize, is more architecture or a model. Some call it a mindset. And I think that's important to realize that the instantiation of Zero Trust, or the embodiment of Zero Trust is just a solution that's deployed but the principles and the concepts define it needs to be applied and used throughout your deployment. But yeah, I think Zero Trust history has actually been marred by quite a lot of uptake in new technologies. SASE, like you mentioned, is one of them which embodies ZTNA, which is, you know, got Zero Trust in the name and it's all just acronym soup for many people but there is a natural progression that some of these technologies have taken towards where we are now. And I think if you look at… even if you know certain, like I said, incidents that happened over time. Specifically, now that's led up to the US federal government's published Executive Order 14028 which is the whole push towards a cyber hygiene and cleaning up on the federal agencies’ approach to using Zero Trust as a basis for their security. I think that's a big push and that's why we're probably seeing quite a lot of activity around it. But overall, I think Zero Trust has quite a lot, and like you said, it's taken quite a long time to get where we are now, actually.

Alyssa: Yeah. Well thanks so much for that, Wicus. So, I do actually have a new question for you. Before that, I want to put this out to the audience. We want this to be interactive. We want all of you to ask your questions. Go ahead and put your questions in the Q&A. We will have a Q&A portion of this discussion today. So, join in on the conversation, be a part of it. We want to hear from you. So, Wicus, I do have a question. So, more simply, where do people start on their ZT journey? Let's say, you know, we've got a CSO in the audience right now and they want to jump on the ZTNA bandwagon, where do they start?

Wicus: That is, I think, could be quite a difficult question to answer if you want to answer it accurately. So I'm going to try and shoot for a broad answer that is applicable to everybody because the short answer is everybody's journey is different. Their business is different from everybody else and, to be more specific about that is, you know what your business type is. In other words, are you a database company? Are you a manufacturing company? Are you driven by services?  et cetera. So based on your services or your mission… your business' mission, you need to choose what is important for you, where you need to secure. Ultimately, I would say Zero Trust, because it's a framework in a way of doing security, if you will, you need to get… you need to treat it as a strategic approach. It is not necessary just to secure it because if you're only going to focus on the security, you're gonna make a lot of people angry because security has always had this, what you call it, this bad rap of always saying “no” to people, not being a business enabler. But this is an opportunity to be a business enabler, to allow agility into the business. So, if you need to start your Zero Trust journey, I would just say it's like, you know, make sure what's your priority and get buy-in because this is going to be a long term commitment if you're gonna do this. This is not something that you just buy Zero Trust and deploy it and you run with it. It is something that you need to… you need to really think about it because you can add a lot of value to the business and the ability to just scale the business up quickly over time. Because businesses these days aren't just a on-prem business, right? Traditionally, you know, you had your on-prem stuff, but if you're going to really move on with the, I think the word they used these days is called digital transformation,  get into the cloud, use services… software as a service type, your business needs to be able to adapt to the threats that's there. And I think Zero Trust is positioned in a way that allows you to do that. So, if you start your Zero Trust journey, get buy-in from top executives. Make sure that they understand what it is you're trying to do. And I think another aspect that people need to realize is once you've got your strategic approach defined, you also need to do some technical work because it's not just, you know, get business to say, “Yes, here's a blank check, go and enjoy yourself.” No, that's not what's going to happen. You have to do a systematic approach of saying, “These are the things we're going to do.” Many people, many companies struggle to understand what is their asset base. What is it actually that they need to protect? How many machines do they have? How many devices they have connected to the network? Where is their data? What's the data classification? Do they have data classification? Do they actually understand  et cetera  et cetera  et cetera? Enterprises do have the advantage that they've been exposed to, you know, federal requirements, especially in America and Europe. They've got all sorts of other compliances that they need to adhere to. GDPR, for example, is just one of them. So data classification is already there. But if you're going to start your Zero Trust journey, understand that you need to first get your ducks in a row as well. Understand, you know, there's this, people talk about, get the basics right. But it is really, it's like you need to make sure that you don't have gaping holes in your environment you are not aware of. And that is, understand your assets. Understand who you want to put what. Who and what you want to protect and what is mission critical so you don't disrupt it, but you’ll actually be able to expand on that.

Alyssa: Awesome. So, Keao. I'm gonna throw it back at you. Tell us about ZTs implications on IT and OT.

Keao: Wow. So, that's a big question, you know, and kind of going back to this notion of “Castle and Moat”, right? So, security has really been driven so much from this notion of “Castle and Moat” and it impacts us even more today, right? So, before a lot of these firewall security concepts were built around this. Now, when you look at the workers, you know, they've moved not only outside the walls – we've gone from having 5% of the people work from home most of the time to 60% of the people – but this notion of even remote of a remote access is changing. It's simply access. The same thing can be said about IOT devices, OT devices. They don't live within a perimeter necessarily anymore. These devices just are out there and what we need is really to think more about the notion of just secure access for everything. Everything should be able to have its own identity. Everything should authenticate and everything should have a secure access to what it needs to reach. And it's not necessarily just thinking about reaching the cloud or a data center, It's really about granular access and in today's world, especially with containerization and people moving to different places, there's just a notion of ephemerality of just needing a connection for a short amount of time. Just between two points. It could be between two applications. It could be between a user and what they're trying to reach. All of that is kind of a long, long way to say that companies are struggling with trying to understand and plan how to secure their IT and OT assets. I think most of that comes from not being able to make a mental leap quite yet to this notion of “I need to secure everything.” Not “I need to secure this here, I need to secure this here and I need to provide secure access to the people who need it to those assets.” No, the assets, the devices, the people, their devices, containers everywhere running. All of them need to be secured and then you need to think about how you provide secure access to those. That's a big leap. But I I don't I don't see… you know, put yourself out 10 years from now in a V2X, V2V, everything-connected world where everything's running in containers at near far edge and cloud, we need to rethink really how we think about secure connectivity, 

Charl: You know, speaking of big leaps, if I could pick up on that, Alyssa. I think you were sort of taking issue with something that Peter said, which is that ZTNA is a new way of thinking about remote access and I think, Keao, you were correcting him, I think correctly so, that it's not about remote access, it's just about access. And so if I kind of cycle back to the question you asked Wicus about where you start, I would almost… Wicus reverse a step further back and say if we're going to make the kind of systemic changes to the way we architect access and if we're going to implement the kinds of systems and paradigms that are required to achieve this granular level of access, then I would almost think the place just started kind of with a mission statement, with the vision. You know, when you ask the question of this, I wanted to say, well you should start with, you know, formulating what your problem is but I almost think that even that is too technical. I almost think that the way to think about it now, given all the transformation that we have to deal with anyway, and and given Keao’s 5 or 10 years window, I would say like the place to start now is with the vision, you know, given what we've learned over the last 20 years. Let's think in a new way about how we imagine our networks working and how it will be for our people.

Alyssa: Start with the problem you're trying to solve first and then move backwards from there versus trying to immediately go to the technology. You know, it's like the same argument. It's like what happened around machine learning. It's like, “oh, all these things, like, I want machine learning,” but why do you need to know? What do you need to know for?

Keao: Even if you think about the evolution now, you know, we've gone from this, sort of, old VPN legacy world to now, a lot of VPN sort of approach is being cloud-based, where you connect to that cloud or exchange and it connects you out. That's not gonna work in the future. You don't want to connect to a centralized network to get access to others. Every single device needs to be autonomous and needs to have secure access, but it just needs to be.

Tom: I was also thinking about the evolution of computing and how the evolution of computing sits on top of the evolution of networking. You know, we used to have these big, monolithic mainframes where you had the input punch cards to get them to operate and then you broke into many computers with digital. And then you went into personal computers, then you moved into virtual machines. And now you have containers and everything is getting smaller and smaller and smaller. But fundamentally you have resources –  compute and storage – that are running programs and they need to talk to each other and the way you have “compute” talking to each other is via a network. And so this artificial distinction between IT and OT Is just that, it's artificial. Because you have “compute” and “storage” that needs to perform functions between other kinds of microservices or other sources of “compute” and “storage”.  And one of the things that we've done that Blastwave is to kind of rethink how this fundamental world has shifted in this very disaggregated way. And how can we have an architecture that can allow policies to only provide visibility and access to those “compute” resources that things should have access to. So, this is, you know, something that's very emotional to Peter and me. Peter doesn't quite share the same level of emotion as I do, because he's from Sweden, but he's definitely feeling it. And if you saw some of the language that we have in our internal slack, that would validate that position. Peter I don't know if you want to add anything.

Peter: No, I mean, I completely agree with what you're saying.

Charl: I had a question for Peter, Alyssa, if I may, Tom, just to kind of pick up where you left off and maybe put Peter in a little bit more pressure. I mean I'd be interested to hear, when you think about the Blastwave technology, like what is it that you're imagining, like how IT will work and how businesses will connect, what's the vision there?

Peter: So, the vision kind of started out quite a bit with our own needs. I've been in the software business for quite a long time and we started out with just having everything on-prem. But then we started moving on to being a distributed teams and we had all these complicated setups and routing and whatnot to actually facilitate communication between just getting software builds done. And then we had some things that were air-gapped because we didn't really trust them even to be on the same local network as other things and so on. So, I just wanted to get away from that and started building something that would really get away from all of those problems and just enable access as Keao pointed out, they're not remote access. and without having someone intervening in the middle… like some of the competition is doing.

Alyssa:  Yeah, I think I've always thought that over time the best companies and products started out with a problem that those founders were trying to solve for themselves. Because, I think, throughout history that's, you know, the best products have always started out that way versus trying to build that shiny new toy that's super cool but it's not really solving a major problem for a lot of people. So, yeah, I love that story. I'd like to take a departure away from ZTNA now and talk about Microsegmentation and that problem that SDP solves. So, you know, this whole discussion around flat networks and why we're still seeing them today. You know, the target breach where the point of sale systems were on the same flat network as HVAC. That was more than a decade ago, it was a long time ago and yet we still are seeing that same problem. I don't know, why don't we just start out… Peter, can you decompose and demystify Microsegmentation for everyone so we can all get on the same page.

Peter:  Yeah, I mean if you take it down to simple terms… In my world, Microsegmentation starts out with, you have access to nothing, then you only get access to small pieces at a time as they're actually needed. I mean, if like, what you're saying, if you have a flat network, typically a set of users have access to everything on another network, which is probably not great because there's going to be things that they don't need to have access to. So, instead, you start out with people having access to nothing and then you put users into buckets where they only have access to a certain port on a certain server or something like that. And it's also important that you tie in the identity portion of it because usually if you have a traditional VPN solution, when you look at the source IP and you might have policies set on that. But typically, there's nothing being enforced that you can't spoof that source IP and get around things that way. Whereas, with some of these new SDP solutions, your identity is tied to your IP address. So you're not really allowed to send something with an IP address that are not bound to your identity. 

Alyssa: Yeah, even in penetration tests today, I'm still seeing organizations running VPNs without Multi-Factor Authentication enforced. Tom, you brought that up earlier, and Peter, even the ones where, you know, Active Directory is tied to the VPN and it goes beyond source IP. But also, authenticating the individual with AD, if there's no MFA, we all know how easy it is to get your hands on a password dump. And Charl, I know you brought this up earlier as well and the importance of authentication but one thing I think we need to talk about is the distinction between authentication and authorization. And yeah, we're authenticating the individual and possibly even the device but what about the authorization to be able to request or access the resource that the individual is wanting to access. Wicus, Do you have any thoughts on that?

Wicus:  So the whole idea of authentication, like you mentioned, is to establish identity. To understand who is it that's claiming to be that person and normally you would have, What you know, what you have and what you are. For example, “what you know” is, passwords are so lovely because everybody has one and everybody has everybody else's password, so that's, typically, one of the weaker ones to have. “What you have” is a key, a physical device or access to something device, or to prove that you have access or control over that device. Think of your MFA device, your security key, your phone,  et cetera.  And then “what you are”, your biometrics. Typically, a fingerprint, facial recognition or some sort of analog conversion to digital space using some sort of clever mathematics to get minutia down. So, you could translate that into an unspoofable identity, if you will. Now, authorization, on the other hand, is to take your identity or that entity that claims to be or has certain attributes and then map that to a certain access path. Let's say, I need to have access to outlook. I've authenticated myself, I've proven my identity,  I've passed that. Now, I can say I want access to this outlook mailbox and then there's an access broker or some sort of identity-aware proxy in between that can say, “Well, based on what you are or who you claim to be, what you know, what you have, I will allow you to have access because your authorization is… your identity is mapped to have access to that. There's a system policy that can reinforce saying you have access to that.” Now, the difficulty with these types of approaches is that somebody can, potentially, get access to that identity, right? So, if I can get access to your identity, how can I… you know, what can I do with it? Now, It's becoming quite interesting to see that, this identity, where proxies don't just look at that identity aspect, they start looking at device state, they start looking at where you're coming from, other behaviors, other attributes about you. Not just necessarily the identities. So it's starting to look at lots of additional things around you as part of the access control. So, your access control is not purely a binary state depending on the sensitivity of the access you're requesting, let's say, getting access to just my email box is different than having access to, say, financial information. And, first of all, maybe, I do not need access to financial information so, why should I get access to that? But if I'm a credit controller or if I'm a CFO or something, then different levels of access control strength on those access control can determine, saying, “Well, you now want to get access to, let's say, sensitive board information because you want to publish Q1 financial details, you need to have stronger authentication to prove, you know… just to make sure that you know, for that session for that instance that you're busy with, you can have it.”  So, access control is very much also segmented, if you will, or carved out based on attributes of that identity that's trying to access it and it's become… and it should be a lot more dynamic than it was in the past. In the past, it's very static. Username, password and then you get this access cookie and then with this access cookie you can do stuff. Nowadays, it's a lot more trickier. If you look at Microsoft's Go Passwordless and all these other attempts at doing strong authentication. More is at stake now with regards to having that single sign-on effect that Tom was alluding to before but, at the same time, the policy enforcement point needs to be able to take that in consideration. Use the policy engine, map that through so your policy administrator can just say “Yes, access for that is granted.” or “No, you don't have access to that.” And it's per session basis, which is, I think, quite an interesting thing and I don't know how… I would like to see how people trying to attack that, especially if you look at it from a red team point of view. At the end of the day, you're gonna have quite a lot of fun trying to map all of that through and you're probably going to be very noisy if you don't do it right.

Alyssa:  Yeah, and this is why I'm so obsessed with the Blastwave solution is, you know, I'm always telling people, you know, you may leave your house and forget your wallet and not go back home, but if you forget your cell phone, you're turning around and you're going back home. You might not even be able to find your way back home because you're constantly using it for… but you know, if you're like me. But, I remember the days when you would be, you know, have to carry around that little fob, you know, the RSA securID fob, you know, and I'm so glad that everything has moved to cell phones because we always have our cell phones on us. Any time we don't, is because we just don't have… We're not in a coverage area. And so, you know, you make a great point because it's not something you are, something you have, something you know, with Multi-factor Authentication. Something you have is your cell phone and it's always on you. 

Charl: Alyssa, I just wanted to pick up on what Wicus said and ask a question maybe to Tom and Peter and this is something I'm generally not clear on. So, you raised the point of Microsegmentation and in my mind, you know, Peter took us on that journey. It's not just about access to the whole network, it's part of the network but not just part of the network. A specific host or service host and not just a host but like a specific service, right?  So, you really have that fine grain control about what on the network a particular identity can access. But then Wicus was saying, in response to your question, that authorization in the Zero Trust mindset needs to almost go down to specifying what transactions a user should be allowed to execute on certain applications. So, on Peter's server port 443 is open and there's a whole bunch of web services running there and, based on what Wicus is saying, we should be able to specify which of those web services a user can hit, but not just that, like what kinds of transactions the user should or shouldn't be able to perform on those web services. Are we there yet? Is that a problem that's being addressed somewhere in the technology stack.

Alyssa: That's a great question, Charl. We have quite a few questions that have come in from the audience so I want to make sure we make time for those. Peter and Tom, if you can just quickly give that just one answer and then I'll jump to questions.

Peter:  Yeah, I can give it a step. I mean, so we're providing… like, Zero Trust is, like Wicus tried to point out, is kind of a mindset. So it's not like something that you buy, like, one application such as Blastshield. So, buying Blastshield will give you one portion of it, but then, you need to extend it to whatever services running and so on to make sure that they are actually enforcing the transactional limits that Wicus was talking about because, I mean there's no way a network component can have that much, in that knowledge of what's going on inside of a single session. So, you need to extend it, you need, you need to have your endpoint protection, you need to have your network protection and you need to have your service protection.

Charl: Another reason why it's not a technology. 

Tom: Yeah, and one of the things we want to do in the future is consider ways to marry the endpoint and the network solutions so that we can get even finer granularity with, not just which application but, like you said, which transaction. And, you know, we're a ways from that. 

Keao: I also think that, you know, the work that the financial – the credit card industry is doing to validate transactions using Fido and Fido2, is taking us towards that, right? Being able to go through several different levels of authentication and integrating it with the transaction. But, yeah, I think it will be a journey to get there.

Alyssa: Awesome. I think it's been an awesome discussion. Let's go and open it up to the floor for questions. One of the questions that we had come in was very simply, what's the difference between Network Segmentation and Microsegmentation? Do anyone of you want to grab that one?

Peter: I would say the network's limitation is kind of based on these old school Echos and VLANs. very coarse, usually.

Alyssa:  More of a MacroV versus MicroV, obviously. VLANs and vCLS. So, I'll expound on that a little. So, with Microsegmentation, I feel like, you know, before, segmentation used to be done where you would set the default routes and the VLANs to the firewall or you would use vCLEs and you would have to manage everything at the switch level. Now, with a Software-defined Microsegmentation, where you don't have to do anything with vCLEs, you don't have anything at the switch level. A lot of that can be driven with software running on the endpoint. And, you know, obviously, the big issue with Network Segmentation was, “Okay, if we segment off this entire VLAN of machines, what if we don't know all the ports and protocols these applications are using. What if we accidentally leave a port or protocol out?” Those are the kind of things that you'd run into versus this new whole software-defined microsegmentation approach. 

Wicus: If I can just jump in there… Sorry, Alyssa, the way I visualized it is that, if you have ever seen this old-school telephone switchboards, where you had an operator literally patch you through from one cable to another cable. And that cable, more or less, we look at Microsegmentation as all these temporary little extensions from one spot to another spot as opposed to where you would have your, like you said, your physical subnets  et cetera. It's not really a flat thing which is just passively open. This is an actively controlled tunnel or session between entities communicating given access control and et cetera. 

Alyssa: Yeah, I always like to say, you know, and this is a great segue into the next question, you know. Not all ZTNA solutions are created equally and I think Tom can attest to that, Peter can. So, the big question here is, what happens in that whole, you know, the whole discussion of risk transference to your security provider? What happens if the ZTNA provider is compromised? What happens to the end user's network? Are we transferring too much risk at that point? Is there concern over, you know, being, you know… lateral movement from the ZTNA provider? Tom or Peter or someone want to take that.

Peter: Sure, I can take that one. I mean, as I said, it depends on the vendor, right? So, we at Blastwave have taken a stance that we don't want to interfere with our customers' traffic, which means that if we have a breach, our customers won't be breached because we simply don't have access to the data that's required to breach them. But some of the competition obviously have all of these cloud infrastructures where they man-in-the-middle all the traffic so they, I mean, I can't speak for them, but it seems like they're in high risk.  

Tom: Yeah. And I think it also kind of comes back to, in my mind, to this poker adage, it depends. It depends on what ZTNA solution it is, and, frankly, everybody and their brother has rebranded everything they're doing as Zero Trust now because that's hot and there was an executive order about that. So, that's why it's so important to really understand. What objective are you trying to accomplish? What problem are you trying to solve? Where are the threats that you're trying to be protected from? And, and I think, you know, there's going to be different answers for different solutions.

Alyssa: I really love this next question that came in because I think we could probably do an entire show on this. But, what are the key things to consider when an organization decides they want to implement ZTNA? What are the biggest difficulties that they need to anticipate and plan for? Can we get into that level of minutia?

Keao: Yeah, I mean, for me, you know, when you think about Zero Trust and it's really guidance right?  Like a lot of cybersecurity guidance out there, it provides you with a set of guidelines and recommendations on how to approach things. It doesn't tell you how deeply you need to secure it or the other ways that you can actually… or that you should and have to implement it.  So, I think a couple of things are important, though. One is, you need to consider how you're going to verify the identity of what you're trying to secure, you know. And you can go through something by confirming their identity with something that is more secure or less secure. So, I would say always going to something that's more, either hardware-based or passwordless authentication as opposed to MFA or a single password. And then you have to think about how you're going to manage everything and there's quite a bit of complexity in terms of managing the lifecycle of identities. And then there are all of the other systems from authentication and encryption and ensuring all of the privileged access. I think there's a lot to plan there and, I think, getting that vision right is important. And I would still go back to trying to define your overall vision and approach for just securing everything as opposed to securing access of certain things to another remote access, for example. 

Charl: But the biggest risk that I see as a sort of outside observer is that we're going to end up with a bunch of products that are branded as ZTNA. Or a bunch of compliance checklists that are, you know, branded as ZTNA. And we're just gonna end up having spent a whole lot of money on new technologies that don't fundamentally shift the needle.

Alyssa: Yeah, any other final thoughts, Tom?

Tom:  Just threat elimination. I mean, if you can figure out what's the leading threat, if you were to ask what's the leading threat that organizations face. That if they could protect against that single threat, they would be much safer and it would be – drumroll please… Credential Theft, right? Social engineering, phishing. Its credentials, right? And so, like, if you can come up with solutions that can eliminate that threat vector, you can make yourself much safer. There are others too – and we don't we obviously don't have time to go through those but that “First Principles” thinking about “how do hackers operate?” They operate on a set of principles and processes. They're not magicians. I mean, Alyssa, you did some magic, but you're not a magician. And I think you know the processes and tools that are used follow a fundamental set of principles and if we can architect our defenses around that reality, we can position ourselves and our customers much better. 

Alyssa: Yeah. Peter, do you wanna close this out with any final thoughts or Keao or Wicus?

Keao:  Why don't we go around the horn? Each of us can share a little bit of a roundup of their final thoughts. 

Alyssa: Okay. Yeah, four minutes. Peter one. We start with you.

Peter:  About this question or about this paneling? 

Alyssa: Just final thoughts. Let's kind of give our two cents. Let's close out with our two cents.

Peter:  I mean, I think this was a great discussion and I think that the topics that we covered were great. It's obviously quite hard for someone who's not really into these kinds of things to know where to start. So, I mean those kinds of questions are obviously great to have answered.

Alyssa: Awesome! Charl.

Charl:  I'm gonna go quote myself. Go back to the idea that I raised about not starting with the question of do I need this technology? It's starting with the question of, you know, how do I need my environment to work In five years and 10 years time? and then how can I use these ideas to get there?

Alyssa: Ok, Tom?, 

Tom: I would say a lot of customers that we've talked to, talk about compliance as a driver. I think what I would love to see is, the people moving towards a more more proactive mindset and think about, how can I make myself safer? What are some things that I can do to take away the biggest risks that we have? And apply energy resources to really address those issues, knowing full well that there's never going to be a clean slate. The solution needs to be something that can accommodate 30 year-old legacy devices that need to be protected, as well as modern operating systems that people are using.  So, it needs to be very strategic, going back to what Wicus said about Zero Trust, a very strategic type of process, not a reactive process based on some compliance or other threats.

Alyssa: Keao? 

Keao: You know, I would say, try to find solutions… once you identify your strategy, find solutions that are easy and practical to implement. Security can be very challenging and overwhelming but as you go through this journey, try to find things and solutions that are going to scale with your business and are actually practical for you to implement and just go on that journey. 

Alyssa: Awesome! And Wicus? 

Wicus: Yeah, I just think what people need to realize is each culture and each corporation is different with regards to how people work and how people do things. At the end of the day, security and all the things we do in the business, it's people that, you know, doesn’t and I think that you need to use your tools, use your solutions or architect your solutions in a way that actually enable those people to do their work better. We talked about earlier about frictionless access control and stuff like that, but I think, make sure that people benefit from introducing new ways of doing things. Whether it's Zero Trust or not, make sure that you get the culture that's in your business and make sure that people will buy into things that you want to do. Because at the end of the day it's a team effort into getting security, getting everything working in the way it should because it should not be hurdles. It should actually be something to make your life “just work” and everything just goes on. We shouldn't, we shouldn't architect complex systems. It should actually be less complex, ideally.

Alyssa:  I love it. Awesome. Well we've had some great points made today and as the recovering hacker amongst us, I'll part with this one last final thought. Just because it's been working all this time doesn't mean that you should keep using it. You know, look at software defined perimeters, definitely check out more information on Blastwave at www.blastwave.io. And I want to thank all of our panelists today. I want to thank our audience for attending and all these great questions. You take care of yourselves and each other. Thank you, everyone. 

Keao: Thanks all. 

Charl: Thanks everyone 

Tom: And thanks to Orange Cyberdefense.