Cloud Security Requirements

This chapter incorporates the best practices discussed in the Cloud Security Alliance (CSA) Security Guidance for Critical Areas of Focus in Cloud Computing, Version 3.0, and the security control areas defined in the CSA Cloud Controls Matrix (CCM) for managing security risks associated with cloud computing. The security focus of this chapter is on Private and Private Community clouds, which CMS expects to host operational environments that have Low or Moderate system categorizations.

The CSA CCM contains a comprehensive list of control areas for consideration, mapped to the relevant NIST SP 800-53 controls. CMS has already provided guidance for most control areas in the CMS ARS. This topic sets forth CMS standards and guidance for implementing a subset of CCM controls areas that have special relevance in cloud environments. These areas are crucial to the security assessment of CMS cloud systems.

Note: Only the Federal Information Security Modernization Act (FISMA)-designated Authorizing Authority (the CMS CIO) can accept risks above and beyond the minimum federal requirements required under FISMA in NIST SP 800-53. For the most part, physical devices identified in the CMS TRA are replaced by logical (or virtual) devices when implemented in the cloud. Replacing physical devices with logical equivalents must be accompanied with compensating controls to avoid compromising security.

Cloud computing presents additional risks over traditional IT environments because of the virtualization of computing resources that must be properly managed to ensure the confidentiality, integrity, and availability (CIA) of CMS data. CMS requires a comprehensive approach that pays appropriate attention to the specific security challenges inherent in managing risk in cloud computing environments to ensure the CIA of CMS information and information systems.

PREFERRED

The CMS strategic implementation that supports these requirements is CMS Cloud. CMS Cloud maintains and secures its environments, leaving the application with primary responsibility for its Authority To Operate (ATO). CMS Cloud provides security and compliance capabilities that include:

• CMS approved security tools and services
• CMS Cloud compliance burden reduction
• Compliance-as-a-Service (CaaS/OpenControl)

Cloud Security Objectives

Regardless of environment, protecting sensitive data requires implementing and enforcing security controls to reduce the risk to the CIA of that data. Because of the technology for implementing clouds, the use of shared physical equipment, lack of visibility into the security management of the system, and reliance on the maturity of vendor processes and procedures, the risk in implementing a system in the vendor-operated federal cloud is likely higher than in an agency’s dedicated computer center.

Similar to traditional computing environments, cloud computing implementations are subject to local physical threats as well as external threats. These threat sources include accidents, natural disasters, external loss of service, hostile governments, criminal organizations, and terrorist groups. Additional threat sources are intentional or unintentional introduction of vulnerabilities through internal or external authorized or unauthorized human and system access, including but not limited to, employees, contractors, and intruders. The characteristics of cloud computing, including multi-tenancy and the variety of service and deployment models, underscore the need to consider data and systems protection within the context of logical as well as physical boundaries.

Cloud computing implementations include the following major security objectives:

• Preventing unauthorized access to cloud computing infrastructure resources. This includes implementing security domains that have logical separation between computing resources, e.g., logical separation of customer workloads running on the same server by VM monitors (hypervisors) in a multi-tenant environment and using secure-by-default configurations.

• Managing hypervisor threat vectors. Hypervisor attack threat vectors include CSP users and CSP employees. Hypervisor vulnerabilities include poor configurations, missed or delayed security patching, or unauthorized activities from a privileged user. Because hypervisor exploitation can have disastrous results, CMS mandates that all hypervisor solutions must be Type 1 (native / bare metal)-based products. Industry best practices should be implemented where available or the vendor’s own published guidelines should be used.

• Minimizing shared network access. Most CSPs have some common network infrastructure components between various cloud customers; these shared network infrastructure components present significant risk because a single breach of a shared component could compromise all users of a CSP’s service. Thus, configurations must adhere to best practices, and exceptions must be well understood, documented, and accepted by users of a CSP’s service.

• Managing privileged user access. CSP privileged users with access to the hypervisor should be kept at a minimum. CSPs should ensure the timely removal of access based on a CSP employee termination event or when access is no longer required (e.g., a job transfer). CSP targets for managing privileged user access in both cases should be real-time removal of access, audit records should be available to CMS auditors that establish when a request was made, and the actual removal of privilege.

• Ensuring that appropriate security safeguards are deployed at the CSP. CMS should conduct independent assessments to verify that appropriate safeguards are in place. This includes traditional perimeter security measures in combination with the additional safeguards required for cloud computing.

• Defining trust boundaries between CSPs and the CMS consumers. It is crucial to clearly document the responsibility for providing security and that the consequences for non-deployment of agreed-upon security controls by the CSP are well-defined in contracts and SLAs.

CMS Cloud Roles and Responsibilities

CMS has established its approach for implementing the guidance in NIST SP 800-37, Risk Management Framework to Federal Information Systems and Organizations. This topic describes how CMS applies this framework in the life cycle of cloud-based systems.

Operating in the cloud may introduce ambiguity about who is responsible for specific activities. Since ambiguity may lead to risk, CMS defines accountability for managing its CSP provider(s). The CMS Cloud Manager is responsible for managing the CSP. Only a CIO-designed cloud management organization may procure a cloud.

The table Table - Roles and Responsibilities in the Cloud (NIST Risk Management Framework) summarizes the cloud-specific guidance associated with managing a CSP.

Table - Roles and Responsibilities in the Cloud (NIST Risk Management Framework)

Activities	Cloud-Specific Roles / Guidance
Conduct Federal Information Processing Standards (FIPS) 199 security categorization	CMS CM, CMS business owner, and CMS ISPG.
Identify regulatory compliance requirements	CMS Chief Information Security Officer communicates all compliance requirements to the CMS CM. The CMS ARS and FedRAMP define all of the security requirements.
Analyze cloud deployment model options (Public, Private, Community, Hybrid) based on security categorization, HHS Cloud Computing, and CISO Cloud Standards guidance	CMS CM works with CMS business owners, ISPG, and other appropriate CMS organizations to define CSP requirements. CMS CM defines and acquires the appropriate cloud deployment model. CMS CM, Chief Information Security Officer (CISO), and CSP evaluate cloud architecture, and the CMS ARS controls selection.
Design, test, and integrate	In coordination with the CMS CM and ISPG, the CSP implements, tests, and documents the controls, including artifacts of compliance to regulatory requirements. Connectivity between a CSP and other CMS data centers will require a secure network solution and all required technical documentation. If both interconnecting systems have the same Authorizing Official (AO) or same primary operational IT infrastructure manager, an Interconnection Security Agreement is not required.
Conduct independent security test and evaluation	CSP hires a FedRAMP-certified third-party organization (3PAO) to conduct assessment of FedRAMP security controls related to the deployment model and additional control requirements mandated by CMS (such as, but not limited to, Health Insurance Portability and Accountability Act (HIPAA), Health Information Technology for Economic and Clinical Health (HITECH), etc.); CMS CM and ISPG perform an independent validation.
Government stakeholders may conduct audits—e.g., audits for Federal Tax Information, HIPAA, or the Office of the Inspector General (OIG)	CMS CM, along with ISPG, works with the CSP to determine how to support CMS and external assessments and audits.
Identify corrective actions for risks	CMS ISPG and the applicable FedRAMP Authorizing Organization records and manages the Plan of Action Milestones (POA&M) CSP supports actions required by the POA&M.
Manage authorization	Business owner submits Authority to Operate package. CMS ISPG makes risk-based ATO recommendation. CMS CIO makes risk tolerance-based ATO decision. CMS may leverage FedRAMP and HHS cloud authorizations where applicable.
Perform security continuous monitoring activities, including asset management, configuration management, vulnerability / patch management, and intrusion detection	CSPs must align their continuous monitoring to support CMS’s reporting and oversight requirements.

The FedRAMP and CMS ISPG govern all CMS policy and processes necessary for obtaining an ATO in or as a cloud environment at CMS. The CMS Policy for the Information Security Program and the RMH provide direction on achieving an Authorization to Operate in the CMS enterprise.

In managing risks within the cloud environment, the security of a platform (PaaS) depends on the controls’ effectiveness within the underlying infrastructure (IaaS); similarly, the security of an application depends on the effectiveness of the underlying platform and infrastructure. For this reason, the approval of the PaaS is contingent on whether the PaaS resides in an approved infrastructure, and the approval of a cloud-based application is contingent on whether the application resides in an approved PaaS and IaaS. In all cases, the PaaS security controls are the same whether the infrastructure supporting the PaaS resides in a traditional data center or is provided by a CSP.

FISMA reporting requirements apply to all systems that store or process government data. CMS will manage these requirements for the virtual instances where their services will run. CSPs will be required to provide Security Content Automation Protocol (SCAP)-compliant FISMA reporting information for the underlying cloud infrastructure and support systems, including hypervisors and all physical hosts that make up the cloud resources. These reports will include CMS-related cloud devices only and be delivered in the format and schedule dictated by FISMA reporting requirements.

Encryption and Key Management

Many CSPs offer encryption services to their customers. As CMS business owners require this service, the following requirements must be met:

• Where the CSP owns the encryption key(s), the encryption key must be different from CSP keys used to manage other CSP customers.
• The CSP CMS keys must be escrowed with CMS.
• CSPs should be able to demonstrate to CMS how the keys are managed and protected.
• The CSP must ensure that the assignment of a key manager adheres to segregation of duties (per the CMS ARS) and provides an option for CMS to perform its own key management.

Resource Traceability and Records Management

In a traditional physical data center deployment, system managers know precisely where data resides by physical server and storage device. In a cloud, data and applications will be allocated across several hardware units, some of which may be geographically disparate.

A CSP may move data securely between its various data center environments providing the CSP complies with CMS’s contractual agreement and their compliance has been documented a priori during the security authorization process. In addition, the CSP must have logging enabled to record where data resources are currently located and where they have been deployed. Depending on the data’s sensitivity (e.g., PII, PHI, and FTI) and records management requirements, CMS data stewards may have to account for where the data currently resides and where it has been to demonstrate the proper application of data life-cycle management.

In addition to the requirements placed on CSPs, business applications have federal records management requirements for data life cycles as well as data retention and records destruction.

Data Availability

Data management policy may require alternate solutions for managing data and keeping sensitive data outside of the cloud environment. Data management may require traditional hosting solutions with controls in place for following the chain of data authority and integrity. A review and understanding of the controls provided in the cloud environment for managing data must be clear and well documented.

Moving data into or out of the cloud requires careful planning and execution. Although data moving into or out of a cloud can use conventional methods for small data repositories, such as through files or programmatically, large amounts of data may require physical media that would need to be passed through the CSP to load into the cloud or be removed from the cloud. CSPs offer this type of service, which requires advanced coordination and planning.

Availability of Data

Archived data must meet National Archives and Records Administration (NARA) requirements and be stored in a format capable of meeting e-discovery needs. (Please refer to CMS Cloud Computing Standards for details.)

CSPs must meet the data needs for security forensic analysis by following CMS ARS Audit and Accountability (AU) requirements.

Data Protection

CMS must require the CSP to safeguard any confidential information (such as PII, PHI,and FTI) in compliance with Agency standards and to comply with all applicable regulatory reporting requirements.

In a multi-tenant environment, confidential data must be protected using a combination of access control, contractual liability, and encryption.

Solutions are needed for protecting data under the following circumstances. Depending on the type of cloud service, the solution can be supplied either by the CSP or by CMS:

• Backup to tape or disk (IaaS or PaaS)
• Archived data (PaaS)
• Removal of disk for repair (IaaS)
• Protection of data between and in disaster recovery sites (IaaS)
• Data extracts sent to partners (PaaS, SaaS, or CMS)
• Shared / consolidated storage used by multiple organizations (IaaS or PaaS)
• Protection from insider theft (service provider employees) (IaaS, PaaS, or SaaS)

Detective Controls for Mitigating Cloud-Specific Risks

The architecture of cloud computing environments presents challenges that do not exist in traditional computing environments. Cloud implementations may simulate the standard multi-tier architecture; however, this is only a simulation of a defense-in-depth strategy implemented at the infrastructure and hypervisor levels. The ability to maintain the security profile of this zone simulation requires both good configuration management, which reduces the likelihood of misconfigurations that would expose the system and data to risk, and appropriate responses to exploits that would compromise the pieces of the architecture that enforce access control and separation between tiers.

The major threats to the confidentiality, integrity, and availability of CMS systems and data are:

• Misconfigurations
  • Accidental misconfigurations
  • Delayed security patching
  • Insider threats
• Process and procedural immaturity
• Operational procedures
• Management oversight

Several detection techniques can be implemented to reduce the risk of these threats to better realize the potential benefits of using the cloud. The ensuing subtopics address proposed requirements for detective techniques to mitigate the risk of operating a multi-tier system in a cloud environment.

The multi-tier architecture is implemented as multiple VLANs through a network interface on the cloud infrastructure; zone separation is provided by either physical firewalls or by virtual firewalls.

A cloud implementation of a multi-tier architecture is dependent on the infrastructure components and the hypervisor to enforce the architecture. Misconfiguration of shared CSP devices (i.e., devices shared with non-CMS customers and/or devices not under the direct control of CMS) or the hypervisor makes the CMS systems vulnerable. Thus, detection techniques focus on ways to quickly identify and remediate misconfiguration of these key components, whether the result of unintentional errors or malicious activity.

The following technical measures are intended to detect component misconfiguration.

Firewall Modification Detection

The following requirements are for firewalls not under CMS’s direct control:

• Any changes to the firewall (rules, configuration, etc.) must automatically generate an alert.

• Real-time security-relevant events on the firewall must be audited.

• Audit logs for indications of inappropriate or unusual activity must be reviewed in a timely manner.

• Unauthorized firewall modifications must be reported to the CMS security team within 60 minutes (as required by OMB Memorandum M-07-16) if these modifications have not been identified as a false-positive result.

Hypervisor Modification Detection

The following requirements are for hypervisor oversight:

• Any changes to the networking configuration of the hypervisor must automatically generate an alert.

• Real-time security-relevant events on the hypervisor must be audited.

• Hypervisor audit logs must be audited weekly for indications of inappropriate or unusual activity.

• Unauthorized modifications to the hypervisor must be reported to the CMS security team within 60 minutes (as required by OMB Memorandum M-07-16) if they have not been identified as a false-positive result.

Network Infrastructure Modification Detection

The following requirements are for network devices not under the direct control of CMS:

• Security-relevant events of the underlying infrastructure and network IDS must be audited in real time for indications of inappropriate or unusual activity.

• Audit logs of network infrastructure devices, such as network IDS monitors, alert logs, etc., must be reviewed weekly for indications of inappropriate or unusual activity.

• Unauthorized modifications to network infrastructure must be reported to the CMS security team within 60 minutes (as required by OMB Memorandum M-07-16) if they have not been identified as a false-positive result.

Administrative Network Port Scans

The following requirements are for network devices not under the direct control of CMS:

• Cloud management infrastructure devices must be scanned daily to identify any undocumented or unauthorized ports.

• Unauthorized ports and protocols must be reported to the CMS security team within 60 minutes (as required by OMB Memorandum M-07-16) if they have not been identified as false-positive results.

Management Detective Controls

Management oversight by the CSPs provides the government with insight into how its cloud is managed and confidence that it is managed securely. The detection management controls permit the government to identify patterns or weaknesses that could compromise the security of its cloud.

Weekly Verification Report

On a weekly basis, summary reports must be provided to CMS to document infrastructure and hypervisor modifications, to confirm that change requests have been verified, and to report any unaccounted for or unapproved modifications with all corresponding corrective actions taken.

Definitions

This chapter relies on the NIST SP 800-145, The NIST Definition of Cloud Computing, September 2011, as the authoritative source for cloud terminology. Visual Model of NIST Working Definition of Cloud Computing shows a visual model of the NIST Cloud model.

Table - NIST Definitions identifies the key terms and NIST definitions for Cloud computing.

Table - NIST Definitions

Term	Definition
Private Cloud	The cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premises or off premises.
Community Cloud	The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on premises or off premises.
Public Cloud	The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.
Hybrid Cloud	The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., for load balancing between clouds).
Infrastructure as a Service (IaaS)	The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).
Platform as a Service (PaaS)	The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.
Software as a Service (SaaS)	The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a Web browser (e.g., Web-based email). The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Other terms commonly used when addressing cloud and virtualized environments include:

• Virtual Machine – An instance of an operating system variant (e.g., Linux) running under the control of a hypervisor.

• Bursting – The ability to increase VM resources, such as processor, memory, or storage capability, provided as a service by the CSP.

• Elasticity – The ability to add or subtract VMs for use by a business application, implemented through configuration of the application platform (PaaS).