Quick! What’s the IP address of your application database server? How about the IP address of your monitoring system? Maybe your data center default gateway? Odds are good you may have been able to come up with at least one of those addresses. But the odds are even better that you just shake your head because you only know those systems based on their DNS names. That’s especially true if you live in the cloud today. In fact, if you know any IP addresses other than your default gateway or your primary DNS server you may be doing this whole Internet thing wrong.
But what about security policies? How can we ensure that devices that aren’t supposed to talk to each other are, in fact, not doing that? In the old days, we had to get creative. We located our development devices in one network and our production devices in another network and we created access lists between the two that said DEV can’t talk to PROD. And all was good as long as those devices lived in different subnets.
Fast forward to the modern day. Now, all of our devices live in the cloud. Our systems aren’t in neat, tidy little networks any longer. They have VPCs or VNets that live in Virginia or Oregon. Getting them to talk to each other is a challenge on a good day, let alone trying to prevent them from communicating in a specific way. Crafting security policies on top of it all is even more difficult. Because, as it turns out, regulators and hackers don’t accept “I couldn’t make it work” as evidence that you two systems aren’t talking to each other. You have to prove that they can’t.
Name Segmentation with Guardicore
During Security Field Day 2, I was delighted to see a presentation from Guardicore. I talked with them a bit last year to understand how they were doing microsegmentation and zero trust networking in their own way. During Security Field Day they took some time to outline exactly how their solution works:
This overview of their platform is great for a lot of reasons. But the one that stood out the most to me was the way they use names to do their security. It’s kind of a foregone conclusion that we need to name things in order to effectively keep track of them. Yet you’d be shocked how often we still refer to devices by IP address. Even in a world where we can spin up hundreds of containers at once we still have this mentality of thinking about devices by number instead of name.
That mentality hurts us with security. What happens when that device gets a new IP? What about when something gets moved to a new subnet? What if a developer machine has DHCP enabled or is connected via Ethernet AND wireless? Just these few scenarios are enough to make your head spin! How are you supposed to keep track of all these things?!?
Guardicore uses an old feature that I really love: labels. It may sound quaint, but the idea of using labels in security policies hasn’t really been used in days gone by. That’s because security policy needed to be “translated” at the device level in order to make sense. Sure, you could write down “devices in DEV can’t talk to PROD” but you needed to do the heavy lifting to figure out how to implement that. And mistakes happen even with the best of intentions.
Now, with Guardicore, it’s as simple as sticking a label on everything. Label your developer resources as DEV and then create a policy that says what they can and can’t talk to. And you write that policy like a normal person would. You say “Devices with label DEV can’t talk to devices with label PROD” and that’s it. Guardicore takes care of ensuring those two systems can’t talk to each other. And you can pull audit logs to ensure that happens, or doesn’t happen in this case. You have the proof regulators want!
The other awesome thing that Guardicore allows is FQDN policies. Again, we’ve been stuck in an IP address and VLAN mindset for a long time. As more and more services move to using DNS names we need to make sure that we craft policies that reflect that. Because we honestly don’t know what’s going to happen in the cloud. Do you know for sure how your application is being load balanced? Or what middle boxes are rewriting TCP headers? How can you even know for sure what path your packets will transit? If you’re running proper resiliency protocols you may not even know which availability zone your packets are landing in!
Guardicore allows you to build policies that reflect DNS names for services. Just like the labels, once you build the policy it applies to all instances that have that DNS entry. So, if you spin up a hundred containers to take a large load during Black Friday, Guardicore ensures they’re all protected as long as they live because they all have the same DNS name. In a world where you can create cloud sprawl as fast as you can click on a Kubernetes instance that’s a large comfort that you’re safe from absentmindedness.
Bringing It All Together
I’m one of those weird people that labels everything I own. Especially if it’s something that can easily get lost or confused with someone else’s stuff. Why? So that I can point to the label and easily identify my iPad or my spork. And if anyone wants to argue then there’s a label to tell them what’s going on. With security labels just make sense. Rather than having to remember arcane segmentation strategies and hope that someone built something that isn’t going to fall apart, you can instead point to the labels as proof that you’re building something extensible and foolproof.j
To learn more about Guardicore and their microsegementation solution, please go to http://Guardicore.com
