Cloud Providers must share discovered vulnerabilities
Government agencies must band together and insist in their contracts that cloud service providers share vulnerability information.
Government agencies that rely upon cloud service providers have to trust that cloud providers will protect their data or services from risk and harm. In a perfect world, cloud providers would have a complete understanding of the unique missions — and risks — that agencies face.
In reality, cloud service operators tend to provide a “one size fits all” approach to services that often overlooks specific or unique mission risks. As a result, government agencies must ultimately accept responsibility for ensuring that cloud providers offer the appropriate amount of protection to manage risk. It also requires agencies to directly address some fundamental questions regarding risk.
According to NIST Special Publication 800-30, “Guide for Conducting Risk Assessments,” risk is a function of threats that can exploit vulnerabilities that in turn can lead to an undesirable impact to the organization. There are three aspects of this equation (threats, vulnerabilities, and impact), and agencies must consider all of them to understand ongoing risk in their cloud environments.
Agencies can ascertain potential threats using information provided by NIST, US-CERT, the organization’s security operations center (SOC), or several other industry threat feeds. They can then determine the potential impact of these threats, using NIST’s Federal Information Processing Standards Publication 199 and the guidance provided by NIST SP 800-60.
However, where and when do agencies gain an understanding of vulnerabilities in a cloud provider’s offering?
In the past, agencies would conduct vulnerability scans, penetration tests, and security assessments as part of the FISMA authorization and continuous monitoring processes. The agency controlled or owned the infrastructure and could therefore perform testing at its leisure. This led to volumes of vulnerability information in the form of scanner output and assessment findings. These results were fed into the risk management equation along with impacts and threats to determine an organization’s risk posture.
With cloud computing, vulnerability information can be difficult, if not impossible, to thoroughly, regularly, and accurately obtain.
The early CONOPS — the Concept of Operations for FedRAMP (the Federal Risk and Assessment Management Program for cloud security) — required agencies to negotiate the exchange of vulnerability information with the cloud provider. The most recent version of the CONOPS and the Continuous Monitoring and Strategy Guide require agencies to delineate between agency controls and cloud service provider controls for reporting.
While incident sharing is covered extensively, vulnerability-information sharing is barely addressed; it amounts to an annual self-attestation event with monthly scanning reports sent to the FedRAMP information system security officer. No mention is made of sharing information in near real-time with the customer agencies that will experience the negative impact of an exploited vulnerability. Additionally, vulnerability information discovered outside of assessments and scanning is not addressed whatsoever.
Vulnerability scanning and FISMA assessments are not the only way cloud providers receive vulnerability information. Security researchers are constantly testing cloud providers’ capabilities.
When agencies move to a cloud provider, they often sacrifice any sense of a staged or development environment because most cloud providers are production only. Therefore, researchers and engineers are often left to test on the production environment. Sometimes they discover massive vulnerabilities, which can lead to administrative-like access to the cloud provider systems.
The authors are members of the (ISC)2 U.S. Government Advisory Board Executive Writers Bureau, which includes federal IT security experts from government and industry. The experts write anonymously through the Bureau so they can be more forthcoming with their analysis and … View Full Bio