CyberWire Daily - The current state of zero trust. [CyberWire-X]

Episode Date: May 15, 2022

According to the zero trust philosophy, we all assume that our networks are already compromised and try to design them to limit the damage if it turns out to be so. In this episode of CyberWire-X, we���ve invited subject matter experts, Amanda Fennell, the Chief Information Officer and Chief Security Officer of Relativity, and Galeal Zino, CEO of episode Sponsor NetFoundry, to the Cyberwire Hash Table to discuss all the ways to think about the solution in the modern era: Software Defined Perimeter (SDP), Secure Access Service Edge (SASE), identity and authorization, and private WAN, all through a First Principle lens. Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. Hey, everyone. Welcome to Cyber Wire X, a series of specials where we highlight important security topics affecting security professionals worldwide. I'm Rick Howard, the Chief Security Officer, Chief Analyst, and Senior Fellow at the Cyber Wire. And today's episode is titled, The Current State of Zero Trust. A program note, each Cyber Wire X special features two segments. In the first part, we'll hear from an industry expert on the topic at hand. And in the second part, we'll hear from our show's sponsor for their point of view. And since I brought it up, here's a word from today's sponsor, NetFoundry.

Thank you. They network in minutes across anything, directly in your app or on any device or in any cloud. Using NetFoundry allows us to close all inbound ports and link listeners, stopping external network attacks, including DDoS, brute force, CVE, and zero-day exploits, while saying goodbye to complex firewall rules, inbound ports, public DNS, static network access controls, and VPNs. All you need is commodity outbound internet for any use case across multi-cloud, IoT, remote access for users, operations or developers, and APIs. Get started with free forever tiers using the NetFoundry SaaS application at https://netfoundry.io slash cyberwirex. I'm joined by Amanda Fennell, the CIO and CSO of Relativity

and host of her own podcast, The Security Sandbox, that is part of the Cyber Wire Networking podcast. Amanda, thanks for coming on the show. Thanks for having me. Let's do it. Welcome back. Today, we're talking about zero trust, and it occurs to me that most of the security

vendors have glommed on to that phrase as a way to sell their product, so much so that it's kind of lost its meaning. But just because the vendors have taken control of the narrative doesn't mean that zero trust isn't a good idea. So where do you fall on this? Is this a purely marketing phrase that has no meaning or is it essential to your own internal security program? Oh man, this is the moment. I wish you could see I'm smiling at this one. It does come up so often. I use the same like kind of relationship here with the term like world peace. often. I use the same kind of relationship here with the term world peace. It's still a great idea. It's like, yeah, we should do that. It's still important. We should do that. Don't deny that just because people use it all the time. And it's like saying, I love you to my husband,

right? I don't love you less because I say it all the time, which I don't. So you're right. It's been overutilized, but I do fall in the same place as you do. Adopting a zero-trust mindset is critical. It's the hybrid working model that we use at Relativity. It's an important component to keep this new digital fortress secure. We no longer have that moat situation that we can easily defend. So it does really help us to provide users with just that bare minimum. And for all our CISSP heads out there, that role of least privilege and things like that,

it does allow us to do that and to accomplish the mission they need to and to contain any potential compromise. Who's going to argue that, right? This is a different perimeter these days. It's not traditional. We can't let it be lost. Just like, what was it, five years ago or so, 10 years, disruption. Ooh. Ooh, yeah. Ooh, that was the word, right? Another word that we overused. Another word. A main theme of the original John Kinnarvog Zero Trust white paper, you know,

geez, it's over 10 years ago, is that we should assume that our networks are already compromised and try to design them to limit the damage if it turns out to be so. And I get a lot of pushback on that. Is that a realistic design scenario or is there something else we should be trying to do here? Yeah, I mean, you know, this is where it's hard. Us security people get a bad rap that we're always assuming the worst, right?

Assume you've already been breached. You know, this whole dynamic. Yeah, you know why? It really helps you start to build things from a good perspective if you just assume the worst and then hope for the best. And I think with a zero trust mindset, the design scenario is applicable.

You do need to assume that everything could have the potential to be hostile until you verify it. And that's why we say things like the trust, but verify saying that, you know, insecurity, we love to say that, but I think it is still the right perspective and it is the still the right design scenario. That doesn't mean you have to come across with a lot of negativity. You know, we're not having to be the active bouncers at a nightclub situation. It's just having the tech do that for us. Well, I mean, in context, you know,

you wrote the paper, like I said, over a decade ago. Back then, we were doing perimeter defense. We thought we could keep everything out. We'd build this electronic fence around everything important, and then everybody would stay out. But John, when he wrote the paper, he said, we need to reverse that thinking. I think he anticipated our networks would be scattered in, you know, just a few short years. And if you assume that it was going to be bad, then you would design it completely differently than if you're trying to put that electric fence out there. Is that what you think it is too? Yeah. And I think, you know, you mentioned how long ago he used the white paper that this came out. Look, you know, Lockheed Martin, Kill Chain, 2008, I think, is that original timeframe.

So we're looking at 14 plus years ago whenever this concept still came out. Guess what? Still applicable. So I think that you have every once in a while these great thinkers in the industry who come up with a concept like this that really is one of those pillars that should stay there

and it should be the way we do it. So for relativity, that means that we operate under that assumption that no user, no link, no application should inherently be trusted until we do verify it using our own systems and processes, which is super useful because it goes back to the pillars of tools, process, people. And if you've created your whole program with that,

zero trust really well, it folds right in there. It's about've created your whole program with that, Zero Trust really, well, it folds right in there. It's about making sure your people are educated on what it is, that the processes reflected and the tools are in place and the tech is in place to help you enable that. So I think you just got to use the security fundamentals to keep it going and keep it strong. So let's talk about that because before we can get to any kind of robust Zero Trust program, we need another kind of robust program, an identity and access management program. Do you guys build that yourself with no commercial help or do you use commercial tools or some hybrid? How do you guys think about that?

This is like my favorite topic these days. I am, it's my favorite topic. So the Spider-Man reference, right? With great privilege, with great responsibility, great strength, all those things. So we know that we have access. Wait, wait, I am so glad that you brought Spider-Man up. Okay. That's right in my wheelhouse. So go for it. How do we not? You know, it's so important. I think the CIA got it from Spider-Man from the comic books originally, Stan Lee. We know we have access to a lot of really important data for ourselves, for our

customers, for our partners. This is really important. We take it very seriously, and it's also an honor and an obligation to really have this opportunity to protect this stuff. So making sure that the right people access it at the right time for just the amount of time that they should is absolutely where we get our IAM programs. You asked a couple questions that were pretty tactical. Yes, our IAM team is built into our larger Colder 7 security team. It was created in-house. It started a couple years ago when we first moved to the cloud. It was a guy who really liked cloud stuff. The one guy. That one guy, right? He really enjoyed it. And we were like, we think this could be something.

We can make this a role for you, right? So he builds out cloud security team. Then he starts to build out that we need an IAM team. Then he starts to develop a security development team with it. And it all goes together because you got to develop new tooling at all times to really make it fit what you're trying to do in-house. So some of those tools we do create ourselves. Some we leverage external.

I don't think it's a big surprise we're a huge Azure involvement. And Azure actually does a pretty good job with helping us to build some of our own tooling on top of what they do for a lot of the IAM stuff. So yes, it's a little bit of everything. I feel like I'm in the kitchen. I'm throwing a little bit of salt and pepper in here.

I got a couple other ingredients that are coming in. I like to leverage what's already in place. I like to create things that are detailed and created for our particular needs. And what we found most useful for doing all of that is that you just can't do 100% any one of those things. It is slivers of the pie that come together. And one of those things I just can't walk away

without mentioning since you brought up my favorite topic is people love to throw automation at IAM. And if I could give any caution to people out there to learn from the things that we had to learn over and over again and fail faster and fail better at is just because you automated it doesn't mean that you also automated going back to check for those stale permissions and to check that the automated permissions are being taken away on time. So we had to really work on that tooling. You're right. Cause we, you know, we spent so much time trying to convince everybody to automate these infrastructure as code processes. And, and it was such a hard job to get people to start that we never really went back to them and said, well, that's good to everything in there. Now that you're doing it, let's do some of the right things. Is that what you're saying? Make sure we

do all those back-end processes that makes it all secure. I think that's the biggest thing that we always try to do with our team is that we know that we're really good and we're very proud of a lot of things we've put together. But if anything, we wish that we could help teach people some of the things that we had problems with so that they could avoid it. And that was one thing that we put in all this great automation, but we had to go back and then say, wait, wait, wait, wait, wait, we also have to activate some automation to go behind the automators. Who watches the watchers? But yeah.

So there's really kind of two architectures for identity and access management programs. One is you, the user goes right to the workload and says, hey, I'm who I am, let me in. But the other one that most people don't have but i think is a better architecture something called it's horribly named by the way it's called software defined perimeter but instead of going to the workload you go to some other thing log in there and then that thing does the negotiations to get you to the workload and only that workload do you see more and more people using it and are you guys using a software defined perimeter approach? Some are not. So I think that it's where there's no, I hate to say like, it depends. So sometimes we do. Yeah. Every time. Yeah. Every time. So this is where you got me into a corner in the

conversation, right? Like you got me through all this way, but now it's at the point where, well, I don't want to show all my cards. This is a how to then then. But I will say that, yes, when applicable, I think it's the right thing to use. I completely can acknowledge that one. It is not 100% in any direction for the way that we've deployed things. And so, because I think that in some cases that works and it is the most

available, solid security and mitigation and the way to approach this. And then there are other times that it's just going to slow things down in that particular way. And that median time to a resolution of things is just, it's too important. So it comes down to the real question of when people use one model versus another, it has to start with, and I hate to simplify this, what are you solving for? Right? Are you solving for speed to access or are you solving for security first? Sure, you're all going to say security first, but the business is going to say something different, right?

And what I would like to say is that whichever model it is that you decide to deploy, our job in the security realm is to let the business do the thing and to have them accomplish the thing and whatever they're solving for, comma, securely. That's it. I like the way you say that. Comma, securely., comma, securely. That's it. I like the way you say that.

Comma, securely. I like that. Comma, securely. Well, one of the future architectures that is on the horizon for us is something called SASE, Secure Access Service Edge. And I know both you and I are big fans of this. So does SASE make this identity

and access management idea easier or will it make it harder for us in the future? I think, oh man, I really, it's so cliche, both. Here you go again. And the reason why is because I think that the way that it's currently deploying and the way that people are using this for this secure access service edge,

it's wonderful in the way that this captures network and security coming together. But I think that in order to do this the way that people really want to do it effectively, you have to have all of the ingredients. And not everyone's environments lend themselves to that. For example, CASB is a great example. CASB may not be the way that we are set up

if you're in a Palo Alto environment. That's not the way that they do that kind of security and perimeter and so on. So I think that it's in the middle of becoming more mature right now. It came out, made a lot of sense. It's very smart to deploy and to use this. But the problem is if you don't have your dance card

filled with all of the different boxes you need here, we're having to learn how to do it differently. So it's the right concept. I think it's the right thing to do, but we are having to augment it and mature differently. Well, it's like many things in our security space. You're doing a river crossing, you know, you're moving to a new thing, but you still got to maintain all the old things before you get there, right? Now you made it more complex, even though you're moving to a thing that's going to make everything less complex somewhere in the future. So that's the problem we all have, right? I think so. And I think there's also always the thing that whenever we decide a strategy or buy a tool, there's always this feeling of like, okay, well, how long until I get value from that? What's the timeframe for me to get some value? And that's the struggle some people are having

right now. I think with Sassy is just that, well, it's Sassy. It's not so simple that way. You can't just say, cool, we're going to do this. This is the new strategy. We're running in this direction. You're going to have to, just like I am, tailor it to your own needs and what you have and what you don't have. And that's where people are doing the work right now. And I think we're gonna see some great stuff come out with people who are gonna publish some more white papers on this and some of the struggles they themselves

have gone through with it. I know that's one thing that we're working on too. So it's like you build a sassy environment and start to move things towards it, but you still maintain what you're doing and pick the most obvious things that make it easy and get some wins there and then

figure out how to do it in the future. I think because people approach a lot of these things differently. What are they doing about DNS and the way that they're doing it? Yes, you keep those things. Look, people, I told you as a joke earlier, my sound, I had to be careful about it because there's people doing work outside, right, on my house. But in order for them to replace the column with this new column I need, right? They had to put two braces up on each side of it. You can't just put this new column in. You have to brace what you have in there. You got to make sure that it's working and it's still going to hold everything together until you're ready for that new one to take over. And then you'll take away the two braces that are

fixing it. So it's a process. And I think I see the same thing with the sassy stuff. Like you said, keep the old until you're ready to move on to the new, but you're going to have some duplicative things that are going on for a little while. Well, Amanda, as usual, really good stuff. But unfortunately, we're going to have to leave it there. That's Amanda Fennell, the CIO and CSO of Relativity

and host of her own podcast, The Security Sandbox Podcast. And you can find her show on the Cyber Wire webpage. Amanda, thanks for coming on the show and sharing your wisdom. Thanks for having me. I love it. This is like my second Zero Trust podcast episode

I've been doing lately, so I'm excited about it. It's on your mind. I get it. Thank you. Next up is my conversation with Galil Zeno, the CEO of NetFoundry. Galil, thanks for being on the show. Rick, pleasure to be here. So no one can doubt that the state of the current InfoSec environment is one of steady improvement.

I mean, you know, we've come a long way from the perimeter defense and defense and death models of the 1990s. And yet it seems that the number of successful cyber attacks keeps growing. You and I are of the same mind about this. If we as a community are to reduce the volume of successful cyber attacks,

we all have to get back to first principles. So I know what I mean by that. So can you tell me what you mean by getting back to first principles? Yeah, Rick. First of all, great. We've made a lot of progress. But then again, talking about first principles, the surface area for attacks is massive compared to a year ago, let alone five or ten years ago. The blast radius, Rick, for these attacks, the severity and consequences of these attacks,

right, from a first principles perspective, that's where we focus on. How can we, for our customers, our users, and by the way, our users are developers, they're operators, DevOps, NetOps, they're security teams. How can we enable them to reduce the surface area of the tech? How can we enable them to reduce the blast radius? How can we enable them to mitigate? We're not going to win this whack-a-mole game completely, but how can we do better? As you said, Rick. I really liked the way you call it the blast radius, because, you know,

when I started doing this back in the, you know, dinosaur days, we only had one perimeter and that's where all the data was. And like you said, today, data is all over the place. I call them data islands. We still have endpoints and data centers that a lot of us run, but we also have mobile phones now and we have cloud services. We have SaaS applications. I was just doing the security assessment of CyberWire today. We have, you know, over a hundred SaaS applications that we're running. So data is everywhere and it's become so complex, right? Yeah, I agree, Rick. I mean, listen, when the app is the new edge and it's like massively distributed,

then how do you better secure both the attack, the surface area and the blast radius and do so in a way that like you're not compromising your business, right? Like business velocity, automation, portability, extensibility, scalability, like just as or more important today than ever before. So I kind of see it like it's this kind of dual issue, Rick, right?

Like security plus business velocity. So talk to me about this business velocity thing. I think many security practitioners don't really have a hand around that or understand what that means. So what do you mean by that? Yeah, I think, Rick, there's this perceived tug of war, if we want to use a quick metaphor, where on one side of the rope is a security team.

And okay, maybe it's just one woman in an organization. Maybe it's a full department. Maybe the folks are distributed. But either way, you have some folks in an organization. They're kind of tugging on the security side of the rope. And on the other side, you have developers, product folks, architects, DevOps, automate everything. You have these forces on the other side of the rope that, of course, they want security, but they need business velocity. If they are going to serve their customers with excellence, deliver an awesome experience to their customers, continually innovate, they can't compromise automation, agility, velocity. And so we have this perception of this tug-of-war, Rick, although, interestingly, I think it's a little bit of a false perception because we do believe that there's some enemies, so to speak, that are common to both the need for security and the need for business velocity.

Yeah, I agree that the perception is definitely there. If a business decides to invest resources into fully throwing down on DevOps and DevSecOps, they don't want the security team to slow that down. You know, all the benefits you would reap from 10 deploys a day and all that stuff, if you're going to not get that because the security team doesn't respond to that or doesn't let you go fast like that, then why do it? But you're right, I think that's false. I don't think that's really happening out there. It's just, it's a perception thing.

Is that what you're saying? Yeah, it's a perception thing. And I think there are common enemies. We usually circle three, actually. Common enemies of both security and velocity. If I kind of go from granular to less granular, IP addresses, enemy of both security and velocity. Firewalls, enemy of both security and velocity. And the network, specifically in private land constructs, network architecture, also an enemy of velocity and security. So if we can eliminate those three things, we help both, right? We help you simultaneously get better business velocity and stronger security. So they're enemies

to both those things because you have to slow down to configure them. You have to decide what a good IP address is and what a bad IP address is. You got to configure the firewalls and you got to do all those things. You're trying to figure out a way to get that done more quickly? Yeah, exactly. So as I mentioned, we serve three types of users, developers, operators, and security folks. For security folks, that's fairly obvious. We're going to do secure by design.

We're going to make things more secure. For like an application developer though, if they never have to worry about symmetric NAT, asymmetric NAT, firewalls, hole punching, turn servers, bastion host, VPN, NPL. If the developer never needs to worry about that again, they're very, very happy, right? So we enable them to kind of get those network constructs

out of their vocabulary, so to speak, or at least so that they're not dominating their work. And then same thing on like the DevOps folks. Like our DevOps folks, they say all the time, we need to automate everything. And what are the things they can't automate? It's like what you described, Rick. It's like firewall rules and ACLs

and certificate management on bastions and VPNs and MPLS. So they're enormously happy if we can do things like get rid of IP addresses, firewalls, and WAN constructs. So yeah, that's where I see the merger, if you will, Rick. So in a DevOps world or a DevSecOps world, that infrastructure as code, is it handled for the developers?

They don't have to worry about it. They could just write their code and they don't have to worry about screwing anything up. It just kind of happens for them. That's what we're trying to get to. That would be nirvana. That's it, right? I think, Rick, that's the definition to me of secure by design, right?

It's like it's secure without you or me having to worry about it. The security is put in there, so to speak. And obviously, it needs to be auditable and traceable. We need instrumentation and visibility and controls. But as you said, Rick, it's not what you and I are doing. You and I as the developer or the DevOps person or security person, we're just working to deliver the best experience to our customers. So we're going to get this by automating a prominent strategy these days called Zero Trust. So let's talk about that. That idea got started in the early 2000s when the U.S. Department of Defense Jericho project tried to make something happen.

Nothing really materialized from that research. 2000s when the U.S. Department of Defense Jericho Project tried to make something happen. Nothing really materialized from that research. But in 2010, two things happened. John Kindervog wrote his seminal white paper on zero trust, and Google got hit by a Chinese cyber espionage attack that caused them to redesign their network from the ground up using zero trust principles. You know, you and I have been talking about this. Here we are over a decade later. Most security practitioners that I talk to are nowhere close to running a mature zero trust program. And they're pretty tired of security vendors claiming that they have a zero trust solution to buy off the shelf. It seems to be the buzzword of the last five years or so. And I got to tell you, just this week, I followed a

Twitter conversation with a gaggle of CISOs that I admire. And at least half of them were saying that Zero Trust is just too hard to do. That the amount of effort it takes to establish a Zero Trust program is not worth the security benefit. I don't agree with any of that, but that was the gist of the conversation. So if I was going to put Zero Trust on the famous Gartner hype cycle, I would say that Kendra Vag's paper was the technology trigger and the idea traveled through the peak of inflated expectations sometime around 2015 or so, but it's been spiraling down

through the trough of disillusionment ever since. So you're a zero trust company. What do you say to your potential customers about that? Have we hit the bottom of the trough and are now just moving up the slope of enlightenment? Yeah, there's a lot in there, Rick. I know. There certainly is.

I mean, you know that game, Rick, where if I say something, then something good or bad happens depending on what I say? You know, we try to play a version of that game where we try not to say the blank trust word because it's become a marketing flaw. We're immediately turned off by somebody saying that now. Yeah. The journey is difficult. Of course it is. But like the marketing journey is, I don't know, there's really great marketers out there and they've commandeered the word.

And now we're zero trust washing, like we cloud washed or AIML washed. It's become a bit ridiculous. But Rick, if we take it back to first principles, if you look at the KinderVag paper you referenced, if you look at the Google BeyondCorp architecture, which I believe you're alluding to, if you look at software-defined perimeter, which in some ways was the word given to this before zero trust was commandeered by the marketeers. The first principles there, identity, authentication, authorization, least privileged access, right? It comes back to our start of the conversation in terms of by design, reducing the attack surface, reducing the blast radius. I think if we can throw all the marketing stuff out and just look at like use cases

and look, as you said, at the journey and what we need to do, because the North Star is great. Like we all agree on the North Star, right? How do I get to the North Star? That's maybe a more interesting question. I know, and that's what my peers are struggling with, you know, is what's the path to get there?

In that CISO Twitter conversation, the naysayers weren't wrong in that implementing a robust zero-trust program is hard, mostly because you have to be able to do DevOps and DevSecOps and the automation of security orchestration. This is a muscle that security practitioners don't necessarily have. You know, we really haven't been tasked to do that job.

But your company is involved in an open source project designed to improve that situation. In fact, your commercial products are built on top of that open source code. It's called OpenZiti. Is that what it is? It's spelled Z-I-T-I? What is that?

OpenZiti. OpenZiti, like the spaghetti. Yeah, yeah, it tastes good. Don't Google Ziti because you'll find out you'll get hungry if you haven't just eaten. But yeah, Google Open Ziti if you want to. What we say, build in or maybe bake in if we want to stay with the pasta analogies. You know, bake in security, build in security by design. in security, build in security by design. We take an open source-based platform approach because, and I know platform's overused here, but platform in the sense that we enable builders,

makers, operators, we enable them to build things on that OpenZD platform that are secure by design. So you have a proxy and you want to make it secure by design. You can use OpenZD platform that are secure by design. So you have a proxy and you want to make it secure by design. You can use OpenZD. You can insert some code into your proxy. You can make it secure by design. You have an IoT application. You have a web browser. You have a backend database, right? With our OpenZD platform, whatever you have, and I think this is really important for the journey, because you can start anywhere. So you have a new edge cloud IoT project, start there. You have a new greenfield application, start there. It gives you that type of flexibility, Rick.

And at the end of the day, we believe that the paradigm shift here is, if you're just trying to bolt on, quote unquote, zero trust, if you're just trying to make your network more secure, something that's inherently not secure, right? Networks are made to deliver packets. If you're just trying to make that thing more secure by bolting stuff on top, well, good luck to you. That's going to be a long journey. And all the times I've tried to do that, I can tell you that has never worked. Okay, so yeah, I'm with you on this. Go ahead. Yeah. It's tough, right? I mean, listen, we have a lot of clever engineering and good technology, et cetera. Don't get me wrong. It's just,

it's just, you're starting from something that's inherently not secure and that is really difficult. So what we kind of say as well, what if you could build it in? What if you could build it in to your application? What if you could build it into your service or use case, your remote management tools, your actual use cases? And what if you could build it in a way that's not going to cause you to forklift everything

else? I don't want to necessarily touch the underlay networks. I don't necessarily want to touch an adjacent use case. I might not want to touch another user group or another cloud or another edge. What if I can take a more modular approach to this, kind of build zero trust in a way that matches my business partners? Well, that's cool. And that's the idea of both OpenZD, which is the open source and the NetFoundry, is essentially the hosted version of that, the SaaS version, the easy button version.

Either are great, depending on what you need to do, what you need to accomplish. So it sounds to me that we may have hit the bottom of the trough of disillusionment and are starting up that slope of enlightenment. Is that the main takeaway today? I hope so, Rick. We're standing on the shoulders of some giants that you mentioned earlier. So we can hope. And, you know, I said the other way, are we really going to be successful in kind of a hyper-connected, like massively distributed world? Like that whole kind of digitally transformed world, it's all built on this kind of assumption of secure networking. So we really do need to get it right. And I believe we're making progress to do so.

Well, it's all good stuff, Galil, but we're going to have to leave it there. That's Galil Zeno, the CEO of NetFoundry. And thanks for coming on the show. Rick, my pleasure. Thank you very much. That was Galil Zeno, the CEO of NetFoundry, and we'd like to thank Galil and Amanda Fennell, the CIO and CSO for Relativity, for helping us gain a bit more clarity

on how to think about zero trust. And finally, a special thanks to NetFoundry for sponsoring this show. CyberWire X is a production of the CyberWire and is proudly produced in Maryland at the startup studios of Datatribe, where they are co-building the next generation of cybersecurity startups and technologies. Our senior producer is Jennifer Ivan. Our executive editor is Peter Kilpie.

And I'm Rick Howard, signing off. Thanks for listening.