Cloud Providers Must Share Discovered Vulnerabilities

At what point does the cloud provider have an obligation to inform a customer agency of this potential vulnerability?

It is important for agency senior management to understand that when an assessment identifies a new risk, this risk did not just materialize when the report reached their desk. Rather, it has likely been in place for some time, and the agency has been unaware but still in a default acceptance posture.

This is similar to a homeowner discovering radon in a basement. While the health risk has always been there, the homeowner didn't know about it until it was tested. In both IT and health risks, the damage may have already been done. Finding the vulnerability and quickly determining appropriate mitigation actions are musts.

Part of the risk equation is probability. This is the likelihood of the threat exploiting the vulnerability. If the likelihood is very low, the risk drops. However, the longer a vulnerability is allowed to exist, the more time and opportunity a threat has to find and exploit it.

While the Department of Homeland Security and the General Services Administration are making progress in implementing continuous monitoring in the cloud, one area that demands immediate attention is vulnerability sharing. Should an agency be expected to wait months for public notice of a potential high-risk vulnerability when possible workarounds are available?

As written, the FedRAMP polices leave agencies in this exact situation. Until DHS and GSA can require sharing of vulnerability information in near-real-time, agencies will continue to be in the dark regarding their overall risk postures. An agency can outsource IT services but not risk or responsibility.

Agencies should ensure that sharing vulnerability information is addressed in the procurement review process and contractual agreements with cloud service providers. Additionally, organizations can take active steps to form collaborative groups of cloud service provider customers to express a common voice and common concern.

In Bruce Schneier's December 3, 2012, blog post, "Feudal Security," he describes cloud security as an experience in feudalism:

Feudalism provides security. Classical medieval feudalism depended on overlapping, complex, hierarchical relationships. There were oaths and obligations: a series of rights and privileges. A critical aspect of this system was protection: vassals would pledge their allegiance to a lord, and in return, that lord would protect them from harm.

In this new world of computing, we give up a certain amount of control, and in exchange we trust that our lords will both treat us well and protect us from harm. Not only will our software be continually updated with the newest and coolest functionality, but we trust it will happen without our being overtaxed by fees and required upgrades. We trust that our data and devices won't be exposed to hackers, criminals, and malware.

The Feudal Lords of Cloud have promised to protect agencies and keep them safe from harm, and it is time they be required to prove it continuously.

NIST's cyber security framework gives critical-infrastructure operators a new tool to assess readiness. But will operators put this voluntary framework to work? Read the Protecting Critical Infrastructure issue of InformationWeek Government today.