Cloud and Continuous Monitoring

Continuous monitoring involves assessing an agency’s information security posture based on changes to risk resulting from new threats or newly discovered vulnerabilities. The National Institute of Standards and Technology’s (NIST) Guide for Applying the Risk Management Framework to Federal Information Systems (Special Publication 800‐37, Revision 1) specifies continuous monitoring as one of the six steps in information security. As agencies begin looking at cloud initiatives, the challenge is implementing a continuous monitoring program that reduces risk and ensures compliance with NIST and other relevant guidance in an environment of decreased control. The solution begins with knowing where compliance ends and risk begins. The Game of Risk Risk is an operational prerogative-- the level of risk an agency is willing to take within a given situation or even as an operational baseline is subjective. For all of their complexity, the NIST SP 800-X series documents only provide guidelines by outlining control families, processes and reporting procedures for proving due care and diligence. SP 800-60 V1 & V2 outline processes for determining information type and the security category (low, med, hi) for systems, but we all know that risk is a trade-off between availability, integrity and confidentiality. Despite all of the guidelines, in the end, there will still be some level of risk remaining.  Therefore, continuous monitoring should serve to provide agencies with a dashboard of information that lets them know if something has changed to increase their actual risk from what their initial assessment of the risk was. So the question remains: How is this activity impacted by moving parts of your systems to the cloud? Leap of Faith/Loss of Control Moving to the cloud involves taking a leap of faith, given that the point of moving to the cloud is to transfer responsibility for the system in question. It can be argued that risk should not be transferred, but that really isn’t consistent with reality. While agencies can’t transfer accountability, they can and should, most certainly, transfer the responsibility. If an agency puts a platform in the cloud, the security requirements of that platform, which they are accountable for, have not changed. And if they have followed their certification and accreditation procedures properly, they know exactly which controls--in the 16 families of NIST controls--apply to that platform. But there’s the rub. An agency no longer has complete control over that platform once it’s in the cloud. They then have to reassess those controls with respect to the Service Level Agreement (SLA) with the cloud provider. For things that are external to the platform (such as physical and network controls), agencies have to rely on their provider to be compliant.  The SLA had better include these newly reassessed controls as well as a description of how the provider is going to prove compliance through continuous monitoring and reporting of those controls. When agencies move something to the cloud, they are moving a significant portion of control over to the provider and the only protection they have is the SLA. Going Public Of course, we have to remember that there is no such thing as “zero risk”.  To this end, when something goes wrong, how do we remediate the issue?  This question brings up a point that agencies are not typically used to dealing with since data has to have value to be compensated for its loss. A provider can patch vulnerability or otherwise remediate the risk, but if there’s an incident, then the presumption is that there’s been a loss.  Therefore, agencies can potentially open their remediation issues to the public scrutiny because enforcing an SLA requires legal action. Ultimately, the bottom line in considering whether or not an agency should move its platform to the cloud is understanding that the associated risk could mean issuing a public explanation and apology.