How secure is your network? Really, how secure is it right this very instant. Without listing your firewalls or IDS/IPS appliances can you say with certainty that your network is secure? What would happen if I dropped in a Raspberry Pi and started a recon attack against your devices? What if I figured out the IP address of your VM hypervisor or your cloud connection and started spinning up my own workloads in your environment? Would you say your network is secure at that point?
One of the biggest fallacies in the modern way of thinking about enterprise networking is that network reachability implies authorization. Think about a firewall. It’s designed to keep the bad things out of your network. But what happens if something slips through? Or, worse yet, what if the malicious payload gets in through a method that’s allowed no matter what? Why do you think that spearphishing attacks are so popular now? Email is universally allowed and protected through other methods. We implicitly allow connections on certain ports or from certain IP addresses.
We shouldn’t think for an instant that reachability should imply authorization. That’s going to cause all kinds of problems. We don’t allow it for other secure documents after all. Just because I know where the HR filing cabinet is doesn’t mean I’m allowed to go look through it. Just because I know where the user info data store is doesn’t mean I’m allowed to search it to find out if a celebrity is one of our customers. There are protections in place on each of those systems to ensure that only authorized users can access that data. Shouldn’t it be the same for the network?
We’ve tried to do this before with all kinds of identity management solutions and they all start failing around the same place: How do you validate and identify a device? Or, given the move to containers in today’s development environments, how can you verify something as ephemeral as a container? There could be a handful of containers that have shared the same IP address in the last hour and we have no way of tracking them. How do we know where a request came from? How can we prevent unauthorized workloads from accessing information? And how can we prevent a replay of a valid workload from getting into something it shouldn’t?
Enter Aporeto
At the most recent Security Field Day event the team at Aporeto has been thinking long and hard about this problem for a while now. One of the key things they’ve done to help combat the identification issue is to digitally sign containers. The Aporeto enforcer is constantly looking for new workloads to be spun up in your environment. And when it finds one, it starts interrogating the metadata about that workload. It can identify the orchestration engine or the parameters around the workload itself. And it uses that data to create key/value pairs about the workload and digitally sign them.
So, what does that get me? It means that you now have information about a workload that you can trust. I can tell that this workload is different from a workload that was spun up to be identically because the cryptographic signature will be different. And the key/value pairs tell me a lot about the workload. Like the cloud provider or the operating environment. It could even tell me what application is running on it or what databases it calls.
Okay, now what do I do with that information? Well, the smart readers probably already know what to do with all kinds of identity information about an object. You build policies around it! The cornerstone of all policy is identity. By having identity information about a workload you can craft a policy for it. And since your users already supply their identity information to the system you can load that into the policy engine as well and make all kinds of fun rules.
Fun With Policies
Just like the HR filing cabinet example above, you can restrict users from creating containers. Or maybe you just want to prevent users from creating specific types of containers. You can also prevent them from creating workloads in unauthorized areas. Maybe you want to lock out your developers from ever accidentally creating a workload in production. Now you can. You can also keep certain users from spinning up workloads in the cloud. That keeps your developers from blowing your AWS budget for the next 8 quarters with a forgotten machine running in the cloud.
More importantly, you can create policies that identify pieces of the container workload itself and prevent mistakes before they become problems. For example, maybe you have a policy in place that no workload will have a non-secured HTTP server running in a public-facing capacity. That’s noble and works well until someone makes a late-night goof and spins up NGINX on a machine somewhere and leaves it open. Next thing you know, you’ve made the news because someone exfiltrated all your customer data. With Aporeto, you can create a policy that any non-secure HTTP server is forced to use a proxy to authenticate user access through something like Google. Now, anyone trying to access the web server will be intercepted and forced to authenticate. That means any accidental issues will be covered until you can be alerted to the issue and remediate it properly.
And, lastly, one fun thing that you can do with policies that you may not realize: You can squash bugs before they come out. Remember CVE2018-1002105? It’s the bug in the Kubernetes control plane that allows people to do bad things with API access and cause all kinds of problems, like accessing your backend and running code with the API authentication level. Funny enough, because the Aporeto Enforcer validates those API requests before they come in they’ve already patched the problem without meaning to do it. That’s a powerful solution indeed.
Bringing It All Together
If your idea of security is firewalls and barriers that leave your internal networks and systems vulnerable you’re likely in for a rough time in 2019. Security isn’t static. It’s a dynamic dance of permissions and monitoring. And you need to be able to identify the things running in your environment. That’s why Aporeto is ahead of the curve. Their identity solution for containers gives you the change to find the things running in your environment that need to be identified and dealt with. And you’d rather have Aporeto find them before someone else can hide them and use them for nefarious purposes.
