Token Security Podcast | Harry Sverdlove Co-founder and CTO of Edgewise Networks

‍About This Episode

Justin McCarthy has an in-depth chat with Harry Sverdlove, Co-founder and CTO at Edgewise Networks. They talk about how network security is going through an evolution and is ripe for change right now, as well as a pragmatic look at the past, present and future of firewalls and their cousins.

‍Listen to the podcast:

‍About The Hosts

Justin McCarthy

Justin McCarthy is the co-founder and CTO of StrongDM, the database authentication platform. He has spent his entire career building highly scalable software. As CTO of Rafter, he processed transactions worth over $1B collectively. He also led the engineering teams at Preact, the predictive churn analytics platform, and Cafe Press..

Max Saltonstall

Max Saltonstall loves to talk about security, collaboration and process improvement. He's on the Developer Advocacy team in Google Cloud, yelling at the internet full time. Since joining Google in 2011 Max has worked on video monetization products, internal change management, IT externalization and coding puzzles. He has a degree in Computer Science and Psychology from Yale.

About Token Security

At Token Security our goal is to teach the core curriculum for modern DevSecOps. Each week we will deep dive with an expert so you walk away with practical advice to apply to your team today. No fluff, no buzzwords.

Transcipt:

Justin McCarthy  0:26
Hey, this is Justin from strong dm, and welcome to this week's episode. This week. We've got Harry Sverdlove, founder and CTO of edgewise networks. And he's going to talk with us about firewalls. So, actually, hey, hey, Harry, how's it going?

Harry Sverdlove  0:42
Good. How you doing? Good. Good to speak with you, Justin.

Justin McCarthy  0:46
So the the first question I have is just is just about you. So can you tell me just the quick version of what of what edgewise is and what your role is?

Harry Sverdlove  0:55
Sure. Absolutely. I've been in security for move Yeah, let's say two decades, maybe three decades and was formerly CTO for a company called carbon black. Three years ago, I left and founded edgewise networks. And our goal is to solve the problems of communications and securing communications and data centers and cloud environments.

Justin McCarthy  1:14
Great. That's, that's very helpful. So so because here on the on the token security podcast, we try to introduce topics that are pretty universal, but maybe topics that are also changing. And one of those topics that's definitely changing right now is firewalls. So if you look back a couple years, or a couple decades firewalls look very different than how they look today. So that's, that's the topic and so that my actually, first question, the first thing I'd like to discuss is just the origin of the name itself. So there's a physical metaphor in here, do you? Do you know anything about the origins of the name?

Harry Sverdlove  1:54
Well, I know that has been widely distributed if you go back to what was it, I think it was hackers, the first movie to actually make that term hit the mainstream was when they used to call it a firewall. But the actual term terminology now I'm afraid I don't,

Justin McCarthy  2:11
well, you know, I'll say I don't know either. I just know that every time I'm down wrenching on my car, I'm, I'm always aware of when I'm punching through the firewall. And then I always give it I always chuckle and then whenever I'm thinking about looking at a plan for building of course, those have firewalls to your to prevent propagation of fire

Harry Sverdlove  2:31
right, when the concept obviously is very much the same. So, you know, certainly almost certainly derived its origins from physical firewalls, but he got his claim to fame because of Hollywood.

Justin McCarthy  2:41
Yep. Thanks. Thanks. Great, great movie. Of course,

Harry Sverdlove  2:46
same with the cloud. I suspect to that. Yes.

Justin McCarthy  2:48
So going back in time firewalls were absolutely hardware devices, but they were always physically separate from switches and routers. So can you tell me a little bit about why that may have been? Why if you were working on Cisco product line, and in the in the 90s that thought you thought of that as separate from routing, for example,

Harry Sverdlove  3:07
what do you think about what a network is networks, all about? facilitating interconnectivity, facilitating communications so you have switches and routers that are all about making sure your traffic can get to point A to point B. This idea of let's introduce security really was an overlay on top of the physical infrastructure. So you have this set separate thing where people got together say, you know what, maybe we should actually put the thing of it is tollbooth so my highways first I built the roads, then I built the totals.

Justin McCarthy  3:36
Yep. And then there must be there must have been a different problem as well. Just in terms of the physical requirements, I imagine. Because, you know, you're, you're, you're asking different questions with firewalls. And actually, I think, to my Linux or my Mac workstation here, you know, they have firewalls, but they're obviously software. And and they are, and they're very much about configuring public use. So can you talk to me just a little bit about some of the differences between sort of a network firewall, you know, let's say, a rack mount piece of gear, and what I'm going to see on my workstation, or may individual host

Harry Sverdlove  4:16
Sure, I mean, if you can actually break it down into GIFs physical or wire-based to firewalls, and you have host-based firewalls, and then you can go a step further with the physical ones and say, You went well physical ones, and they can be virtual as well, when you start talking about things like the cloud or environments where there aren't physical wires. And if you think about what a firewall is, you know, again, back to that tollbooth metaphor you're looking at traffic on the wire. Now, how deep you look that we can get into that sort of the evolution of how smart firewalls got. But you could only make decisions based on what you see going the wire a host-based firewall, while you're sitting there on the system, starting that communication. So you can be a little more specific, you can make decisions based on who's making the communication or who's receiving that communication on the wire, you really have to infer that and there are different ways to do that. But you're still limited, kind of like, think about it. Another way to think about a firewall is imagine you're sitting at the bottom of the swimming pool. And you're looking up at where is that swimming pool, that water, that's the network, you can see shapes of things go by, but they're kind of blurry. So you can't really know Oh, yeah, that's Justin walking over there, you kind of think it kind of looks like Justin, a host-based firewall is sitting above the water making a decision at one point in time, a network-based firewall is sitting in the swimming pool.

Justin McCarthy  5:35
Yeah, that's a, that's a great metaphor, I, I totally can see that I can see that perfectly in my mind.

You know, one thing I observe about network-based firewalls is that many of the policies or all of the policies are essentially expressed in terms of those vague shapes, basically, source and destination. And I think that trades on an assumption about essentially the difficulty to spoof those packets of the source and the destination. So I guess it's 2018 now it's about to be 2019, how, how concerned is anyone in the security industry about the strength of the, in the validity of sort of packet origins of destinations?

Harry Sverdlove  6:23
Well, I think, you know, and it made sense once upon a time now, by like, firewalls have been around think the first one was 1988. So we're talking 30 years now, at this point, that that sort of form factor in that technology came about in those days, sort of two things were true. One is there actually were physical separations of networks, Seattle, you know, your office network, and you had a different office network, and then added different physical separation, you remember token networks and ring networks and all that fun stuff. But the other was that these addresses were somewhat persistent. It kind of again, going back to metaphors. Think about it this way, you have telephone numbers of people have your but nobody actually knows telephone numbers today. So that our phones basically just have an identity, they have a name, and oh, I've got a call from Justin today. But once upon a time, when there were a limited number of phones, and a limited number of phone numbers, I just remember the phone number. It's the same thing with firewalls, when you're dealing with Packet Inspection if what you're seeing in the swimming pool is packets. So you seeing x source address, destination address, maybe destination port protocol, you can do a couple other things. But that's how you have to make your decisions now that you're dealing with this idea of.

First of all, a completely volatile network. So maybe your addresses in a coffee shop, maybe you're at work, maybe you're in China, maybe you're traveling so your address no longer is stable, and there are no longer perimeters. So now you have one cloud service talking to another cloud service addresses are changing all the time. So when you're dealing with a form factor, we're all you have this packets Yeah, you're really limited into what you can do or you're and you're going to end up being very grossly over permissive. Everything that starts with the address, you know, to, to, to, it can communicate with everything starts with the address 333, which of course, now it's great for facilitating communications, not very good for security.

Justin McCarthy  8:11
Yep. So. So I think that very distributed very, in some cases, even femoral environments, that the coffee shop talking to AWS bouncing through to the surface and Azure, that that that is definitely a very familiar aspect of modern life.

I will before we get there, though, I'm actually interested in going sort of laterally to a few firewall cousins, and I say, cousins, because these definitely aren't quite firewalls, but they, they're, they're asking some similar questions. So the first one is, you know, intrusion detection systems. And then another one is what are called, I guess, web application firewall. So these are very much I guess, you call it to layer, seven application layer, sort of, like semantically aware, in Spectres of traffic. So how, how are how are those concepts relevant still, and, and, and actually, how might their implementations be similar or different from just sort of the network level isolation,

Harry Sverdlove  9:15
right? So until we go back to firewalls, and imagine, remember, now, all you've got as these packets, that's what you're inspecting things like web application firewalls, they breathe new life into an older technology. And the way they do that is they rip open the packets and they say, okay, does this at least for the conversation I'm looking at, does this look like a legitimate conversation in this specific case of a web application firewall, they know, okay, this is talking to Port 80, or Port 443. So it's talking to a web server. And I know what when talk sounds like, you know, imagine somebody monitoring our conversation, I know what English sounds like. So I'm going to look for bad words, I'm going to look for bomb or I'm going to look for some, you know, terrorist. In the case of a web application firewall, the equivalent would be, I'm going to look for some malformed packets, something that looks like it might be a SQL injection or cross-site scripting. And this looks like a bad conversation to me, I'm going to block it. So they take, you know, again, there's still dealing with packets. But they're taking that and giving it a new life by saying, Let me open up those packets. Let me put them together. And let me see, does this look like a reasonable conversation between a client and a web server in case of IDs, they can do other things to like, let me look at the patterns are these coming from either bad known addresses? Or do I see a pattern where a conversation keeps happening over a number of different addresses in a short period of time, or a number of different ports. So I'm looking for example, in that case, for a denial of service attack, or I'm looking for patterns in the water that I know are highly indicative of something bad. And both cases whether it's IDs, web application, firewalls, UT, and other different variants, it's all about, let me take a look inside this fuzzy conversation I'm looking at and see if I can look for patterns that either look bad, whether they don't sound like they should be the things that are talking

Justin McCarthy  11:04
and all of those implementations. If we sort of if we imagined the very sort of hardware amenable use cases of just straight packet Routing and Switching. And then we sort of imagine how you might implement some of these some of these more semantically aware rules, I'm assuming that there's essentially there was never a WEF that was implemented in hardware like we're we're to the point where we're pretty much everything we're talking about here is like, this is software.

Harry Sverdlove  11:30
It is software, although I mean, the fine line between I guess you could get philosophical, all hardware and software at some level, suppose all software could be hardware at a really atomic level. But they do have, you know, you can buy a physical hardware device that implements laugh rules in hardware, it's just you still need for that purpose, you need to have the problem with physical is you physically need a wire I need we're, nevermind whatever networking is, I need to find I need to find the source wire, I need to find the destination or at least a throughput a choke point. And I need to bleed all my traffic through this when you're an example, if you're in a coffee shop, going to AWS going as your where's that wire? And and that's often why we end up in a software form factor now.

Justin McCarthy  12:20
Yeah, absolutely. I'll say that the notion of network device capacity made a lot of sense when you could think about it in multiples of wire speed. And you can think about what, what the bandwidth was. And, and, and sort of all of that gets blurry when you have when you're relying on some hardware optimized network capabilities of your cloud provider. But that other stuff is pure, you know, Gen CPU application layer throughput. Absolutely. Yep.

Okay, awesome. So, so that. So that brings us, I believe, actually up to up to pretty much the cloud generation. So so.

Justin McCarthy  13:01
Yes. So one thing that I noticed as I move between the major cloud providers is that the nomenclature is all slightly different. So you have security groups, in one case, you have things that are formerly called firewalls and other places, and then throughout, you also have, for example, Apple's that to describe very much at the low level what network traffic is permissible between, for example, for V PCs and other segments within the PCs.

So So I guess, what are some themes that you notice in terms of what what is common to the cloud providers and, and maybe how they and maybe just how they're changing as it relates to describing network partitioning and network security

Harry Sverdlove  13:50
will, between the different cloud providers, I think, you know, certainly hit the nail on the head, the beach provided something slightly different in terms of their nomenclature, it's also just because of the way they've of involved, you know, one of the things that's very common were terms change is it within cloud environments, you also have this concept of load balancers where you have something coming in over the wire or over the virtual wire, and you want to, you know, you want to send it out to one of many possible sources, these are elastic environments, it very common scenario be of your web server. And, you know, you might want one web server when it's low traffic. But in a high traffic scenario, all of a sudden, you're going to just pop open new instances. So now you have 10 instances, same on the back end. So now, you had one database instance, now, you have 10 database instances. And the way you do that is, you slap a load balancer in front of that, and, for example, an Amazon, you can have lbs and lbs. For network load balancers and lbs for application load balancers. And the different environments have different terms, I think some of its just sort of the way they've evolved, I think some of it sort of their ability to hook you on their crack, you know, you want to get hooked into the, whatever terminology or whatever usage so that, hey, you continue to buy those services at the end of the day, functionally, they're all offering very similar or metaphorically, similar things. And my balancing network connections, my balancing a specific application set of connections, am I trying to translate connections so that I can connect one virtual environment to another, functionally, they're all serving certain very common purposes.

Justin McCarthy  15:22
And actually, since you mentioned translating one environment to the other, I think, I think the role of VPN is it's worth bringing that in at this point.

So so within the cloud providers, you definitely have the notion of you can do, you can essentially bridge networks within universal across providers, using essentially VPN technology. And it's either you're either installing some open VPN on both ends, or maybe the cloud provider has, has an option VPN, it's interesting, they do sort of blend one perimeter into another, right. So there, it sort of does create does reintroduce a notion of a parameter and it does really tend to reintroduce the notion of trusting by network addresses because essentially my, let's say, my corporate office for my, in my, you know, ops bullpen area, we all have access to this particular subnet within the VPC in AWS. Right. And, and so and so there is it does sort of bring back trust as long as you authenticate into the, into the VPN. Um,

Harry Sverdlove  16:27
yeah, so furthering on the VPN concept, you definitely expanding your perimeter to include foreign devices, so that you dial in through some encrypted connection. And now you're part of some other network, your address space is now considered part of, let's call it the trusted address space. One of the biggest challenges with VPN, of course, is now everything on your device essentially has access to this trusted space. So you dialed in, because maybe you wanted to get your corporate application working. But there's other software running on your laptop sitting in that coffee shop that has a that may, in fact have access to that is basically now a member of your trusted network. So VPN or a way we've dealt with our distributed environments. But we're still dealing with the same the same basic semantics addresses, ports and protocols, to authenticate your identity, maybe through a password two-factor authentication, we encrypt the channels, so sleeping eyes can't look at it. Those are all good things. But we haven't established trust at the level of who's the person walking across, what is it that you're doing? And who are you we've established trust it, okay, now everything on your system has a trusted address in terms of setting up a VPN, the different cloud providers each have their own ways that they can offer VPN service, or as you said, you can get an open VPN. But it all it does require having something running on all of these remote devices that can establish a secure connection. So there's a there's, again, more maintenance, they're involved, it's a common way to do remote computing, but it definitely opens up some security holes as well. So

Justin McCarthy  18:01
is there any hope on the horizon and standards or otherwise have a beginning to answer this question more reliably?

Harry Sverdlove  18:09
Well, there's the optimistic area and the pessimistic carry, you know, because Mr. Kerry is I think we should unplug the cloud and all sit in tiny, isolated rooms, because there's no the optimistic carries. Look at technology continues to evolve. And it's not just to facilitate new possibilities, but also to facilitate new security measures. And, you know, being in the security industry for over two decades, I've seen a lot of things change network security certainly is, is going through an evolution and is ripe for change right now. So the short answer to your question is, I lean more towards the optimistic carry, it is possible. But I think we have to start rethinking some of not just the form factor. But some of the ways we associate trust when we are letting point A or user a talk to application or point B.

Justin McCarthy  19:00
One term that you find pretty quickly when you're deploying your firewall. is the notion of stateless for sustainable, what do they typically mean by that?

Harry Sverdlove  19:09
So the original firewalls which were stateless firewalls, and that's basically layer three and layer for in terms of just monitoring, they were making point in time decisions at this point in time, does this source is it allowed to talk to this destination? When you start adding state full firewalls, which gives you a broader level of inspection, they're actually monitoring persistent connections? And what's the conversation that's going on? So they can then make determinations about well, should this conversation continue, and you're allowed that you have a lot more depth in terms of the types of rules that you can allow, when you are state full, because you're having a conversation and you're saying, Okay, well, I don't want these types of things to happen, even after the initial connection is allowed. And hence, you get into this concept of a state full firewall.

Justin McCarthy  19:57
Got it. Thanks. So you mentioned web firewalls. One thing that comes to mind with and the idea of looking inside the conversation is just the role of disrupting man in the middle proxies. So So in the case where I can imagine in a corporate environment, I would very much want to be able to look inside certain kinds of traffic. If I were Facebook, I can imagine wanting to prevent that from happening. So can you talk a little bit about the role of encryption and actually decryption when you're trying to get into the semantics of some ongoing traffic. And this

Harry Sverdlove  20:31
therein lies some of the one of the biggest challenges with firewalls, which is when securities collide, if you will, the best practice we all suggest even is to encrypt your traffic, certainly when it's remote traffic. But even with, for example, GDPR, people say you should encrypt your internal traffic to well, when your traffic is encrypted. The whole point is so that people can't look at the wire or the virtual wire and read it. But a firewall especially when it is not when it is a choke point in your network needs to read it to do most of its next gen functionality. And so how do you deal with that. And the way that firewalls deal with that today is they deal with that by essentially man in the middling your network, you install certificates on the firewall, virtual or physical device. So it can essentially terminate this, the encryption decrypt the traffic make a decision as to a as a good or bad conversation, and then re encrypted, that act actually, it creates a configuration nightmare. In some cases, and with pls, 2.0 and future revisions of internet protocols, this may not even be possible. So it's going to become a challenge. If you're a firewall. If you're in the swimming pool, for example, and you've got to read the traffic to make business or security decisions. But that traffic is purely encrypted, you're going to be greatly limited. And you might actually end up essentially going back to the stone age's having to make your decisions again, off of Wow, all I got is, you know, source address and destination address again, what do I do right now?

Justin McCarthy  21:59
Can I can definitely see that is, so can you say a little bit more about that. So this is dealing with the contrast between host-based and host-based firewall. So we talked a little bit earlier about, you know, pf or IP tables running on my little Linux workstation, but does it does it go beyond that

Harry Sverdlove  22:18
in terms of what host based firewall is able to do? Well, certainly does. Because if you think about, they're sitting at a point in time before a certificate is applied, before it's encrypted, they can make decisions, looking at the operating system, looking at the environment saying, Hey, you know, I see you making a connection, but your systems not patched or see something else running, they have, they have a much higher fidelity in terms of the things they can use to make their decisions. The downside, of course, is there more distributed, generally speaking, you know, from a security perspective, it's better to have the control point or the control decisions made as close as possible to the thing you're trying to secure than to have it be at what a traditional or network based firewall is, which is at a choke point choke point is a single point of failure, it's a single point of bypassing, and it's a lower fidelity, it's a point where you have lower fidelity data to make decisions from.

Justin McCarthy  23:11
Got it. So I think we can see that a lot is changing in network security. And in firewalls, what are some properties that you could see, and then you would expect to see in, let's say, five years, so the devices and the software that is protecting our network, five years from now, what are some important attributes that you would expect to see,

Harry Sverdlove  23:30
I'd be, I think that we are definitely going to start seeing some enhancements, we're already seeing some of these being proposed and standards bodies where there is a more secure transport mechanism at a higher Layer Layer within the network conversation, because you're not always going to be able to either a, find a choke point or be in the case of Internet of Things, install a quote unquote, host based firewall on your nest, you know, home thermostat, or your industrial control systems. So there needs to be a standard where the communications injects in it a handshaking mechanism that can be validated, so that, you know, what is it we're trying to validate? We're trying to validate the identity of who's making the request, the identity of who's receiving it, the the transaction, what is it they're requesting, and possibly even some other attributes, you know, what time of day it is, or is my system patched other things happening, and that needs to be pushed into a standards body so that any two devices can communicate and actually be able to individually or independently ascertain, Hey, is this connection trustworthy? For me, when that happens, a lot of the firewall technology, which was, you know, you had mentioned earlier was based sort of as a bolt on on top of existing infrastructure technology. Now, all of a sudden, we have a new tool in our arsenal that we can use to secure communications.

Justin McCarthy  24:52
That's great. So regarding some of those upcoming standards, are there any acronyms that come to mind that we should be any or any RFC that we should be looking at?

Harry Sverdlove  24:59
Well, this a couple of s seems to be a common word spa, for example, as a standard that's been been secure protocol, I'm going to I'm going to mess them all up. So I'll give you the the acronyms and we can we reverse engineer what they actually stand for spiffy as another one, SP FF II believe, maybe without the without the I rather. But these are standards where they're trying to embed, or they're proposing embedding what in layman's terms, essentially a cookie or a cryptographic identity at the beginning of the packet within the header so that it identifies who's making the request, or it's some level of identification that the other side can handshake where the other side can validate against some other certificate. So that there is some cryptographic handshake between a source and the destination that isn't about, you know, the method of transport isn't about let me find a choke point and rip open the packets and make a decision that way, rather, let me look inside the conversation and see is this really you that is talking to me? Or is this really you that's making a legitimate request.

Justin McCarthy  26:06
So we've talked a little bit about the past and a little bit about the future, I'd love to, I'd love to leave our listeners with just a few steps they could take today to improve their story around around any of these topics. So is there is there anything that you recommend folks look into that is something they can sort of take action on today that would, that would improve some aspect of how they trust network traffic?

Harry Sverdlove  26:37
Once you understand who and what is communicating in your network, you then have to decide where am I going to start making security improvements? Am I going to do you know, what's important? And this is based on your own business drivers? Is it am I most worried about my users, maybe I have a lot of remote users and suspicious locations, or a lot of third party contractors, in which case I want focused on securing the identity of whoever's dialing into my network or my network resources and validate them. It may be for example, for your organization, well, no, I have certain assets that are the most important I don't care if somebody gets access to, you know, my my whiteboards or, or some fun application, what I care about is they're going to get my source code or these patents I have, or this secret thing that I'm working on, in which case, start by securing that and what a secure mean, secure means going through that that principle of least access of least permission in the case of something like a database least permission is I want to make sure that the fewest possible other services or users have access to that. And that's, you know, often where we get into, one of the things we often talk about in networks is segmentation. The whole idea behind segmentation is it's this assumption that, well, bad actors will get into your network, and you want to stop that from moving around. So imagine, for example, even like an office building, you might have some security on the outside, I use an access badge to swiping But in addition, I have higher security zones inside my building. So even if you make it in, Well, okay, you got into the copy area, but you can't get access to, you know, my records or something like that segmentation, and the network is the same way. So, find out which ones of your assets are have different sensitivity than others, and you put them in a different zone or you put them in a different segment, there's lots of ways with networks to do that. firewalls is certainly you know, the most common tool which helps you create sort of, if you will address based segmentation but you can create segmentation based on assets based on users and get even more granular at the end of the day. If you kind of want to think about sort of your vision or anybody's vision for the future it's going to be one where the network doesn't matter at all the addresses don't matter at all All that matters is what are the identities that of the things communicating that would be the perfect world so even on your laptop if you VPN in okay you running your email client is able to connect in but that other thing running on your system that other application or that other user that might come to your laptop he or she or they are not able to make that same access and I you know we're not there yet for most traditional firewall technology but that's definitely where we're going and if you start thinking about the problem differently that way and don't think about things in terms of addresses you can start prioritizing Hey Where do I want to try these different ideas try different security approach it

Justin McCarthy  29:40
This was very educational I want to I want to thank you that's Harry Sverdlove, love founder and CTO of Edgewise networks, helping us learn a little bit about firewalls past present and future today.

Harry Sverdlove  29:55
Justin, thanks so much for having me.

‍