A Case Study for Cloud Service Providers

CHAPTER

A Case Study for Cloud Service Providers

13

INFORMATION IN THIS CHAPTER: • Case Study Scenario: “Healthcare Exchange” • Applying the Risk Management Framework within FedRAMP

CASE STUDY SCENARIO: “HEALTHCARE EXCHANGE” The Patient Privacy and Protection Act,1 recently signed into law, creates a new requirement for patient healthcare exchanges to be built, herein referred to as “Healthcare Exchange.” The “Federal Agency” responsible for implementing the requirements of the law has chosen to use an operating expense model instead of a capital expense model, and usage-based pricing for processing, storage, bandwidth, and license management, and to support elasticity as demand for computing resources may change over time. Since the “Federal Agency” will require collaboration with external partners to support the development of State “Healthcare Exchanges,” the “Federal Agency” has chosen to acquire Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) environments from one provider to support the delivery of a computing platform and an application platform (similar to the cloud configuration use case included in Figure 13.1) where the States could build, test, deploy, and run portable, interoperable, and secure State “Healthcare Exchanges.” This enables the “Federal Agency” to quickly meet its requirements under the new law. In addition, the IaaS/PaaS environments will be used by other federal agencies to support the development of a Federal “Healthcare Exchange” and other functions required to share information between State and federal government entities. The cloud computing environment will also be used to support a “Federal Agency” mission and will contain federal information and information systems. Therefore, the infrastructure and platform environment of the cloud computing stack will be required to address federal cloud computing security standards. To reduce the complexity, the scenario will be limited to a discussion of only the Federal “Healthcare Exchange.” The cloud computing infrastructure (IaaS/PaaS) will be required to address not only federal information security requirements under FedRAMP, but 1This Act

is fictitious and does not exist.

Federal Cloud Computing. http://dx.doi.org/10.1016/B978-1-59-749737-4.00013-7 © 2013 Elsevier, Inc. All rights reserved.

395

396

CHAPTER 13  A Case Study for Cloud Service Providers

FIGURE 13.1  IaaS/PaaS Cloud Configuration Use Case [16]

also to meet all data management safeguard requirements required for the protection of Personally Identifiable Information (PII), Personal Health Information (PHI), and Federal Tax Information (FTI) data. In this chapter, we will discuss the application of the FedRAMP deliverable documents to the FedRAMP Security Assessment Process Area included within Figure 13.2 under the Cloud Service Provider column. The case study in this section will be used to support the discussion.

APPLYING THE RISK MANAGEMENT FRAMEWORK WITHIN FEDRAMP This section will focus on the application of Steps 1–5 of the NIST Risk Management Framework (RMF), which corresponds to Steps 1.1–1.3 of the Federal Risk and Authorization Management Program (FedRAMP) Security Assessment Process Area. The case study provided in the last section will be used as a basis for illustrating how to approach using the FedRAMP deliverables to support a FedRAMP Provisional Authorization. Figure 13.3 provides the roadmap for the topics that will be presented.

Categorize Information System The Cloud Service Provider (CSP) must identify the applicable information types and conduct a security categorization2 of the cloud service to determine the impact level. As depicted in Figure 13.4, the CSP can use available federal governmental standards, guidelines, and regulations, and industry-specific “best practices” to assist in establishing a characterization of types of information currently stored, processed, or transmitted in the cloud service environment. The Federal Information Processing Standard (FIPS) 199 analysis represents the information type and sensitivity levels of the CSP’s cloud service offering and is not intended to include sensitivity levels for federal

2Security categorization is discussed in detail in Chapter 5, Applying the Risk Management Framework.

Applying the Risk Management Framework within FedRAMP

FIGURE 13.2  FedRAMP Security Assessment Process Area [1]

FIGURE 13.3  Mapping between FedRAMP Security Assessment Processes Area and NIST RMF Steps

agency customer data, because they will be expected to perform a separate FIPS 199 analysis for federal information hosted on the CSP’s cloud environment [15].

397

FIGURE 13.4  Role of Cloud Service Provider in the Security Categorization Process

398 CHAPTER 13  A Case Study for Cloud Service Providers

Applying the Risk Management Framework within FedRAMP

Once the CSP has identified all the potential information types, the CSP will need to document this information in the FIPS 199.3 In documenting the FIPS 199, the CSP will need to provide an overview of the cloud service (i.e., high-level system description). Cloud services generally operate through the concept of a shared responsibility model, where both the CSP and the “Federal Agency” consumer will share the responsibility4 for specific aspects of securing the cloud environment. Therefore the FIPS 199 completed by the CSP will need to address only5 the information types and sensitivity levels of the cloud service for which the CSP is responsible. For example, Table 13.1 provides the information types that may be applicable to the IaaS and PaaS provider. However, if the CSP operated a Software as a Service (SaaS) cloud service, all applicable information types will need to be examined. This may require the CSP to become familiar with the specific business use cases6 and the types of information that the “Federal Agency” customer would process, store, or transmit in the cloud environment as a basis for determining the security categorization of the cloud service. This activity would be accomplished by using publicly available information from government-wide or agency-specific Federal Enterprise Architecture (FEA)7 or Federal Segment Architecture (FSA) documentation.8 A segment architecture is a “detailed results-oriented architecture (baseline and target) and a transition strategy for a portion or segment9 of the enterprise” [3]. Tables 13.2–13.4 provide a list of potential information

3From FedRAMP Program Management Office (PMO). FedRAMP Template and Process Quick Guide. Washington: US General Services Administration; 2012. “The Federal Information Processing Standard 199 (FIPS-199) Categorization (Security Categorization) report is a key document in the security authorization package developed for submission to the Federal Risk and Authorization Management Program (FedRAMP) authorizing officials. The FIPS-199 Categorization report includes the determination of the security impact level for the cloud environment that may host any or all of the service models (Information as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). The ultimate goal of the security categorization is for the cloud service provider (CSP) to be able to select and implement the FedRAMP security controls applicable to its environment.” 4From FedRAMP Program Management Office (PMO). FedRAMP Concept of Operations (CONOPS) Version 1.1. Washington: US General Services Administration; 2012. The Control Implementation Summary (CIS) document is used to enable the CSP to delineate where both the CSP and a federal agency may have a shared responsibility. 5From FedRAMP Program Management Office (PMO). Guide to Understanding FedRAMP Version 1.1. Washington: US General Services Administration; 2012. “Customer agencies will be performing a separate FIPS 199 analysis for their customer owned data hosted on the system.” 6NIST Cloud Computing Business Use Cases Working Group. Available from: http://collaborate.nist. gov/twiki-cloud-computing/bin/view/CloudComputing/BusinessUseCases. 7Federal Enterprise Architecture (FEA). Available from: http://www.whitehouse.gov/omb/e-gov/fea. 8Federal Segment Architecture Methodology (FSAM). Available from: www.cio.gov/documents/ fsamv1.pdf. 9From Architecture and Infrastructure Committee. Federal Segment Architecture Methodology Version 1.0. Washington: CIO Council; 2008. “A business service segment includes common or shared business services supporting the core mission areas.”

399

400

CHAPTER 13  A Case Study for Cloud Service Providers

Table 13.1 IaaS and PaaS Information Types [2] Information Type

Description

C.3.5.1 System Development Information Type C.3.5.2 ­Lifecycle/ Change ­Management Information Type

System Development supports all activities associated with the in-house design and development of software applications.

C.3.5.3 System Maintenance ­Information Type C.3.5.4 IT ­Infrastructure Maintenance ­Information Type

C.3.5.5 ­Information ­Security ­Information Type C.3.5.6 Record Retention ­Information Type C.3.5.7 ­Information ­Management Information Type C.3.5.8 System and Network ­Monitoring I­nformation Type C.3.5.9 ­Information ­Sharing ­Information Type

Lifecycle/Change Management involves the processes that facilitate a smooth evolution, composition, and workforce transition of the design and implementation of changes to agency resources such as assets, methodologies, systems, or procedures. System Maintenance supports all activities associated with the maintenance of in-house designed software applications. IT Infrastructure Maintenance involves the planning, design, implementation, and maintenance of an IT infrastructure to effectively support automated needs (i.e., operating systems, applications software, platforms, networks, servers, printers, etc.). IT infrastructure maintenance also includes information systems configuration and security policy enforcement information. This information includes password files, network access rules and implementing files and/or switch setting, hardware and software configuration settings, and documentation that may affect access to the information system’s data, programs, and/or processes. IT Security involves all functions pertaining to the securing of federal data and systems through the creation and definition of security policies, procedures, and controls covering such services as identification, authentication, and non-repudiation. Records Retention involves the operations surrounding the management of the official documents and records for an agency. Information Management involves the coordination of information collection, storage, and dissemination, and destruction as well as managing the policies, guidelines, and standards regarding information management. System and Network Monitoring supports all activities related to the real-time monitoring of systems and networks for optimal performance. The BRM provided in the FEA Consolidated Reference Model Document, Version 2.3, October 2007 specifies Information Sharing as relating to any method or function, for a given business area, facilitating: data being received in a usable medium by one or more departments or agencies as provided by a separate department or agency or other entity; and data being provided, disseminated, or otherwise made available or accessible by one department or agency for use by one or more separate departments or agencies, or other entities, as appropriate.

Applying the Risk Management Framework within FedRAMP

Table 13.2 Service Delivery Support Information Types [2] (continued) Information Type

Confidentiality

Controls and Oversight Corrective Action Low (Policy/Regulation) Program Evaluation Low Program Monitoring Low Regulatory Development Policy and Guidance Low Development Public Comment Low Tracking Regulatory Creation Low Rule Publication Low Planning and Budgeting Budget Formulation Low Capital Planning Low Enterprise Low Architecture Strategic Planning Low Budget Execution Low Workforce Planning Low Management Low Improvement Budgeting and Per- Low formance Integration Tax and Fiscal Policy Low Internal Risk Management and Mitigation Contingency Moderate Planning Continuity of Moderate Operations Service Recovery Low Revenue Collection Debt Collection Moderate User Fee Collection Low Federal Asset Sales Low Public Affairs Customer Services Low Official Information Low Dissemination Product Outreach Low Public Relations Low Legislative Relations Legislation Tracking Low

Integrity

Availability

Low

Low

Low Low

Low Low

Low

Low

Low

Low

Low Low

Low Low

Low Low Low

Low Low Low

Low Low Low Low

Low Low Low Low

Low

Low

Low

Low

Moderate

Moderate

Moderate

Moderate

Low

Low

Low Low Moderate

Low Moderate Low

Low Low

Low Low

Low Low

Low Low

Low

Low

401

402

CHAPTER 13  A Case Study for Cloud Service Providers

Table 13.2 Service Delivery Support Information Types [2] (continued  ) Information Type

Confidentiality

Integrity

Availability

Legislation Testimony Proposal Development Congressional Liaison Operations General Government Central Fiscal Operations Legislative Functions Executive Functions Central Property Management Central Personnel Management Taxation Management Central Records and Statistics Management Income Information Personal Identity and Authentication Entitlement Event Information Representative Payee Information General Information

Low

Low

Low

Moderate

Low

Low

Moderate

Low

Low

Moderate

Low

Low

Low Low Low

Low Low Low

Low Low Low

Low

Low

Low

Moderate

Low

Low

Moderate

Low

Low

Moderate Moderate

Moderate Moderate

Moderate Moderate

Moderate

Moderate

Moderate

Moderate

Moderate

Moderate

Low

Low

Low

Table 13.3 Resource Management Information Types [2] Information Type Administrative Management Facilities, Fleet, and Equipment Mgmt Help Desk Services Security Management Travel Workplace Policy Development and Management Financial Management Asset and Liability Management

Confidentiality

Integrity

Availability

Low

Low

Low

Low Moderate Low Low

Low Moderate Low Low

Low Low Low Low

Low

Low

Low

Applying the Risk Management Framework within FedRAMP

Table 13.3 Resource Management Information Types [2] (continued  ) Information Type

Confidentiality

Reporting and Information Low Funds Control Moderate Accounting Low Payments Low Collections and Low Receivables Cost Accounting/ PerforLow mance Measurement Human Resource Management HR Strategy Low Staff Acquisition Low Organization and Position Low Management Compensation Low Management Benefits Management Low Employee Performance Low Management Employee Relations Low Labor Relations Low Separation Management Low Human Resources Low Development Supply Chain Management Goods Acquisition Low Inventory Control Low Logistics Management Low Services Acquisition Low Information and Technology Management System Development Low Lifecycle/Change Low Management System Maintenance Low IT Infrastructure Low Maintenance Information System Low Security Record Retention Low Information Management Low System and Network Moderate Monitoring Information Sharing N/A

Integrity

Availability

Moderate Moderate Moderate Moderate Moderate

Low Low Low Low Low

Moderate

Low

Low Low Low

Low Low Low

Low

Low

Low Low

Low Low

Low Low Low Low

Low Low Low Low

Low Low Low Low

Low Low Low Low

Moderate Moderate

Low Low

Moderate Low

Low Low

Moderate

Low

Low Moderate Moderate

Low Low Low

N/A

N/A

403

404

CHAPTER 13  A Case Study for Cloud Service Providers

Table 13.4 Mission-Based Information Types [2] Information Type

Confidentiality

Integrity

Availability

Defense and National Security

Nat’l Security

Nat’l Security

Nat’l Security

Moderate

Moderate

High

High

High Moderate

High High

High

High

High

High

Low

Low

Low

Low

High

High

High Low

Moderate Low

High

High

Low

Low

Low

Low

Low

Low

Low

Low

Moderate Low

Moderate Low

Low

Low

Low

Low

Moderate

Low

Low

Low

Homeland Security Border Control and TransModerate portation Security Key Asset and Critical InfraHigh structure Protection Catastrophic Defense High Executive Functions of the High EOP Intelligence Operations High Disaster Management Disaster Monitoring and Low Prediction Disaster Preparedness and Low Planning Disaster Repair and Low Restoration Emergency Response Low International Affairs and Commerce Foreign Affairs High International Development Moderate and Humanitarian Aid Global Trade High Natural Resources Water Resource Low Management Conservation, Marine, and Low Land Management Recreational Resource Man- Low agement and Tourism Agricultural Innovation and Low Services Energy Energy Supply Low Energy Conservation and Low Preparedness Energy Resource Moderate Management Energy Production Low Environmental Management Environmental Monitoring/ Low Forecasting Environmental Remediation Moderate

Applying the Risk Management Framework within FedRAMP

Table 13.4 Mission-Based Information Types [2] (continued  ) Information Type

Confidentiality

Integrity

Availability

Defense and National Security

Nat’l Security

Nat’l Security

Nat’l Security

Pollution Prevention and Low Control Economic Development Business and Industry Low Development Intellectual Property Low Protection Financial Sector Oversight Moderate Industry Sector Income Moderate Stabilization Community and Social Services Homeownership Promotion Low Community and Regional Low Development Social Services Low Postal Services Low Transportation Ground Transportation Low Water Transportation Low Air Transportation Low Space Operations Low Education Elementary, Secondary, and Low Vocational Education Higher Education Low Cultural and Historic Low Preservation Cultural and Historic Low Exhibition Workforce Management Training and Employment Low Labor Rights Management Low Worker Safety Low Health Access to Care Low Population Health ManageLow ment and Consumer Safety Health Care Administration Low Health Care Delivery Services Low Health Care Research and Low Practitioner Education

Low

Low

Low

Low

Low

Low

Low Low

Low Low

Low Low

Low Low

Low Moderate

Low Moderate

Low Low Low High

Low Low Low High

Low

Low

Low Low

Low Low

Low

Low

Low Low Low

Low Low Low

Moderate Moderate

Low Low

Moderate High Moderate

Low Low Low

405

406

CHAPTER 13  A Case Study for Cloud Service Providers

Table 13.4 Mission-Based Information Types [2] (continued  ) Information Type

Confidentiality

Integrity

Availability

Defense and National Security

Nat’l Security

Nat’l Security

Nat’l Security

Moderate

Moderate

Low

Low

Low Low

Low Low

Low

Low

Low Moderate

Moderate Moderate

Moderate Low Low Moderate Low Moderate

Moderate Low Low Moderate Low Moderate

Low High Moderate Moderate

Low Low Moderate Low

Low

Low

Moderate Low

Low Low

Moderate

Low

Moderate

Low

Moderate

Low

Income Security General Retirement and Moderate Disability Unemployment Low Compensation Housing Assistance Low Food and Nutrition Low Assistance Survivor Compensation Low Law Enforcement Criminal Apprehension Low Criminal Investigation and Moderate Surveillance Citizen Protection Moderate Leadership Protection Moderate Property Protection Low Substance Control Moderate Crime Prevention Low Trade Law Enforcement Moderate Litigation and Judicial Activities Judicial Hearings Moderate Legal Defense Moderate Legal Investigation Moderate Legal Prosecution and Low Litigation Resolution Facilitation Moderate Federal Correctional Activities Criminal Incarceration Low Criminal Rehabilitation Low General Science and Innovation Scientific and Technological Low Research and Innovation Space Exploration and Low Innovation Knowledge Creation and Management Research and Development Low

Applying the Risk Management Framework within FedRAMP

Table 13.4 Mission-Based Information Types [2] (continued  ) Information Type

Confidentiality

Integrity

Availability

Defense and National Security

Nat’l Security

Nat’l Security

Nat’l Security

Low

Low

Low Low

Low Low

Moderate Low

Low Low

Low

Low

Low Low Low

Low Low Low

Low

Low

Low Low

Low Low

Low Low

Low Low

Low Low Low

Low Low Low

Low Low Low Low

Low Low Low Low

N/A N/A

N/A N/A

General Purpose Data and Low Statistics Advising and Consulting Low Knowledge Dissemination Low Regulatory Compliance and Enforcement Inspections and Auditing Moderate Standards Setting/ ReportLow ing Guideline Development Permits and Licensing Low Public Goods Creation and Management Manufacturing Low Construction Low Public Resources, FacilLow ity, and Infrastructure Management Information Infrastructure Low Management Federal Financial Assistance Federal Grants (Non-State) Low Direct Transfers to Low Individuals Subsidies Low Tax Credits Moderate Credits and Insurance Direct Loans Low Loan Guarantees Low General Insurance Low Transfers to State/Local Governments Formula Grants Low Project/Competitive Grants Low Earmarked Grants Low State Loans Low Direct Services for Citizens Military Operations N/A Civilian Operations N/A

407

408

CHAPTER 13  A Case Study for Cloud Service Providers

TIP If the CSP determines, through a review of the recommended impact levels, that there are differences in the selected impact levels, the CSP will need to provide justification (rationale) for any changes. During the review, the following factors [5] can be used to assist the CSP in determining if the impact levels should be adjusted based on the applicable security objectives: • Sensitivity of change of information when aggregated. • Compromise in critical system functionality. • Elevation based on extenuating circumstances. • Integrity of public information, loss of system availability, privacy information, etc.

types and the recommended (provisional10) impact levels for the confidentiality, integrity, and availability security objective of Low, Moderate, or High.11 In addition, the CSP will need to ensure the “Federal Agency” customer using the cloud service collects, processes, or stores information types that do not exceed the high-water mark of low- or moderate-impact level for the confidentiality, integrity, and availability security objectives [4]. The role of the “Federal Agency” in the security categorization process is the characterization of the information that it plans to store, process, or transmit in the cloud service. The application of the security categorization ­process by the “Federal Agency” will require an evaluation of multiple sources of information,12 to include, but not limited to, the organizational input from key stakeholders (e.g., other federal agencies and State partners), the architectural descriptions of the “Healthcare Exchange,” and EA reference models used to establish a business case13 as the basis for determining the security objectives for the types of information that will be processed, transmitted, or stored in the cloud service.

10From Stine, K., Kissel, R., Barker, W., Fahlsing, J., Gulick J. NIST Special Publication (SP) 800-60 Revision 1, Volume I: Guide for Mapping Types of Information and Information Systems to Security Categories. Maryland: National Institute of Standards and Technology; 2008. “Provisional security impact levels are the initial or conditional impact determinations made until all considerations are fully reviewed, analyzed, and accepted in the subsequent categorization steps by appropriate officials.” 11Note, FedRAMP does not currently address “high-impact” sensitivity levels. 12It is important to understand that not all information might be available, however, since the security categorization effects the other steps of the NIST RMF, a regular review may be required to identify any changes that would have impact. 13From Office of Management and Budget (OMB). FY13 Guidance on Exhibit 300—Planning, Budgeting, Acquisition, and Management of IT Capital Assets. Washington: Executive Office of the President, Office of Management and Budget; 2011. “The business case must demonstrate the relationship between the investment and the business, performance, data, services, application and technology layers of the agency’s EA.”

Applying the Risk Management Framework within FedRAMP

FIGURE 13.5  Exchange Reference Architecture Framework

The “Federal Agency” established a business case14 for the “Healthcare Exchange” IT Investment. The “Healthcare Exchange” provides a platform for organizing health information. The “Federal Agency” identified two mission-essential functions ­supported by the IT Investment Exchange Systems and Data Services. Through an evaluation of the architectural descriptions (e.g., architecture reference models, mission, and business processes, etc.) and organizational inputs (laws, directives, policy guidance, etc.), specific mission-based information15 and management and support information16 can be identified and categorized using information associated with the “Healthcare Exchange” as a point of reference to understand the potential impact due to a compromise in the confidentiality (C), integrity (I), and availability (A). The “Federal Agency” established Exchange Reference Architecture,17 as illustrated in Figure 13.5, defines the key business information and technical areas and

14A business case assists stakeholders in making decisions regarding the viability of a proposed project effort. The Office of Management and Budget (OMB) requires a business case as part of Part 7, Section 300. Additionally, business cases are considered standard practice throughout private and public industry in addition to specific laws and regulations that mandate business cases for certain project types. 15Information that is specific to individual departments and agencies or sets of departments and agencies. 16Information that supports the delivery of services or the management of resources. 17From Office of Management and Budget (OMB). The Common Approach to Federal Enterprise Architecture. Washington: Executive Office of the President, Office of Management and Budget; 2012. “A ‘Reference Architecture’ is an authoritative source of information about a specific subject area that guides and constrains the instantiations of multiple architectures and solutions.”

409

410

CHAPTER 13  A Case Study for Cloud Service Providers

Table 13.5 Key Data Definitions Term

Definition

PII

As defined in OMB Memorandum M-07-16, PII refers to any “information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc.” [7] The HIPAA Privacy Rule defines PHI as individually identifiable health information that is held or transmitted in any form or medium by a covered entity [8] HIPAA defines IIHI as any information, including demographic information, collected from an individual that is created or received by a health care provider, health plan, employer or health care clearinghouse, and relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual, and identifies the individual or where there is a reasonable basis to believe that the information can be used to identify the individual [9] Federal Tax Returns and return information are confidential, as required by IRC Section 6103. The IRS uses the IRC to ensure that agencies, bodies, and commissions maintain appropriate safeguards to protect the information confidentiality [10]

PHI IIHI

FTI

also provides a high-level view of the Business Architecture (BRM),18 Information Architecture (DRM),19 and Technical Reference Architecture (TRM).20 The Exchange References Architecture21 provides the description of the core business areas and processes in the Business Architecture that will be used to exchange information defined in the Information Architecture and supported through the implementation of the business and information requirements in the Technical Reference Architecture. The “Federal Agency” also identified key data types in Table 13.5 to use as a basis for characterizing the types of information that will require the highest level of 18From Office of Management and Budget (OMB). FY2014 Guide on Exhibit 53 and 300—Information Technology and E-Government. Washington: Executive Office of the President, Office of Management and Budget; 2012. “Business Reference Model (BRM) a classification taxonomy used to describe mission sectors, business functions, and services that are performed within and between Federal agencies and with external partners.” 19From Office of Management and Budget (OMB).Consolidated Reference Model Version 2.3. Washington: Executive Office of the President, Office of Management and Budget; 2007. Data Reference Model is “a flexible and standards-based framework to enable information sharing and reuse across the federal government via the standard description and discovery of common data and the promotion of uniform data management practices.” 20From Office of Management and Budget (OMB). Consolidated Reference Model Version 2.3. Washington: Executive Office of the President, Office of Management and Budget; 2007. Technical Reference Model (TRM) is a “technical framework categorizing the standards and technologies to support and enable the delivery of Service Components and capabilities.” 21Similar to the role of the enterprise architecture discussed in detail in Chapter 5, Applying the NIST Risk Management Framework.

Applying the Risk Management Framework within FedRAMP

TIP Depending on which cloud service model (IaaS, PaaS, SaaS) and deployment model (public, hybrid, private, community) is chosen as part of the implementation, the cloud service may become part of or completely (in circumstances where the entire business and mission function is outsourced) integrated into federal agencies’ enterprise architecture (EA). This dependence by federal agencies can introduce many challenges when applying the RMF to cloud services. The Federal Cloud Computing Strategy highlighted, as part of the “Decision Framework for Cloud Migration,” the need for federal agencies to provision cloud services by integrating them into their wider application portfolio. This will require federal agencies to evaluate architectural compatibility of the cloud services and other critical applications [6]. EA, as a tool, provides federal agencies with a structured approach for ensuring the interoperability, portability, and security of cloud computing adoption through coordination with the federal government EA programs. EA can also assist in determining the requirements for addressing governance, risk management, and compliance (GRC) (see Figure 13.4).

protection when conducting security categorization. In addition, a list of related laws, standards, guidelines, and organizational agreements for consideration was developed and mapped against the “Healthcare Exchange” participants as organizational inputs into the security categorization process. Based on the case study used in this section, several potential information types may be selected by the “Federal Agency” such as: • SC Access to Care Information Type22 = {(confidentiality, Low), (integrity, Moderate), (availability, Low)}. • SC Health Care Delivery Services Information Type23 = {(confidentiality, Low), (integrity, High), (availability, Low)}. • SC Taxation Management Information Type24 = {(confidentiality, Moderate), (integrity, Low), (availability, Low)}. 22From Stine, K., Kissel, R., Barker, W., Lee, A., Fahlsing, J. NIST Special Publication (SP) 800-60 Revision 1, Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories. Maryland: National Institute of Standards and Technology; 2008. This information includes streamlining efforts to receive care; ensuring care is appropriate in terms of type, care, intensity, location and availability; providing seamless access to health knowledge, enrolling providers; performing eligibility determination, and managing patient movement. 23From Stine, K., Kissel, R., Barker, W., Lee, A., Fahlsing, J. NIST Special Publication (SP) 800-60 Revision 1, Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories. Maryland: National Institute of Standards and Technology; 2008. This information includes assessing health status; planning health services; ensuring quality of services and continuity of care; and managing clinical information and documentation. 24From Stine, K., Kissel, R., Barker, W., Lee, A., Fahlsing, J. NIST Special Publication (SP) 800-60 Revision 1, Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories. Maryland: National Institute of Standards and Technology; 2008. This information includes activities associated with the implementation of the Internal Revenue Code and the collection of taxes in the United States and abroad.

411

412

CHAPTER 13  A Case Study for Cloud Service Providers

FIGURE 13.6  Laws, Required Standards, and Guidance

Select Security Controls The security control selection process relies on the definition of the security control boundary and a clear delineation of the security controls responsibility across service and deployment models. It also requires an understanding of any decomposition of cloud services into associated subsystems and the mapping of data flows to ensure adequate protective measures are applied cost-effectively to sensitive data throughout the cloud service lifecycle. The implementation of the “Healthcare Exchange” includes a complicated set of security and privacy requirements. Figure 13.6 illustrates the different requirements derived from various laws, requirements, standards, guidelines, and control frameworks, in addition to any organization-specific requirements established by the information-sharing agreement.25 For example, under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security Rule, covered entities “must comply with the Rules’ requirements to protect the privacy and security of health information and must provide individuals with certain rights with respect to their health information” [11]. These requirements could include the additional

25From Grance, T., Hash, J., Peck, S., Smith, J., Korow-Diks, K. NIST Special Publication (SP) 80047, Security Guide for Interconnecting Information Technology Systems. Maryland: National Institute of Standards and Technology; 2002. “Organizations should examine privacy issues related to data that will be exchanged or passed over the interconnection and determine whether such use is restricted under current statutes, regulations, or policies.”

Applying the Risk Management Framework within FedRAMP

administrative, physical, and technical safeguards that exceed the security control requirements defined in the FedRAMP baseline security controls.26

Defining the Boundary The first step in the security control selection process is to define the boundary.27 This provides the scope of protection for the system components and interfaces for interconnections and is critical for understanding and clarifying the shared responsibilities for implementing, monitoring, and assessing security controls allocated28 across the various cloud service and deployment models. Although only conceptual, Figure 13.7 provides a high-level illustration of the factors that might be considered when allocating security controls and assigning ownership between the CSP and the “Federal Agency.” For example, identifying those controls which are inherited from one or more organizations (common controls) or are shared between one or more organizations (hybrid controls), requires establishing roles and responsibilities based on the different deployment models and service models. In addition, establishing a definition of both the authorization boundary and the level of control of the resources can help clarify the delineation of the specific aspects being inherited. For security control allocation to be successful, in most cases it requires building trusted relationships based on the sharing of evidence that specific security controls are implemented, including any assessment results (or a summary) and information collected as part of an ongoing continuous monitoring program. The Control Implementation Summary (CIS)29 will be used by the CSP to indicate who owns the responsibility (or the shared responsibility) to implement and manage the controls, and the implementation status of the controls [12]. In this scenario the CSP provides the implementation status (i.e., in-place, partially implemented, planned, alternative implementation, and not applicable) for security control implementations that relates to the infrastructure and the platform, 26NIST Special Publication (SP) 800-66 Revision 1, Introductory Resource Guide for Implementing the HIPAA Security Rule, discusses security considerations and resources for use when implementing the requirements of the Security Rule. 27From Joint Task Force Transformation Initiative, NIST Special Publication (SP) 800-53 Revision 3, Recommended Security Controls for Federal Information System and Organizations. Maryland: National Institute of Standards and Technology; 2010. “Well-defined boundaries establish the scope of protection for organizational information systems (i.e. what the organization agrees to protect under its direct management control or within the scope of its responsibilities) and include the people, processes, and information technologies that are part of the systems supporting the organization’s missions and business processes.” 28From Joint Task Force Transformation Initiative, NIST Special Publication (SP) 800-53 Revision 3, Recommended Security Controls for Federal Information System and Organizations. Maryland: National Institute of Standards and Technology; 2010. “Allocation is a term used to describe the process an organization employs: (i) to determine whether security controls are defined as system-specific, hybrid, or common; and (ii) to assign security controls to specific information system components responsible for providing a particular security capability (e.g. router, server, remote sensor).” 29From FedRAMP Program Management Office (PMO). FedRAMP FIPS 199 Categorization Template. Washington: US General Services Administration; 2012. “The CIS report includes control implementation responsibility and implementation status of the FedRAMP security controls.”

413

414

CHAPTER 13  A Case Study for Cloud Service Providers

FIGURE 13.7  Security Control Allocation

and indicates where the security control originates (i.e., service provider corporate network, service provider cloud service-specific, shared between the cloud service and the corporate network, configured by the customer, customer-specific hardware/software, and shared management between the service provider and the customer).

Tailoring and Supplementing The security controls selection process uses the security categorization to determine the appropriate initial baseline of security controls (i.e., Low or Moderate) that will provide adequate protection for the information and information systems that reside within the cloud service environment. A cloud service may require the implementation of alternative or compensating security controls not included in the initial baseline, or adding additional security controls or enhancements to address unique organizational needs based on a risk assessment or organization-specific security requirement. For this purpose, the Control Tailoring Workbook (CTW) provides the CSP with a listing of the FedRAMP security controls applicable for the cloud environment and assists in identifying the exception scenarios for the service offering so that the platform can be pre-qualified before resources are used to develop all of the other requisite FedRAMP documentation requirements [12].

Applying the Risk Management Framework within FedRAMP

Implement and Document Security Controls Documenting security controls within the cloud service requires the CSP to describe how the security controls were implemented in the System Security Plan (SSP). In the previous section, security controls were allocated based on specific responsibilities (i.e., inherited by another organization, shared between organizations, or implemented by an organization). In the SSP, information system components will need to be described based on the authorization boundary. The SSP details how the implementations address each required security control and enhancement in the selected, tailored, and supplemented security control baseline, descriptions of roles and responsibilities, and expected behavior of individuals with system access [12]. In addition, some security controls may require developing support documentation. For example, Table 13.6 identifies some of the documents that would be implemented by the CSP for FedRAMP.

Assessing Security Controls The assessment of security controls is primarily driven by the security control assessor. Within FedRAMP, an accredited third party assessment organization (3PAO) performs and independently tests the CSP’s cloud service to determine the effectiveness of security control implementation [14]. A discussion of the 3PAO’s responsibilities is beyond the scope of this section. Instead this section focuses on the Plan of Action and Milestones (POA&Ms).30 Once the 3PAO has completed conducting an assessment of the security controls, the Security Assessment Report (SAR)31 is developed, which is used by the CSP as a source for identifying, documenting, and managing the mitigation32 of “medium”33 and “high”34 risk security vulnerabilities.35 The POA&M is a tool used by the CSP, FedRAMP, and the “Federal Agency” when tracking and reporting on the progress of remediating security weaknesses and deficiencies. The POA&M36 addresses the specific tasks and resources, including a schedule for completing the remediation activities. 30Office of Management and Budget (OMB) Memorandum 02-01, Guidance for Preparing and Submit-

ting Security Plans of Action and Milestones, preparing the plan of action and milestones (POA&Ms). Available from: http://www.whitehouse.gov/omb/memoranda_m02-01. 31From FedRAMP Program Management Office (PMO). Plan of Action and Milestones (Template). Washington: US General Services Administration; 2012. POA&Ms are based on the findings and recommendations of the SAR excluding any remediation actions taken. 32FedRAMP specifies 90 days for “medium” and 30 days for “high.” 33Vulnerabilities are labeled “medium” if they have a CVSS base score of 4.0–6.9. 34Vulnerabilities are labeled “high” if they have a CVSS base score of 7.0–10.0. 35The Common Vulnerability Scoring System (CVSS) standard provides guidance on scoring vulnerabilities. Available from: http://www.first.org/cvss/cvss-guide.html. 36The POA&M document is one of three key documents (SSP, SAR, and POA&M) used by the JAB to make a determination of a provisional authorization and the federal agency in making a determination for leveraging the cloud service.

415

Configuration Management Planc

IT Contingency (including Business Impact Analysisb)

Plana

Document Name

a. Addresses roles, responsibilities, and configuration management processes and procedures; b. Defines the configuration items for the information system and when in the system development life cycle the configuration items are placed under configuration management; and c. Establishes the means for identifying configuration items throughout the system development life cycle and a process for managing the configuration of the configuration items.

CM-9—Configuration Management Plan The organization develops, documents, and implements a configuration management plan for the information system that:

b. Distributes copies of the contingency plan to [Assignment: organization-defined list of key contingency personnel (identified by name and/or by role) and organizational elements]; c. Coordinates contingency planning activities with incident handling activities; d. Reviews the contingency plan for the information system [Assignment: organization-defined frequency].

Identifies essential missions and business functions and associated contingency requirements; Provides recovery objectives, restoration priorities, and metrics003B Addresses contingency roles, responsibilities, assigned individuals with contact information; Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure; – Addresses eventual, full information system restoration without deterioration of the security measures originally planned and implemented; and – Is reviewed and approved by designated officials within the organization;

– – – –

a. Develops a contingency plan for the information system that:

CP-2—Contingency Plan The organization:

Security Control Requirement

Table 13.6 SSP Supporting Documents [13]

416 CHAPTER 13  A Case Study for Cloud Service Providers

IR-9—Incident Response Plan The organization:

Incident Response Pland

Provides the organization with a roadmap for implementing its incident response capability; Describes the structure and organization of the incident response capability; Provides a high-level approach for how the incident response capability fits into the overall organization; Meets the unique requirements of the organization, which relate to mission, size, structure, and functions; Defines reportable incidents; Provides metrics for measuring the incident response capability within the organization; Defines the resources and management support needed to effectively maintain and mature an incident response capability; and Is reviewed and approved by designated officials within the organization;



b. Distributes copies of the incident response plan to [Assignment: organization-defined list of incident response personnel (identified by name and/or by role) and organizational elements]; c. Reviews the incident response plan [Assignment: organization-defined frequency]; d. Revises the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing; and e. Communicates incident response plan changes to [Assignment: organization-defined list of incident response personnel (identified by name and/or by role) and organizational elements].

–

– – –

– – – –

a. Develops an incident response plan that:

Security Control Requirement

Document Name

Table 13.6 SSP Supporting Documents [13] (continued  )

Applying the Risk Management Framework within FedRAMP 417

IA-2—Identification and Authentication (Organizational Users) The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). IA-8—Identification and Authentication (Non-Organizational Users) The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users). PL-5—Privacy Impact Assessment The organization conducts a privacy impact assessment on the information system in accordance with OMB policy.

E-Authenticatione

Special Publication (SP) 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems contains sample Information System Contingency Plans for Low-Impact (A.1) and Moderate-Impact (A.2) systems. Available from: http://csrc.nist.gov/publications/ nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf. bNIST Special Publication (SP) 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems contains sample Business Impact Analysis Template (Appendix B). Available from: http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errataNov11-2010.pdf. cNIST Special Publication (SP) 800-128, Guide for Security-Focused Configuration Management of Information Systems contains sample outline for a Security Configuration Management Plan (Appendix D). Available from: http://csrc.nist.gov/publications/nistpubs/800-128/ sp800-128.pdf. dNIST Special Publication (SP) 800-61 Revision 2, Computer Security Incident Handling Guide contains a description of elements of the Incident Response Plan (Section 2.3.2—Plan Elements). Available from: http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP80061rev2.pdf. eNIST Special Publication (SP) 800-63-1, Electronic Authentication Guide contains information on e-authentication. Available from: http://csrc. nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf. Additional information can be found at IDManagement.gov. fOffice of Management and Budget (OMB) Memorandum 03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 provides guidance on conducting a privacy impact assessment (PIA). Available from: http://www.whitehouse.gov/omb/ memoranda_m03-22.

aNIST

Privacy Threshold A ­ nalysis and Privacy Impact Assessmentf

Security Control Requirement

Document Name

Table 13.6 SSP Supporting Documents [13] (continued  )

418 CHAPTER 13  A Case Study for Cloud Service Providers

References

SUMMARY This chapter presented a short case study to illustrate how the NIST RMF can be applied within the context of FedRAMP. In addition, some of the various FedRAMP deliverables were discussed as they relate to the security categorization, security control selection, and the implementation of the security controls (including supporting documentation) and documenting corrective actions resulting from the security controls assessment. Since the NIST RMF is a continuous process, documents will require regular reviews and updates on a continuous basis to address changes to the cloud service information system and the operating environment.

References [1] FedRAMP Program Management Office (PMO). FedRAMP template and process quick guide. Washington: US General Services Administration; 2012. [2] Stine K, Kissel R, Barker W, Lee A, Fahlsing J. NIST Special Publication (SP) 800-60 Revision 1, Volume II: Guide for mapping types of information and information systems to security categories. Maryland: National Institute of Standards and Technology; 2008. [3] Architecture and Infrastructure Committee. Federal segment architecture methodology version 10. Washington: CIO Council; 2008. [4] FedRAMP Program Management Office (PMO). FIPS 199 Categorization (Template). Washington: US General Services Administration; 2012. [5] Stine K, Kissel R, Barker W, Fahlsing J, Gulick J. NIST Special Publication (SP) 800-60 Revision 1, Volume I: Guide for mapping types of information and information systems to security categories. Maryland: National Institute of Standards and Technology; 2008. [6] Kundra V. Federal cloud computing strategy. Washington: Executive Office of the President, Office of Management and Budget; 2011. [7] Johnson C. Office of Management and Budget (OMB) memorandum 07-16, safeguarding against and responding to the breach of personally identifiable information. Washington: Executive Office of the President, Office of Management and Budget; 2007. [8] HIPAA Privacy Rule [Internet]. Washington: US Government printing office [cited June 18, 2012]. . [9] Health Insurance Portability and Accountability Act of 1996 [Internet]. Washington: US Government printing office [cited December 15, 2011]. . [10] IRC Section 6103, Confidentiality and disclosure of returns and return information [Internet]. Washington: US Government printing office [cited December 17, 2011]. . [11] For Covered Entities [Internet]. Washington: US Department of Health & Human Services [cited December 15, 2011]. . [12] FedRAMP Program Management Office (PMO). Guide to understanding FedRAMP version 1.1. Washington: US General Services Administration; 2012.

419

420

CHAPTER 13  A Case Study for Cloud Service Providers

[13] Joint Task Force Transformation Initiative. NIST Special Publication (SP) 80053 Revision 3, Recommended security controls for federal information system and organizations. Maryland: National Institute of Standards and Technology; 2010. [14] FedRAMP Program Management Office (PMO). FedRAMP Concept of Operations (CONOPS) version 1.0. Washington: US General Services Administration; 2012. [15] FedRAMP Program Management Office (PMO). FedRAMP FIPS 199 Categorization Template. Washington: US General Services Administration; 2012. [16] FedRAMP Program Management Office (PMO). Guide to Understanding FedRAMP. Washington: US General Services Administration; 2012.