Hi, folks, Ed Amoroso here. And I want to talk to you a little bit about the implications of a big distributed, hybrid cloud security architecture. And the idea that we'd have workloads scattered around different cloud infrastructure, potentially around the globe. And coordinated and hyper-resilient, all the nice features that we want in a future enterprise security architecture. When I show that concept to a lot of security teams, here's what they say. They'll show me that their data center architecture is global. So what? Data center over here and some headquarters building over there. And we're scattered around the globe, maybe a big bank. And they'll say, we already are that. We are distributed and we are global. But that's not what I'm talking about. A global perimeter is not secure. Here's a representation here that shows a little warning that global perimeters are not secure. If I have all these nodes scattered around lots of different countries, little blue nodes and red nodes, denoting workloads and control nodes, respectively. If all of them are protected by a common perimeter, meaning, I've got one or two or three or however many gateways that are the entry point to which I can gain access to these systems across which there's layer one connectivity. There's network media that connects them and that they trust each other. So someday, an attack that happens in Australia might cascade laterally across the perimeter to a server in Seattle. They all trust each other. A global perimeter is not secure. Now if you have something like this, which a lot of people do, an interesting corollary emerges. And maybe I want you to look up in the top left of this diagram. You can see one of the little servers there, if it's sitting there. Again, let's assume I got an attack in Australia. It traverses laterally through this trusted grid, which is more secure for it to be sitting in the perimeter. Or the next chart shows I've now taken that server, moved it way up into Canada into an isolated server with its own microsegmentation. Let's go back a chart, look at what we had. We had that dot, that little server sitting inside the perimeter, officially inside the perimeter. And now, boom, I've isolated it out. Which do you think is more secure? I think the answer is that server is more secure outside that big monster perimeter. Now here's the reason this is sort of interesting. Here in the United States, we had an election recently, where one of the big issues was that one of the candidates had isolated an email server outside the official government infrastructure, namely, big perimeter, happened to be run by the US State Department. Now setting the politics aside, this has nothing to do with politics. The implication a lot of people sort of made, or the conclusion that was made was that by isolating that server outside the perimeter, this candidate had made the server less secure. I think you could make the case that the argument is wrong. That in fact, by isolating the server, by removing it from the perimeter, it was actually more secure. I doubt that that political group had intended to do it for that reason. I think they had maybe 50 other reasons for moving it out. But maybe an unintended consequence is that it actually led to a more secure service. So what we all need to take from this is that it's not necessarily the case that services are better off from a security perspective inside a big sort of official perimeter. Better to break the whole thing up, isolate, scatter, distribute, virtualize. These are the words, these are the verbs that should be used synonymously with making systems more secure. I hope you've enjoyed this, and I'll see you in the next one.
