"I hate cloud security." Part 3 of 3: Driving remediation

 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:

• Work with the operations teams to define reasonable aging targets: how long a vulnerability is allowed to live from first detection. Risk-informed SLAs need to be balanced with creating a simple standard that is easy to measure and explain.
• Be transparent across operations teams: producing a simple red-, amber-,  green-style scorecard, comparing teams against their peers, can be very effective. If you can help one or two teams perform at a high level, it shows other teams what is really possible.
• Set overall goals for teams: when will you meet the SLA not just for most of your vulnerabilities, but for all of your vulnerabilities?

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. 

• First, you must implement mitigating controls. Perhaps you limit access to a resource or implement additional monitoring of the vulnerable object. If you don't think the risk is large enough to warrant a mitigating control, then you don’t need an exception, and instead need to update the standard. 
• Second, put time limits on your exceptions. Technologies and risks change over time, and you should look at your exceptions with your updated risk lens regularly. 
• Finally, report on your exceptions as you report on your vulnerabilities. It's too easy to file and forget your exceptions. Not looking at them in summary can lead to missing important insights and broader risks. Remember, the bad guys don't care if you've put an exception in place for a risk.