The cloud is a “thing,” obviously. As security professionals, we need to figure out what we’re going to do to secure it. As a community, our first thought has been to adapt our existing thought processes, threat models, and security controls to this new environment. This is a rational first step -- we build on what we know works. It is time for a second thought -- to figure out where these controls fall short, where we have new opportunities, and where we have new risks.
We were scratching our heads about this problem. As we did, we realized that we have a brand new piece of infrastructure to secure that, until recently, we hadn’t had to worry about much -- the cloud control plane.
The control plane is the defining feature of cloud -- the fact that you manipulate the infrastructure with an API, a set of routines, protocols, and tools, rather than by plugging in Ethernet cables. In the cloud we now have to make sure we make all the right API calls to get control plane configured just right.
But it gets trickier. In the cloud, the cost of complex deployments goes down so deployments get more complex and therefore harder to reason about. In the datacenter you might have broad network boundaries (i.e. DMZ, servers, workstations) and for each subnet the access control is the union of the required access of all the things in that network. However, in the cloud, there is no particular reason to design your infrastructure this way -- each host, or cluster of hosts, can easily have exactly the access it requires and no more. [You’ve probably heard it called “microsegmentation.”] The upside of all this is that we have more precise access controls, but the downside is that reasoning about this massively complex environment becomes effectively impossible.
Still, it gets even trickier. Devops is also happening to us, which means that environments are changing faster and with less governance. Devops is, in part, a repudiation of the governance model that we security professionals rely on to do our jobs. Devops and security can be incompatible, but devops and governance are often like mortal enemies. Because of devops, we have to adapt to ever-changing environments, and we cannot rely on our spot in the governance pipeline to make sure our teams have good security hygiene. [Endnote: I’m not making a judgement about any of these changes but rather trying to point out that they are happening and we’ve got to find a way to deal with them.]
So we see that we have a confluence of problems here:
- We have a new thing to protect.
- That thing is getting more complicated.
- We’re losing our enforcement mechanism.
How do we get our heads around the immense complexity of these networks? And how do we ensure that in these immense, rapidly changing networks that even the most basic security hygiene is in place?
So as hackers do, we started hacking, and we’ve developed a solution to address control plane hygiene in the cloud. We’re focused on helping you with your responsibility to get the AWS control plane configured correctly. Think of it like this: the AWS control plane is a great big panel with thousands of knobs and switches. Most of those knobs are security critical -- they must be in the correct position in order for you to be secure.
Here’s How SecureWorks Cloud Guardian™ Works:
Thing #1: Have a security opinion
We’ve aggregated the generally-accepted best practices (including those from emergent third parties such as CIS). We used our incident response experience and threat intelligence to prioritize and supplement the best practices. Then we develop an informed, defensible and strong security opinion of the correct setting of the knobs and switches.
Thing #2: Tell you which knobs and switches are out of place.
We look at your accounts and tell you what is broken. This is fairly straight-forward. There are a few other players in this space and this is where they put their effort.
But as hackers do, we kept hacking.
Thing #3: Put switches into the secure state.
For each knob and switch that is out of place, we’ve given you a button that you can push and flip the switch back to the correct state.
For example, one best practice is that you should be logging API activity with AWS CloudTrail. If you don’t have it turned on, push the repair button, and we’ll set it up for you.
Another best practice is that you should be using TLS for transport security. If we find a load balancer that doesn’t appear to have TLS, push the button, and we’ll set it up for you.
We all know we should require multi-factor authentication for administrative users, and so the service checks that you do. To repair missing multi-factor authentication, you have to cajole the user into turning it on. If they don’t, you can lock them out -- which is what our repair button does.
Thing #4: Once you are secure, stay secure.
Once you’ve put a switch into the correct place, you’d like it to stay there. So once you’ve convinced Alice to turn on her multi-factor authentication, you’d like to lock her out if she ever turns it off. And that’s what we do -- we’re a thousand thumbs holding each knob and switch in place. We continuously monitor your accounts and if Alice ever turns off MFA, she’ll be locked out right away.
You can always choose to opt out of protection, and we only protect resources that you’ve already resolved.
Customizing your experience
As I mentioned before, we have our strong security perspectives baked into the tool on purpose, but we recognize that every point of view isn’t right for every network. So how can we let you customize? This is trickier that it sounds. We can’t just overlay a highly-complex control plane with another highly-complex control plane -- that would be self-defeating.
So to allow customization, we’ve provided hooks that allow you to implement your own checks and repairs as AWS Lambda functions. You can also use AWS Lambda to filter the output of the standard checks to modify the policies. One of our best practices is that access keys should be rotated every 90 days. If your organization’s policy is to rotate every 60 days, you can write a filter to make the rule 60 instead of 90.
Ready, set, go!
Hygiene isn’t the sexiest place to invest your resources. None of this is rocket surgery. It won’t fix all of your problems. But the incident history shows that as a community, we struggle to get basic security hygiene implemented. As our networks get more complex and change more quickly we’ll struggle more.
SecureWorks Cloud Guardian is a stab at making it possible to do hygiene correctly. We’re just getting started. We’ve got a good cohort of best practices available today and we’re adding more all the time.
The service is free on a trial basis beginning November 28 for a limited time. If you are interested, please head on over to cloud.secureworks.com and give it a spin. We’re eagerly awaiting your feedback.
 End date of free participation is TBD