Saving the Perimeter — Part 1
I get nervous a lot: Speaking in front of groups still bothers me. I’m not a huge fan of heights. I get nervous for my kids more than anything. But rarely do I get anxious in my day to day job. I’ve been managing technology risk for quite some time now, long enough that I can generally handle just about any crisis while keeping my cool. But in the summer of 2016 I was near panic over security perimeters.
To understand what shook me so much we first need to take an abbreviated look at the history of the network perimeter. To get started let’s look at an ancient network diagram from the early to mid 1990’s.
OK, this diagram might be a bit too simple, but networks just were pretty simple back then. All enterprise data was stored in the safe confines of the network perimeter. Ports in and out of that perimeter were just opened or closed. We’d open ports that we considered safe like those used for e-mail or web traffic and close ports that were considered unsafe such as those used for SMB or telnet. (Well, I thought we all closed off SMB from the internet in the 1990’s. WannaCry proved that we’re not quite there yet.)
Of course, there’s one problem with the all or nothing strategy for opening firewall ports: If you have a house with 65,536 doors and decide to lock all but 3 or 4 of them, sooner or later the bad guys will find those doors and get in. And that’s exactly what happened. We started to get attacked through web and e-mail. Other protocols started to get directed through ports 80 and 25. (What? You can do that?)
And so, we evolved:
This new network doesn’t look so different from the last one. All the enterprise’s data is still almost exclusively stored inside of corporate firewalls. But we added a significant additional control in this version. By creating a DMZ (or 2 or 3) between the traditional corporate network and that scary world outside we were suddenly able to accomplish much more in the way of security.
Now we could break open connections and inspect traffic going in and out of the organization. Security was no longer all or nothing. We now had the ability to inspect inbound traffic for malicious data (integrity). We could check outbound traffic for sensitive data going out (confidentiality). We could do filtering so web sites were could be blocked or spam could be intercepted.
This one little change gave us an enormous security boost. While still imperfect, we may well look back at these days as the golden age of security.
Unfortunately, it didn’t last long, at least for most folk. Cloud based software and Bring Your Own Device Device (BYOD) policies soon resulted in data migrating out of the internal network that was the foundation of our security approach.
For most people this happened gradually. For me it literally happened overnight. That was terrifying.
But after spending a little time thinking through it, I realized that even back in our early 1990’s networks, the perimeter wasn’t about the network. They were just a convenient means to protect the data inside. The data may have escaped the internal network, but that protection didn’t need to end, only the convenience. We could still create a perimeter around our data. But in a world of cloud and BYOD that perimeter would have to take more creative forms.
Whatever forms our new perimeter would come in they needed to be measured. And the golden age of the DMZ still provides the standard for perimeters to come. If we can inspect and filter data in transit for data loss and malicious activity in a way that was comparable to what the DMZ provided then we could adopt new technologies like cloud and BYOD without degrading perimeter security.
It’s a brave new world, but we can still navigate it.
In the second installment of this series we’ll talk about some steps, tools, and techniques for trying to recreate the perimeter.
