Public Sector Cloud Service Providers

Public Sector Cloud Service Providers Critical First Steps for FedRAMP Success (Boundary Scoping) Summary James Leach Veris Group, LLC A Federal Risk and Authorization Management Program (FedRAMP) authorization is required for all cloud service providers (CSPs) selling cloud services to public sector entities such as federal civilian, defense, and intelligence agencies or state or local governments. Several cloud initiatives, government mandates, and the potential for significant cost savings for government are driving the fast pace of cloud adoption. The Office of Management and Budget (OMB) has mandated that all existing or new cloud systems must be approved through the FedRAMP Program by June 2014. Time to market remains a key concern for organizations offering these cloud solutions, but many CSPs applying through the FedRAMP program miss fundamental steps that can affect the success of this critical authorization. In their urgency to apply, CSPs may lack adequate planning, documentation preparation, and technical implementations required. CSPs that do not clearly and consistently define cloud components and adequately outline corporate (service inputs) against the FedRAMP cloud offering will encounter significant problems navigating the FedRAMP assessment. By streamlining the boundary scoping process, preparation and proper identification of the periphery interfaces and components, system interconnections, and data flows, CSPs stand to gain a significant advantage in regards to timeline, assessment costs, and overall approval of the respective system in the FedRAMP Program. As a trusted stakeholder in FedRAMP preparation process, an experienced FedRAMP Third Party Assessment Organization (3PAO) can provide a clear roadmap to defining and detailing the right elements of the boundary scoping FedRAMP requirements. The 3PAO can potentially lower assessment costs and help shorten the timeline to achieve FedRAMP authorization. Boundary Definition & FedRAMP: An Overview The National Institute of Standards and Technology (NIST) defines a system boundary (synonymous with authorization boundary) as [all] components of an information system to be authorized for operation by an authorizing official and excludes separately authorized systems, to which the information system is connected. i Clearly defining these boundaries, particularly in preparation for the intense scrutiny under FedRAMP review, can be a daunting task for any CSP. The cloud provider must carefully describe the abstract and physical cloud system including its sub-systems, system interfaces, stakeholders, third-party vendors/suppliers, and processes in order to prepare for a successful FedRAMP assessment. As a requirement for all FedRAMP approval methods (see box, FedRAMP Authorization ), a well-documented system boundary is one of the best indicators to the FedRAMP Joint Authorization Board (JAB) or sponsoring Agency FEDRAMP AUTHORIZATION The three most common ways a cloud system can be approved (authorized) for end federal government use via FedRAMP: 1. FedRAMP JAB Provisional Authorization (PATO) 2. FedRAMP Agency Authorization (ATO) 3. CSP supplied

that a CSP is prepared with a defendable assessment package. A CSP that cannot define and defend the boundary will likely have to schedule delays and cost overruns. The Federal Information Processing Standard (FIPS) 199 security categorization is conducted to detail data types. This process should be completed in parallel with the CSP system boundary definitions prior to any System Security Plan (SSP) being generated. ii Security-conscious organizations know what cloud systems and assets they have, what deployment models are in use, where the system physically resides, what data types exist (for service provider system data only), and how that data is protected. In determining system boundary, a CSP will confirm the identity of what hosts/assets are in direct management (common control and mission) and/or within the responsibility domain of the solution. Given the complexities in defining cloud boundaries, treating the cloud solutions as systems/sub-systems provides a targeted and cost-effective approach to an effective risk management process. Why Is Boundary Definition Important? A successful FedRAMP solution requires significant assessment preparation from the CSP to fully vet the solution both technically and operationally, including documenting clear system technology component definitions and how they interface within the cloud offering. Proper planning, architecture, and sound engineering practices are heavily weighted in the successful execution and completeness of a cloud solution. If the CSP fails to adequately plan or does not pick the right partners/subcontractors, the FedRAMP process may result in schedule delays, additional testing, and cost overruns. Schedule Time-to-market is a very important and valid concern for any CSP wanting to sell any technology solution. The danger (commonly overlooked) in an aggressive timeto-market push in the FedRAMP accreditation timeline/schedule is not spending the appropriate time scoping the boundary. Assets are often overlooked or underestimated, system boundaries are not fully defined and delineated (corporate versus third-party versus FedRAMP cloud offering boundaries), and system components are not consistently identified in the SSP and tested. Any of these issues may result in schedule delays because the FedRAMP JAB and/or Agency will not accept these types of inconsistencies. Costs Overruns CSPs seeking to minimize cost overruns will want to avoid key missteps such as not clearly defining the boundary (be very specific), not employing a robust asset inventory, changing the boundary mid-assessment, selecting poor architecture (non FIPS), having a weak vulnerability management process resulting in high scan findings (network/os, web and database), not dedicating internal staff, and not clearly delineating all system components and writing to the control implementation level for the required documentation. Additional Technology Testing/Partner Interconnections (Partner Services) Additional technology testing typically does not surface until the onsite testing portion of the FedRAMP assessment. A CSP may struggle to describe the differences between corporate infrastructure and its respective cloud offering. It is very common to see CSPs partner with other firms as a packaged cloud IaaS/PaaS/ SaaS solution. As the complexity of the assessment increases, asset counts, system interfaces, and documented system components tend to be missed/underdocumented by the CSP until testing execution is fully underway. This may result in

systemic boundary scoping issues that can delay schedule and result in cost overruns. What Is the Solution for CSPs? Successful FedRAMP preparation requires CSPs to work through a series of preparation activities ranging from confirming the characteristics of the cloud system to defining the boundary protections. By streamlining this process, CSPs will have the information and documentation ready to achieve FedRAMP authorization. The Five Critical Components/Steps for Boundary Development Offering a comprehensive boundary definition with detailed physical/logical interfaces of cloud systems is a challenge for all CSPs to work through. There are instances where current hosting offerings do not meet the metrics/criteria of a cloud system and further review should be done to ensure the FedRAMP model is the right fit for the service provider s system offering. An experienced 3PAO such as Veris Group offers the following critical components/steps process/methodology to work through the boundary scoping process. 1. Confirm Confirm the characteristics of the cloud system Within certain cloud hosting environments, it is possible that some FedRAMP requirements may not apply to the hosting provider. In order to assist the CSP or Federal Agencies in determining applicability, the CSP should align its cloud offering to the essential characteristics, service, or deployment models. A CSP should determine whether it has a true cloud system versus a dedicated single-tenant application running in the cloud. According to NISTiii: Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access Confirm Create Confirm characteristics of the cloud system Create clear system/ component descriptions Consistently detail cloud components to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. For example, this cloud model is composed of five essential characteristics, four deployment models and three service models, as detailed in the NIST SP 800-145, The NIST Definition of Cloud Computing :iv Detail Characterize Illustrate Characterize system inter-connections (internal/ external) Illustrate and describe data flow Essential Characteristics On-demand self-service Broad network access Resource pooling Rapid elasticity Measured service Deployment Models Private Cloud Community Cloud Public Cloud Hybrid Cloud Service Models IaaS PaaS SaaS

CSPs will need to evaluate the service offering against the cloud metric/characteristics identified above to ensure applicability of the FedRAMP accreditation program. Veris Group recommends that CSPs incorporate NIST 800-145 guidance and validate how their cloud solution maps to the NIST definition of cloud computing. Once the CSP confirms how its cloud solution meets the cloud definition model/characteristics, the next step is to start documenting a clear system description to reflect the FedRAMP offering. 2. Create Create clear system/component descriptions Every good System Security Plan (SSP) starts with a detailed system description, inclusive of a very detailed system boundary. Outside of the full system description, unique identifier, system owner, governing organization, system location, and cloud offering versions, there are several other key considerations (not fully inclusive) in determining a detailed system boundary: v General/Enterprise o What is the system business function, charter (ownership), and cloud capabilities of the system? o Can the CSP provide network architecture/design overview, topology, and data flow diagrams? o Provide a comprehensive asset inventory (hardware, software, network)? o Types of users (internal/external) as it applies to boundaries? o Data process flows (inputs / outputs) of the federal cloud offering? o Is any corporate infrastructure included within the FedRAMP cloud offering? If so, how is the corporate infrastructure isolated from the FedRAMP offering? o Data types transmitted and/or processed (part of the FIPS 199 Security Categorization)? o Are network zones instituted if so, how? o Provide a granular description of system-specific, shared, and end customer specific controls/requirements (Control Tailoring Workbook/Control Implementation Summary). o Will federal agencies cloud data be co-mingled with non-government customers? If so, how will this be isolated? o Define geographic location where data resides. o Describe multi-tenancy how the cloud solution virtually isolates its data and configuration for each respective customer. o Does the cloud solution support multifactor authentication for network privileged/non-privileged and local privileged? If so, explain in specific detail how. o Where do all administrative staff reside, are they US citizens, and do they have adequate security clearances? o Are there live migration strategies, rules, and use case implementations (manual/automated) within the cloud system? System Interconnections/Perimeters o List all interconnected systems (partners, third party services), physical location and connection flow. o Identify all systems and subsystems (static/dynamic), Contiguous United States (CONUS).

o o o How do the cloud border devices (router access control list, firewalls, IPS/IDPS, IPsec tunnels, VPN) provide isolation on the external interfacing devices? Trusted Internet Connection how does the CSP plan on integrating their solution with the federal agency s Trusted Internet Connection? Define approved ports, protocols, and services platform functions allowed within the system (inbound/outbound). Network How do the cloud border devices (router access control list, firewalls, IDS/IPS, IPsec tunnels, VPN) provide isolation internally through multitenancy protections? Does the CSP isolate virtual machine zones on unique network segments? What type of traffic isolation is performed? Is NAT integrated into the solution (static, dynamic, overloading, overlapping, etc.)? If so, how what specific configurations and parameter changes are instituted? Are IP Geographic boundaries leveraged? If so, how? Are FIPS-validated encryption methods integrated for system processing, transmission, and data at rest? Remote access methods what are the end users, data flow and usage restrictions. Storage Does the storage solution consist of Direct Attached Storage (DAS), Network Attached Storage (NAS), iscsi, or Storage Area Networks (SAN) solutions, or others (API customization with the hypervisor tier)? Where does the data reside (physical locations) within the cloud offering? Cloud redundancy storage options given the redundancy of most cloud offerings, does it use a multipath environment (availability zones) for storage options/solutions (persistent/non-persistent storage options)? *While not completely uncommon, there are CSPs that have varying storage device offerings that will need to be detailed within the FedRAMP boundary. Is there a clear delineation between system, hybrid, and end customer storage responsibilities? These elements provide a good foundation/roadmap but are not meant to be fully comprehensive. Additional review and considerations would need to take place in compliance with FedRAMP requirements. 3. Detail Consistently detail cloud components Describing the CSP s cloud system components is essential. The SSP must have a welldefined technology component list which must also directly and consistently align to the component list included as part of the Security Assessment Plan (SAP). CSPs have the option of describing system components by an internal unique name or by functionality. The figure below is an example of the types of services available to the end cloud consumer.vi

Most cloud service providers have a good handle on what they are and what they offer from a cloud service model. The next step is to align the offering the graphic above and look to further define the system as it relates to unique technology components. The CSP then needs to further define the cloud offering to the actual technology components of the cloud solution: General/Enterprise (e.g., Multifactor authentication, Ticketing, IDS/IPS, Monitoring, Auditing, Self-serve portal) Network (e.g., Routers, Switches, Firewalls, VPNs, Load Balancers) Hosts/OS (e.g., RHEL, CentOS, Windows) Web (e.g., Apache, IIS, IBM HTTP Server, Oracle HTTP Server, Resin) Applications (Jetty, iplanet, GlassFish, JBoss, WebLogic) Virtualization (e.g., Hyper-V, Xen, KVM, VMWare ESX/ESXi) Database (e.g., Oracle, SQL Server, MySQL) Storage (e.g., NetApp, EMC) Whichever naming method (component or functionality-based) a CSP selects, a consistent naming convention remains critical as a functional or technical component description. The CSP s FedRAMP security authorization documentation should be consistent across the FedRAMP package. Each document should utilize the same names, acronyms, and terminology, and provide the same system description, components, and logical/physical inventory/assets. During the review by FedRAMP PMO or a sponsoring agency, these types of inconsistencies could considerably impact schedule delays and lead to cost overruns.

4. Characterize Characterize system inter-connections (internal/ external) One of the common mistakes CSPs encounter is the failure to adequately detail and describe how their cloud offering is physically and logically separated from their corporate infrastructure. The FedRAMP PMO has provided guidance in the SSP template and utilizes a table to define the system interconnections, which is provided below: CSP IP Address and Interface External Organization Name and IP Address of System External Point of Contact and Phone Number Connection Security (IPSec VPN, SSL, Certificates, Secure File Transfer etc.) Data Direction (incoming, outgoing, or both) Information Being Transmitted Ports or Circuit # Within many organizations, there may be legitimate business or risk-based justifications as to why the CSP cannot fully or always isolate all technical functions (Multifactor Authentication, Monitoring, Ticketing, Admin access, etc.). In these instances, a CSP must provide additional information to explain how the corporate infrastructure is properly secured, segmented, and logically communicates with the FedRAMP cloud solution. The table below provides context to the Service Provider Corporate and how these controls/interfaces should be documented. Corporate Resource Provided? Function Provided by which Business Unit/Group within the Organization? Key Point of Contact, Service Owner? Ports, Protocols, and Services Data Direction (incoming, outgoing, or bidirectional) Information Being Transmitted CSP Cloud Endpoint (identified device for demarcation) Cisco Identity Services Engine (ISE) /detailed) Credential validation / authentication functions Acme X Chief Security Office John Doe LDAP(389), SMB(445), KDC(88), Global Catalog (3268, 3289), KPASS(464), NTP(123) and LDAPS (636) Bi-directional Credential validation / authentication functions Cisco ASA 5515 (IP Address X.X.X.X) 5. Illustrate Illustrate and describe Network/System Diagram, Architecture, and Data Flow Another important step in the FedRAMP process, a CSP is required to brief the FedRAMP PMO/JAB or sponsor agency on the respective cloud system, including its mission, functionality, features, architecture, and the data flow for the services provided. Creating clear, concise diagrams that illustrate the end user experience and network traffic flows throughout the cloud system will significantly contribute to achieving initial FedRAMP stakeholder understanding, and ultimately setting a right foundation for the assessment

lifecycle. The more the FedRAMP PMO/JAB understand the cloud system upfront, the better position the CSP will be in to meet the end goal: risk acceptance/authorization. One of the main differentiators on the data flow diagram versus network topology diagram is that the data flow illustrations are more centric to the direction of network traffic flow and less about each and every component of the cloud topology. CSPs should look to create these data flow diagrams of the following perspectives: CSP Administrative Access graphically detail how support staff access the FedRAMP cloud environment internal to the corporate network, externally via VPN or other means. CSP Corporate Services (System Inputs) illustrate what services are provided to the FedRAMP cloud, viewed as inputs to the system but not part of the system. Examples of this could be multi-factor authentication or monitoring capabilities. End Customer Data Flow data flow experience on how IaaS/PaaS/SaaS services are rendered/provided to the end customer. If integrated cloud service models are deployed, multiple data flow diagrams may be required to demonstrate flow. System Interconnections/Partners data flow illustrations on system interconnects and integrated partners Storage data flow diagram depicting the cloud storage data flow. Accurate and complete data flow illustrations in the initial draft FedRAMP security authorization package will provide FedRAMP PMO, JAB, or sponsor agencies with a critical understanding of the cloud solution and provide a clear and concise view of the cloud solution to the stakeholders. Conclusion As with any successful task or project, effective and efficient planning is critical and the essential first step in ensuring success. With FedRAMP, a tactical approach in delineating the cloud system boundary, system interfaces, and corporate resource isolations are fundamental to the success of an independent FedRAMP assessment (also other regulatory requirements/assessments). FedRAMP success is predicated on the following elements/roadmap to success: Characteristics of the Cloud Well-Documented System Description Define CSP Technology Components (Functional) Data Flow, Network, and Architecture Diagrams/Illustrations System Interconnections CSPs can choose to take these steps internally utilizing their existing compliance team or look to outsource all or several of these preparation functions with a qualified 3PAO entity. The CSP s success in the FedRAMP program is founded in the planning phase, the preparation. To ensure a CSP s time-to-market goals are met, they must account for the boundary scoping points above to make the ultimate goal of achieving a FedRAMP approval (FedRAMP JAB, Agency, or CSP Supplied) a reality.

i Ross, Ronald & Johnson, L.A. (2010) NIST SP 800-37 Rev 1, Guide for Applying the Risk Management Framework to Federal Information Systems [NIST Publication] http://www.nist.gov/manuscript-publicationsearch.cfm?pub_id=904985 ii Cichonski, Paul, Millar, Tom, Grance, Tim, and Scarfone, Karen (2012) NIST SP 800-61, Rev. 1 Volume 2, Computer Security Incident Handling Guide [NIST Publication] http://csrc.nist.gov/publications/nistpubs/800-61rev2/sp800-61rev2.pdf iii, iv Peter Mell, Timothy Grance, The NIST Definition of Cloud Computing, September 2011 v GSA (2012) Guide to Understanding FedRAMP. http://www.gsa.gov/graphics/staffoffices/ Guide_to_Understanding_FedRAMP_060412.pdf iv Fang Liu, Jin Tong, others, NIST Cloud Computing Reference Architecture, 500-292 > James Leach is the Vice-President, Strategic Operations, of Veris Group, LLC, a Vienna, VA-based cybersecurity firm. > Veris Group, LLC Attn: FedRAMP 8229 Boone Blvd., Suite 750 Vienna, VA 22182 (703) 760-9160 > fedramp@verisgroup.com