"I hate cloud security." Part 3 of 3: Driving remediation
May 13, 2020
In Part 1 of this series on cloud security, I discussed the importance of knowing your your estate. In Part 2, I outlined measuring and reporting on compliance.
So, now the cloud is going just great for you You've got a grip on your company's cloud presence. You've got all of your assets identified and inventory is under control, you've figured out how you want to measure compliance, and you've implemented a brand new, shiny compliance tool and ..."OMG, look at all these vulnerabilities. I am so fired!"
Deep breath. Let's talk about remediation.
Part 3 of 3 - Driving Remediation
Unless you're in a really small shop, you are not in this alone. You didn't put those vulnerabilities there, so you shouldn't feel like it's your personal job to clear them. You should, however, feel responsible for making sure *someone* clears them. Take advantage of governance that is already established and hold the cloud service owner responsible for clearing the vulnerabilities and misconfigurations.
In much the same way it's an automobile owner's responsibility to make sure brakes and seat belts work, the team that is using the cloud account needs to make sure it's also safe. You will likely need to explain this to some of your cloud consumers (really, their managers), who may think they're already safe just because they are with a known brand of cloud service, therefore they must be safe. Naïve, but forgivable given the level of hype and marketing. Ultimately, it will be the operations team that has to correct these, planning any service disruptions around required up-time hours.
Compelling teams to get their vulnerabilities fixed can be as big of a challenge as identifying owned assets in the first place.
I suggest the following:
Create your game, explain the rules, and help all of the players win.
This is the formula to driving down risk in this space. Ultimately, a good system to address risk will let you focus on the next frontier: prevention. Prevention is really long goal here and is one of the many benefits of a well implemented DevSecOps approach.
Can’t get enough on Cloud Security? Check out my InfoSec Beat podcast on the topic
In closing, I think exceptions merit a brief discussion.
Exceptions are a temptation, and many organizations use them as a way to improve their SLA metrics. But exceptions do not make you safer, they just hide the risk.
With regard to technical risk, please adhere to a few rules when using exceptions.