A Publication of Pepper Hamilton LLP
Partly Cloudy with a Chance of Data Breach
Friday, August 23, 2013
A report recently published by NIST sets forth steps federal agencies and the private sector providers who cater to them need to take to ensure the security of data stored and processed in the cloud. As has happened with previous NIST reports, these criteria will likely be used as benchmarks for assessing regulatory compliance, and serve as the gold standard for transactions completely within the private sector as well.
The National Institute for Standards and Technology (NIST) recently published a report detailing parameters for federal procurement of cloud services with respect to maintaining the security of data stored and processed in a cloud environment. NIST Cloud Computing Security Reference Architecture (NIST Special Publication 500-299) (the Report), published in June for public comment by July 12, 2013, is one of a series of “Special Publications” aimed at accelerating the adoption of cloud computing by federal agencies, which is a mission given to the NIST by the US Chief Information Officer.
The Report provides a “comprehensive formal model to serve as security overlay” to NIST’s earlier cloud reference architecture, detailed in the NIST Special Publication 500-292: Cloud Computing Reference Architecture. It is meant to demystify the process of describing, identifying, categorizing, analyzing and selecting cloud-based services for the consumer seeking to determine which service offering most effectively addresses their cloud computing requirement(s), and supports their business and mission-critical processes and services in the most secure and efficient manner.
The significance of this report is threefold:
- It sets parameters for federal agencies which, starting on June 6, 2014, would be required to utilize only cloud providers assessed and authorized through the Federal Risk and Authorization Management Program (FedRAMP) which are aligned with NIST SP 800-37: Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach and with the Report.
- U.S. regulatory bodies tend to use NIST standards to assess compliance generally. For example, this Report could be used by the US Department of Health and Human Services for assessing whether entities covered by HIPAA are in compliance with administrative, technical and physical security standards.
- Cloud providers and brokers from the private sector, will, in all likelihood, seek to comply with the NIST cloud guidance in whole or in part in order to get federal agency business. This will likely become the “gold standard,” widely used by corporations in the private sector as requirements in their respective cloud services contracts, SLAs and provisions as well.
The Report sets forth a risk management process to ensure that issues are identified and mitigated early in the investment cycle with routine and periodic reviews. It does so by identifying a core set of security components (Annex A of the Report, the “Security Components”) that can be implemented in a cloud ecosystem to secure the environment, the operations, and the data migrated to the cloud, and providing for each cloud actor (consumer, cloud provider, cloud broker, etc.), the core set of Security Components that fall under their responsibilities depending on the deployment and service model (software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS)).
The security is analyzed using a six-step process, which is similar to the original Risk Management Framework for Federal Information Systems set forth in NIST SP 800-37:
- Step 1 – CATEGORIZE: the information system or service migrated to the cloud, and the information processed, stored, and transmitted by that system based on an impact analysis. This includes consideration of legislation, policies, directives, regulations, standards, and organizational mission/business/operational requirements.
- Step 2 – IDENTIFY: security requirements for the information system or service migrated to the cloud, and perform a risk assessment – including a Confidentiality, Integrity, and Availability (C/I/A) analysis – to identify the Security Components that are appropriate for the system. Select the baseline security control.
- Step 3 – SELECT: the cloud ecosystem architecture that best fits the analysis performed in Step 2 above for the information system or service migrated to the cloud.
- Step 4 – ASSESS: potential service provider(s) based on their official Authorization-To-Operate (ATO) (as a service provider for the federal agency). Identify the security controls needed for the cloud-based information system or service already implemented by the cloud provider, and negotiate the implementation of the additional Security Components and controls identified as necessary for this system or service. When applicable, identify the security controls that remain within the cloud consumer’s responsibility, and implement them.
- Step 5 – AUTHORIZE: the use of the selected cloud provider (and cloud broker, when applicable) for hosting the cloud-based information system or service. Negotiate a service agreement (SA) and service level agreement (SLA) that reflects the negotiation performed in Step 4.
- Step 6 – MONITOR: the cloud provider (and the cloud broker when applicable) to ensure that all SA and SLA terms are met and that the cloud-based information system maintains the necessary security posture. Directly monitor the Security Components and associated controls under the cloud consumer’s direct responsibility.
Pepper Point: It would be beneficial for companies in the private sector seeking to use cloud services to incorporate provisions from the cloud adapted risk management framework established in the Report into terms and conditions of contracts with cloud providers and cloud brokers. Contractual terms may include, among other provisions, guarantees of the consumer’s timely access to or receipt of cloud audit, monitoring and access logs.
Sharon R. Klein and Odia Kagan
The material in this publication was created as of the date set forth above and is based on laws, court decisions, administrative rulings and congressional materials that existed at that time, and should not be construed as legal advice or legal opinions on specific facts. The information in this publication is not intended to create, and the transmission and receipt of it does not constitute, a lawyer-client relationship.
View the PDF version