Back
Staying Off the Hamster Wheel of Cloud Security Pain
It all starts innocently enough. You engage with a trusted provider to perform a penetration test of your shiny, new cloud-native application. And the penetration testers find stuff. Of course, they find stuff. They always find stuff because that’s what they do. Sure, you try to make it harder for them to find stuff, and sometimes you’re somewhat successful in that, but they’ll still find stuff.
Sigh. That means you have to fix stuff, right? Now you have a decision, and it can be a pretty tough decision. Do you fix things once and move onto the next thing? Or do you try to be a little more strategic and address the root cause of the issue, which is typically a human error committed by a well-meaning operations person? Our pals at Gartner believe that 99% of all cloud security failures will be the customer’s fault. Ouch.
You probably look at your to-do list and then make the quick fix to move onto the next thing. To be clear, I’m not judging that choice. It’s reality given the number of items on your plate and the amount of time it’ll take to really fix the problem.
Unfortunately, you are now on the cloud security hamster wheel of pain. This concept was coined back in 2005 by Andy Jaquith and highlighted the challenge of doing security correctly. No matter what you did, you ended up in the same place – breached and having to respond to the incident. Yeah, those were fun times. But I guess I shouldn’t speak of that in past tense because far too many folks are still on their hamster wheel.
So, what is a better approach to dealing with these cloud infrastructure security issues that provide the avenues for our trusted penetration testers to gain access to your cloud environment? It’s to implement a security operations platform that both responds to attacks and enforces a set of policy guardrails around your infrastructure.
Let’s start with the guardrails concept, as you may already be familiar with that term – since it’s taken on a life of its own in security marketing circles. We’re referring to the ability to assess against a set of security best practices continually (for instance, the CIS Benchmarks) and automatically remediate if a change is made that violates the policies. The guardrails moniker is apropos, as you don’t want anyone to drive your cloud application off the proverbial road, and the automated security guardrails keep you there without slowing anyone down.
But risks to your systems are not always security policy violations, as there are times where an attacker gains access to your cloud environment and starts making changes. You likely have all sorts of detection technologies and monitors (like AWS CloudTrail and GuardDuty, or Microsoft Security Center) checking on your cloud, but what happens when an alert fires from one of those tools? In some environments, nothing happens. Yeah, that’s the wrong answer. If you had a pre-designed set of playbooks to take actions depending on the attack, you’d already have addressed the attack before too much damage is done. We call this capability Cloud Detection and Response (CDR), but we’re not particular about the name – rather just that you can respond to a cloud attack at the speed of cloud.
Now, we’re all too aware that you may have broken into hives at the mere mention of automated remediation. We get it, many of us came from operations backgrounds as well, and we know (all too well) the downside of an automation run awry. So, we believe that humans should be in the process where needed. Thus, your cloud security operations platform should have logical points where an administrator can approve an automation before it takes action. Being able to make a “decision” about an automated action goes a long way toward gaining comfort with the tool and the changes required.
I’d be lying if I told you that cloud security (or any security discipline, for that matter) is easy. There is nothing easy about it. But staying on the cloud security hamster wheel of pain of making tactical fixes over and over again is an even harder path. Building internal cloud security operations capabilities is certainly an option, as we have many friends who carry around their own “suitcase full of scripts and Lambdas” to automate remediation.
But we don’t think DIY (do it yourself) is a long-term answer either. The solution is deploying a cloud security operations platform, as we’ve described above. If you’d like to learn more about this concept and how to gracefully address the issues found by your penetration testing team, check out our webinar on April 16.
And then you’ll have the confidence that you’ll have addressed the issues once and for all, or at least until the next time NetSPI penetration testers go after your application because they’ll find different stuff. That’s what they do…
Learn more about NetSPI’s cloud penetration testing services, including how cloud pentesting helps improve your cloud security posture.
