Securing the Internet With Cloud Innovation

Clarke Rodgers (00:10):
It’s hard to believe there was a time before the Internet, when security concerns were simpler and more clear cut. The world has changed drastically in the last 40 years, and online connection is now central to our lives and businesses. With that comes greater opportunities, but also much greater risk.

I’m Clarke Rodgers, Director of Enterprise Strategy at AWS and your guide for a series of conversations with AWS security leaders here on executive insights.

Today, we’re talking with Paul Vixie, AWS Deputy CISO, Vice President, and Distinguished Engineer. Paul brings a unique perspective to AWS Security, having been an early influencer in the evolution of the Internet. Join our conversation as we discuss the role of security leaders in making the Internet a safer place to communicate. We hope you enjoy.

Clarke Rodgers (00:57):
Paul, thank you so much for joining me today. You've been in the Internet game for quite some time. Can you share some of your observations of how it started and how we got to where we are today, especially from a security perspective?

Paul Vixie (01:11):
Well, security was an afterthought. So that comes into the story considerably later, but the stories are true. This did begin as a US government network. It was never used by the military, at least in the early days. And so, there's a mythos that the protocols were designed to be hardened against kinetic attacks or whatever. And that's not true. It's always been a best effort system. And when it works, it works really well for a lot of people. When it doesn't work, there can be some catastrophic failures that a more hardened network would not have.

Clarke Rodgers (01:48):
At what point did you realize, “Oops, security wasn't taken into account”? And what did you realize needed to happen?

Paul Vixie (01:56):
I started ringing the alarm bells pretty early, and my initial concern was spam. We had no authentication, nothing that prevented people from sending unwanted traffic because in a pure government network, you didn't have anybody who would benefit from sending unwanted traffic.

So, I started ringing the alarm bells as early as '92. And after I was off on my own doing consulting and so forth, I also started the first anti-spam project, which became the first anti-spam company. And our distributed reputation system was the first of its kind. I wish I'd patented that. And I mean that system is still in broad use today, although the company I started to fight spam got sued out of existence. So that company is gone. But the idea and the technologies all live on, and boy was I ever right.

Clarke Rodgers (02:57):
So what, if anything, and I hope there's something, is sort of encouraging you now that you're seeing security being taken more seriously, not only at the large cloud service providers, but at customer companies as well. Does it give you hope?

Paul Vixie (03:13):
I have hope and it's tinged with disappointment because everything we're doing is too little, too late. But you kind of have to wait for the whole market to wake up and see the problem. You can't just be ringing the alarm bell as one company or one person.

One thing that gives me hope is a collection of technologies that I've encountered after coming to Amazon. It turns out that at scale there are some problems that you can generalize and solutions that you can then deploy, which can't be done by smaller companies who are only doing a small thing. So as an example, what we've done in the Graviton processors to make our VMs more secure against other VMs, nobody's done that except us.

If you look at the Nitro chip set and the Nitro hypervisor, nobody's done that except us. When Log4j came out, as an example, we weren't unaffected, but we had a patch for all of our customers within a few dozens of hours because we're big enough to know how to do it and to be able to deploy it rapidly in a global way, whereas a less centralized system where everybody's responsible for their own stuff, yeah, you got to wait for your supply chain to wake up.

And a lot of the things we did early on on a shoestring back when transistors cost a dollar apiece are gradually phasing out. And other than by not doing the stupid things in the first place that helped us get to market faster than the OSI protocols, there's no other way to fix this except with clouds like ours.

Clarke Rodgers (05:09):
As we sort of look forward into the next couple of years, are there any particular technologies or methodologies that you're particularly excited about that you think is going to help not only companies like ours but also our customers to move forward with their security and compliance workloads?

Paul Vixie (05:31):
Well, certainly one thing that's heartening internally is the way that containers are turning out. The fact that we can have 10,000 of these all operating on a single chip and start thousands of them per second if there's a load spike, but not require somebody to completely change the way they did their software engineering, that is heartening because as people move to that model, we will get away from the problem we have now on, for example, patching.

On any given day there's something that needs to be patched. And unless you have a team dedicated to that, you're going to put it off, you're going to do it once a week, once a month, whatever. And when you do that, you may find, "Gee, in order to make this patch fit the system I have, I've also got to upgrade these other things, which means I have to put the whole thing in a test lab." And so, you could be months away from the time that you find that something really desperately needs patching to the time when you finally have that patch in your system.

I don't think we can get to the glorious future in Star Trek where everything just works if we keep doing that. And so, things like containers, whether it be Lambda, Kubernetes, Firecracker gives you a chance to have your build pipeline, the so-called CICD, make an image and run it through its tests, and if it passes, you can just drop it into service.

You don't have to have a VM that's got enough onboard tools and logic so that you could actually reach in and use it to patch itself. That's what we do today — it isn't going to scale. It's already shown some creaks, although I still run that way because that’s the world I grew up in, but I don't recommend others to do so. There's no reason to do so and there's a lot of benefit if we could just agree, “Yeah, we're going to build things and then we're going to not touch them.”

So, the idea that we're going to stop having humans in the loop is the other heartening thing. And I'm sad to say this because humans thought this up and humans built it, but we have to reduce the human element now if we want to have safety that is not reducing over time.

The amount of software and hardware that is sort of between a human and the value delivered to a customer is greater than it's ever been. And our understanding has remained relatively fixed, which is to say we understand a smaller fraction of it every time it grows. That won't work. We're going to have to figure out how to make sure that the complexity doesn't create outcomes that are undesirable. And again, that depends on having more discipline and keeping humans out of the loop.

Clarke Rodgers (08:18):
With the idea around human access and networks, the idea of Zero Trust has evolved over the years. What are your thoughts on Zero Trust, both from an AWS perspective, like how we think about things and implement things internally, but also from a customer perspective, how should they be looking at Zero Trust?

Paul Vixie (08:39):
The key irreducible element of Zero Trust is misunderstood. For example, I've heard people talking about this who say “Just put everything online, make it all reachable and secure the services and the servers themselves. Secure the network without having a perimeter.” That's not the point of Zero Trust and doesn't work. You still need a firewall, it's just that once you're inside the firewall, you won't find that you have any special trust just because you're inside the perimeter.

So, it's doing away with the assumption that reachability implies trustworthiness. It used to be called the “crunchy exterior” and the “soft, gooey interior.” So, we don't want to have a soft, gooey interior even though we still have a crunchy exterior. So, you need a system that mechanizes identity and authentication and permissions at scale. And as an example, while you and I are having this conversation, there are a couple billion authentication events per second happening on the Amazon Cloud.

And we didn't use any sort of cheap tricks like caching recent results and saying, well, if you had permission a second ago, you probably still have permission. No, we check every time, and at some point, we bit the bullet and said, “Nothing less than that is going to properly address security as job zero.”

But again, most systems were designed with the idea that if you could get in, then since they didn't have fine-grained access control that would work at scale, they just let you do anything you wanted. That's what we're changing. And there are a number of different authentication standards. Ours has gotten out there kind of first and it's very big, but it was never meant to be an industry standard. And so other clouds have similar things that they're working on and there are some industry standards that are trying to get born.

And as far as I know, without having talked to the service team, we're going to make sure that any customer who wants to operate that way can do so.

Clarke Rodgers (10:49):
In the last year or so, generative AI has been all over the news and seems to appear almost daily in my newsfeed. What are your thoughts on it from a security practitioner perspective? How do you see security professionals using it to help protect, investigate, those types of things?

Paul Vixie (11:10):
So, you have to look past the hype and say, “What will it be once it settles down?” And in some cases, we don't know. It's a pretty new technology and a lot of hardware and software is being crafted for it. And you never really know what the impact of a tool is going to be until it is used by somebody other than its maker. If you're going to use a wrench as a hammer, that's probably not what the wrench maker thought you were going to do, but it might work in some situations.

We haven't seen strong indications of what this will really make possible once the hype cycle dies down and we have something else that's grabbing the headlines. That having been said, we at Amazon have been doing research, development, and deployment of AI-based solutions for at least the last dozen years. And so, this was not a complete surprise to us.

We already have an example in that the CodeWhisperer system of something that is using generative AI techniques but doesn't look anything like what's been grabbing the headlines. I see that happening on all sorts of systems. For example, when you're doing anomaly detection, you're looking at telemetry flows from your system, you're looking at either events that indicate maybe there's something going wrong or events may indicate somebody's attacking you. It's going to be possible to cross-correlate those better now that we have this technology. And again, I feel like we've barely seen 1% of what will be possible.

So, while on the one hand I despise the hype cycle and I wish we could just be serious from the get-go, I also understand there is some real merit here. I'm working with some teams inside of AWS Security who are trying to answer that exact question: “What can we do to better serve our customers now that this is generally available and generally understood?”

Clarke Rodgers (13:14):
And then sort of help that human security practitioner with a lot of the grunt work from a technology perspective with generative AI tooling?

Paul Vixie (13:25):
Yes, and I don't mean this to be a product plug, but Amazon's biggest success with our cloud has always been the workflows we enable our customers to adopt and build. And so, one of the first things that we did in the large language model space was Bedrock. The idea is if you want to use a large language model, do you also want to pay the training cost? Do you want to have to build the model?

Because that can take thousands of hours or tens of thousands of hours of very expensive computer time to do. And if there are various pre-built models and they're sort of on a menu and you get to pick which ones you want, but you don't have to pay to copy that to your own system, you can simply put logic in your VPC or whatever it is you're doing in our cloud environment that has direct access to APIs that know that they have access to these subscription models.

And so, the original premise, which I didn't know at the time, I've had to learn after coming here, the premise of the cloud turned out to be that having an elastic amount of compute, so as much as you really needed, next to an elastic amount of storage, again, as much as you really needed, with no access penalty is how we got big. And now we've just replicated that inside of generative AI so that people who are maybe very ambitious in their own segment of the market can do with our cloud and LLMs what they've always done with our cloud without LLMs. We love that. I love that because the real power of this will turn out to be what our customers did with it.

Clarke Rodgers (15:13):
And that customers have that built in trust from all the security tooling they've used for years and other aspects that can now apply to tools like Bedrock and whatever else may be coming down the road.

Well, Paul, thank you so much for joining me today.

Paul Vixie (15:26):
It has been great. Thanks again for having me.