• No results found

Public Sector Cloud Service Providers

N/A
N/A
Protected

Academic year: 2021

Share "Public Sector Cloud Service Providers"

Copied!
9
0
0

Loading.... (view fulltext now)

Full text

(1)

Public Sector Cloud Service Providers

Critical First Steps for FedRAMP Success (Boundary Scoping)

James Leach Veris Group, LLC

Summary

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

F

ED

RAMP

A

UTHORIZATION

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

(2)

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 time-to-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/under-documented by the CSP until testing execution is fully underway. This may result in

(3)

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

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

Confirm characteristics of the cloud system Confirm

Create clear system/ component descriptions CreateConsistently detail cloud components DetailCharacterize system inter-connections (internal/ external) Characterize

Illustrate and describe data flow

Illustrate

Essential

Characteristics On-demand self-service

Broad network

access

Resource

pooling elasticityRapid Measured service Deployment

Models Private Cloud Community Cloud Public Cloud Hybrid Cloud

Service Models IaaS PaaS SaaS

(4)

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).

(5)

o How do the cloud border devices (router access control list, firewalls, IPS/IDPS, IPsec tunnels, VPN) provide isolation on the external interfacing devices?

o Trusted Internet Connection – how does the CSP plan on integrating their solution with the federal agency’s Trusted Internet Connection?

o 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 multi-tenancy 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 well-defined 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

(6)

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.

(7)

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

(8)

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.

(9)

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-publication-search.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

8229 BOONE BLVD., SUITE 750 | VIENNA, VA 22182 | P: (703) 760-9160 F: (703) 760-9164 | info@verisgroup.com | www.verisgroup.com

References

Related documents

neural stem cells improve spinal muscular atrophy phenotype in mice. Taylor JL, Lee FK, Yazdanpanah GK, Staropoli JF, Liu M, Carulli JP,

of the body can regenerate a whole animal. Regeneration is due to the presence of totipotent adult somatic stem cells, called neoblasts which can make up as much as 30% of all cells

3 To make decisions in the economy, actors must form expectations, among other things, with regard to technological development, consumer preferences, prices, availability of raw

We have conducted a global meta-analysis of both the past and the most recent literature data on the nutrient concentrations in photosynthetic tissues, foliar litter

Prior to the visual search displays, observers were presented with a colour cue that indicated either the target colour (positive cue), the colour of the to-be-ignored

Map of the mesonet (blue squares) and METAR (blue squares with red circles) weather station locations from MADIS. The AMU used the data from these sites to

The peak number of stored nodes is roughly equal to the size of a layer times four, since Divide-and Con- quer Beam Search only stores four layers in memory; the current, previous,

The LISFLOOD hydrological and water use model was run using climate projections for a high emissions (RCP8.5) and moderate-mitigation (RCP4.5) scenario to simulate minimum river