SaaS Business Rules
BR-SAAS-1: SaaS Clouds Are Defined by NIST SP-800-145
CMS uses the NIST SP 800-145 definition of software as a service. It is recognized that mapping commercial or government products to this model is not always straightforward because many providers produce clouds that have characteristics of one or more of these models. If uncertain, consult with the CMS TRB.
Rationale:
The HHS designation of “Third Party Web Site” (TPWS) has been confused with SaaS. Some have argued that a given website is a TPWS and not a cloud (therefore not requiring FedRAMP certification). TPWS applies only to the analysis for privacy concerns. That is, when a CMS website redirects a user to a TPWS, it is instructing the user’s browser to shift its attention to another address. The user will be interacting with a website that is not operated on behalf of CMS, does not have a contractual relationship with CMS, and may use data in ways that CMS cannot control. Examples would include popular social media and news sites.
A service that collects official government data must be used under contract and with an ATO, even if it is possible to acquire the service without payment. The privacy and security of CMS data is at stake.
OMB Memorandum M-10-23, Guidance for Agency Use of Third-Party Websites and Applications, states that:
The term “third-party websites or applications” refers to web-based technologies that are not exclusively operated or controlled by a government entity, or web-based technologies that involve significant participation of a nongovernment entity. Often these technologies are located on a “.com” website or other location that is not part of an official government domain. However, third-party applications can also be embedded or incorporated on an agency’s official website.
There may also be unknown licensing issues with using what appears to be a free service. Many services that are free to an individual are not free to an organization. Integrating these capabilities into CMS systems places CMS and the government at risk of violating copyright laws.
BR-SAAS-2: SaaS Must Have a CMS ATO
Projects may only use SaaS if they hold a CMS Authority to Operate (ATO) issued by the CMS Designated Authority, nominally the CMS CIO. Although not absolutely required, the SaaS should have FedRAMP Certification, especially in scenarios where the SaaS may store or process sensitive information. Without FedRAMP Certification to inherit security controls from, the business owner must address the controls and risks in the SaaS environment, which may be a burdensome undertaking. If the SaaS environment will be storing or processing CMS data, it is a CMS Processing Environment (as defined in CMS TRA Foundation, Processing Environments) and must comply with the CMS ARS, CMS TRA, RMH and other relevant CMS and federal requirements.
Related CMS IS2P2 Cloud Computing requirements include: CMS-CLD-1, CMS-CLD-1.1, and CMS-CLD-2.
Rationale:
A CMS ATO is required by FISMA, OMB Memorandum, Security Authorization of Information Systems in Cloud Computing Environments, December 8, 2011; and CMS IS2P2 with Cloud Computing requirements: CMS-CLD-1 and CMS-CLD-2. Projects may only use SaaS if they hold a CMS ATO issued by the CMS Designated Authority, nominally the CMS CIO. Also, per CMS-CLD-1.1, a SaaS product without current FedRAMP authorization , a CMS Provisional Authority to Operate (P-ATO) may be granted following a Rapid Cloud Review (RCR).
BR-SAAS-3: Ensure CMS Security May Perform Periodic Security Assessments
Projects must coordinate with the cloud and CMS security to allow designated CMS security personnel to perform non-destructive security testing and assessment, with prior communication with the SaaS service, including penetration testing.
Related CMS ARS Security Controls include: CA-07 - Continuous Monitoring, CA-7(4) - Risk Monitoring, CA-08 - Penetration Testing (High and Moderate HVA Systems), and CM-07- Least Functionality.
Rationale:
Ensuring that CMS data and services are secure cannot be satisfied by a one-time check. CMS security must perform periodic security assessments to identify risks to CMS data and services. Testing of cloud services will require concurrence from the Cloud Service Provider. Assessments are performed by ISPG, another federal government agency, or a contractor working on behalf of ISPG or another federal government agency.
BR-SAAS-4: Plan for Data Archival to Comply with Federal Records Management
Projects must establish how CMS data will be archived (for long-term records management purposes). Data within the SaaS Cloud must be catalogued by a CMS data steward and appropriate disposition recorded to ensure data is stored for the appropriate time period and in the appropriate manner.
Related CMS ARS Security Controls include: AU-11 - Audit Record Retention, MP-6 - Media Sanitation, SI-12 - Information Management and Retention, SI-12(3) - Information Disposal
Rationale:
Commercial SaaS providers do not typically retain data after contract expiration. Federal Records Management guidelines require specific handling of records at system disposition. Archival is typically performed to storage outside of the SaaS cloud.
BR-SAAS-5: Establish SaaS-Specific Contingency Program
Projects using SaaS Cloud providers must establish a contingency program plan, independent of the SaaS Cloud Service Provider, that meets the business owner’s RTO / RPO requirements.
Projects must ensure that gaps in the SaaS Cloud provider’s recovery plan be accounted for and handled. Disaster recovery must also include recovering any integration between the CSP and CMS, such as CMS Cybersecurity Integration Center (CCIC) integration, EUA integration, or CMSNet.
Contingency Planning and Disaster Recovery may be conducted within the same Cloud Service Provider (typical) or another provider (atypical.)
There are several critical requirements associated with the contingency program that must be addressed:
-
Business recovery processes may include the following documents: Business Continuity Plans, Disaster Recovery Plans, Continuity of Operations Plans (COOP), Crisis Communications Plans, Critical Infrastructure Plans, Cyber Incident Response Plans, Insider Threat Implementation Plan, and Occupant Emergency Plans.
-
It is essential all recovery-related plans be coordinated.
-
It is essential all recovery-related plans testing be coordinated.
-
It is essential all recovery-related stakeholders (and personnel) be periodically trained on responsibilities.
Business owners should also anticipate and plan for disruption of service such as voluntary or involuntary transfer from a SaaS service to an alternative.
Related CMS ARS Security Controls include: CP family of controls, in particular, CP-2 - Contingency Plan and CP-2(1) - Coordinate with Related Plans.
Rationale:
Although many Cloud Service Providers have contingency plans for their own purposes, the responsibility for contingency planning for CMS services lies with the project team and CMS business owner. Disaster Recovery is just one element of a Contingency Program.
BR-SAAS-6: Perform Configuration Management
All configuration settings and code changes must be placed under configuration control by project teams. Configuration Change control must be also implemented. The baseline configuration and settings must also be managed. Specialized tools focused on SaaS Security Posture Management (SSPM) have become available in the market and CMS is currently evaluating various tool options. See the CMS Cybergeek SaaS Governance Program web page (SaaS Governance) for more information and how to contact the SaaS Governance team to get current information on SSPM tools
Related CMS ARS Security Controls include: the entire CM family of controls.
Rationale:
SaaS Clouds often eliminate the need for projects to manage the software that runs a service. There may still be configuration settings and changes performed to set up a product before use by CMS users. Managing configurations is essential to ensure reproducible configurations.
There may also be configuration-specific data items, such as SSL / TLS keys or SSH keys that must be installed and managed (during key expiration, for example), as well as user privileges and data access restrictions.
Projects must establish how CMS life-cycle reviews and system promotion will be conducted to maintain orderly promotion of code from development to production. Configurations and code should be stored in a CMS-approved source control system.
Operating SaaS applications does not absolve project teams from these responsibilities.
BR-SAAS-7: Integrate with CMS CCIC
Projects using clouds must integrate with the CMS Cybersecurity Integration Center. This means transferring event and incident logs periodically to the CCIC.
Related CMS ARS Security Controls include: AU-02 - Event Logging, AU-03 - Content of Audit Records, AU-06 - Audit Record Review, Analysis, and Reporting, CA-02 - Control Assessments, CA-06 - Authorization, CM-03 - Configuration Change Control, and CM-07 - Least Functionality.
Rationale:
CMS cloud-based systems must be integrated with CCIC to participate in the global CMS security monitoring. Because of the wide variety of different SaaS clouds and their ability to integrate with external services, the exact form of integration will vary. The objective should be to participate with the CCIC in sharing information about security and application status of SaaS-hosted applications.
To meet CCIC requirements, it may be necessary to obtain direct feeds from the SaaS service or, lacking that, indirect feeds using external monitoring and polling. Please refer to CMS TRA Network Services, Security Services and CCIC Integration chapters.
BR-SAAS-8: CMS Data Must Always Reside in the U.S.
CMS system owners must ensure that CMS data is not processed, transmitted, transferred, or stored outside the United States and its territories. This maintains the jurisdiction of the Privacy Act of 1974 and the Health Insurance Portability and Accountability Act of 1996 (HIPAA).
Rationale:
CMS data must be stored, transferred, and processed entirely (and exclusively) within the U.S. to eliminate the possibility that foreign powers might obtain access to CMS data and information.
SaaS Recommended Practices
RP-SAAS-1: Integrate with CMSNet
Projects using clouds should integrate with CMSNet to reach other CMS processing environments and transfer data securely.
Rationale:
CMSNet is a secure transport between most CMS data centers and cloud enclaves. Using CMSNet reduces the possibility that data could be intercepted during transit because, in addition to using encryption, CMSNet is a private network with limited access.
RP-SAAS-2: Comply with CMS Defense-in-Depth Architecture
Projects using clouds should follow the defense-in-depth practices when possible.
Rationale:
It is understood that SaaS providers often do not reveal or discuss their internal architectures, which makes complying with the multi-zone architecture difficult. The following steps can provide comparable risk reduction offered by a Defense-in-Depth strategy like the CMS Multi-Zone Architecture:
- Use a Web Application Firewall (WAF)
- Use CMS-issued certificates
- Use a Content Distribution Network with DDoS protection
- Ask the CSP to provide documentation for these steps and services
The CMS IS2P2 section 4.1.3 provides guidance for ensuring compliance with the CMS Multi-Zone Architecture. In addition, IS2P2 System and Communications Protection (SC) requirements SC-1.1.3, SC-1.1.3.1, SC-1.1.3.2, and SC-1.1.3.3 should be consulted.
RP-SAAS-3: Continuous Monitoring
Projects using SaaS should integrate with CMS continuous monitoring initiatives.
Related CMS ARS Security Controls include: CA-07 - Continuous Monitoring and CA-7(4) - Risk Monitoring.
Rationale:
NIST requires continuous monitoring to address security impacts. This is complementary to, but different from, continuous operational monitoring, which seeks to assess the operational condition of an IT system.
RP-SAAS-4: Integrate SaaS with CMS Identity Management Systems
Projects must establish how CMS’s Identity Management Systems will be integrated with the SaaS (if possible).
If not available directly, projects are responsible for establishing how they will conduct user onboarding / offboarding to ensure that only active, authorized users are allowed in and CMS is not paying for excess capacity/accounts, etc.
Rationale:
The CMS Identity Management Systems (such as EUA) are used across CMS systems to ensure a common set of processes for onboarding and offboarding users as well as authentication. This assures CMS, for example, that employees who leave and contractors whose contracts expire are quickly and reliably removed from authorization lists. Using such a system also ensures that employees and contractors can benefit from reduced or single sign-in (R/SSO), greatly reducing the burden on managing credentials.