CMS Technical Reference Architecture

FOUNDATION 

Introduction to the TRA 

The CMS Technical Reference Architecture (hereafter referred to as the “CMS TRA”) articulates the technical architecture of all Centers for Medicare & Medicaid Services (CMS) processing environments (hereafter simply the “CMS Processing Environments”). A CMS Processing Environment is defined as: 

Any computing environment (e.g., CMS data center, virtual computing environment, or cloud computing including Infrastructure as a Service (IaaS), Software as a Service (SaaS), and Platform as a Service (PaaS)) that creates, consumes, and/or stores CMS-related data. CMS data includes sensitive, non-sensitive, and security information and event management-related information used to provide CMS services to the public and internal CMS users. 

The CMS TRA represents the Agency’s policy guidance to all Agency business partners wishing to develop, transition, and maintain information systems that interact with the CMS Processing Environments. The CMS TRA is approved and authorized by the CMS Chief Information Officer (CIO) and Chief Enterprise Architect (CEA). 

Adherence to the CMS TRA supports the Agency’s healthcare mission by providing: 

• A secure CMS Processing Environment that protects sensitive information, including CMS, beneficiary, provider, and partner information 
• Appropriate disaster recovery and business continuity capabilities 
• Timely and economic transition of CMS applications into new processing environments 
• An enterprise computing solution that responds to CMS’s evolving mission and business needs 

Toward these ends, the CMS TRA defines a common set of terms and definitions to support CMS’s architecture approach and ensure an effective operating environment. It conveys required design considerations, including security policies and controls (for confidentiality, integrity, and availability), reusability, scalability, and sustainability. The common framework of the CMS TRA supports future application designs as well as architecting and engineering CMS applications. It encourages the use and creation of enterprise shared services and presents clear guidance on their appropriate use and interaction among CMS data centers. By promoting a technical reference standard for future CMS task orders and acquisitions, the CMS TRA clarifies the decision-making process and target technical environments, which helps Agency contractors develop sound and acceptable transition approaches. 

Purpose 

This topic introduces the CMS TRA and is the keystone of CMS TRA guidance, as shown in Essential Guidance for the Entire CMS TRA. It articulates the CMS Architectural Vision and provides guidance relevant to all stakeholders. It establishes the guiding principles of the CMS architecture that informs all guidance in subsequent topics and presents overviews of CMS Services Framework and Multi-Zone Architectures. 

TRA Overview Diagram (page 7) 

Essential Guidance for the Entire CMS TRA 

This topic also summarizes how to request a change to the CMS TRA through the Architecture Change Request (ACR) process. 

Stakeholders interested in specific architectural topics can find detailed guidance organized in topics as follows: 

• Network Services – focuses on network infrastructure including security-related appliances that monitor network traffic 
• Infrastructure Services – focuses on physical or virtual infrastructure supporting CMS applications 
• Application Development – focuses on application-level concepts and methodology 
• Data Management – focuses on data management and data lakes 

The guidance in each CMS TRA topic includes narrative providing context; Business Rules (BR), which are requirements for TRA compliance; and Recommended Practices (RP), which are strongly encouraged for use within the CMS Processing Environments but not required. 

Intended Audience 

The CMS TRA is intended to guide system architects, business owners, system maintainers, and security auditors in working with CMS’s technical environment. A publicly available version is located at CMS TRA. CMS restricts access to the complete CMS TRA to the following authorized users: 

• CMS staff 
• CMS Processing Environment contractors 
• Operator of the CMS Alliance to Modernize Healthcare Federally Funded Research and Development Center (the Health FFRDC) 

CMS executive or management approval is required to provide this document to other entities pursuant to business need. 

Complementary Documents 

The CMS TRA complements CMS standards documentation. The CMS TRA supersedes and takes precedence over other existing CMS standards documentation, with the following exceptions: 

• CMS Information Security (IS) Acceptable Risk Safeguards (ARS, hereafter simply the “CMS ARS”) 
• All volumes of the CMS Risk Management Handbook (RMH) 
• CMS Information System Security and Privacy Policy (IS2P2) 
• CMS Section 508 Policy 

The CMS ARS is located at: CMS Acceptable Risk Safeguards (ARS) on the CMS CyberGeek website. 

CMS provides an orientation briefing for CMS TRA Document Development (MS PowerPoint) and the ACR Form (PDF) for initiating an Architecture Change Request. 

A mailing list entitled “CIO Resource Library Communications” is available to notify subscribers when new or revised information technology (IT)-related policies, technical or TRA standards, directives, or guidelines are available. To subscribe to the new list, please select the following URL and enter your email address: 

https://public.govdelivery.com/accounts/USCMS/subscriber/new?topic_id=USCMS_12066 

Please direct all questions, comments, suggestions, or requests for further information to the CMS CIO Policy Officer at IT_Policy@cms.hhs.gov.  

Guiding Principles 

The CMS TRA informs the development of the Agency’s Common Enterprise Infrastructure (CEI) and is the foundation for the design and implementation of processing components and computing environments across the CMS Enterprise. Ensuring the secure operation of all CMS Processing Environments (as defined in CMS Processing Environments) is a primary architectural consideration. Adhering to the CMS TRA improves interoperability of services across the enterprise, supporting the goal of providing high-value services at lower cost, with higher availability, reduced implementation times, and improved maintainability. 

The CMS TRA describes the technical baseline for all CMS Processing Environments. The CMS TRA cites proven, effective, and tested common controls that meet legislatively mandated mission, security, and privacy requirements. The Agency updates the CMS TRA as required to respond to CMS’s changing needs and direction and to reflect current technical standards. 

As CMS’s repository of technical reference standards, the CMS TRA plays a critical role in all contracts. Contracting Officers refer to the CMS TRA topics in task orders and solicitations to ensure that contractors understand and apply technical consistency across data centers and contract efforts. 

The TRA focuses on services, outcomes, and effects instead of physical structures, specific products, or system components. Unless explicitly stated, references to specific products and/or vendors within the CMS TRA provide information about the existing technical environment rather than express an Agency preference. The CMS TRA supports the Department of Health and Human Services (HHS) Enterprise Architecture principles and satisfies the CMS ARS security control, CM-2, Baseline Configuration. 

CMS relies on the following guiding principles for the CMS TRA: 

• Defense-in-Depth 
• Least privilege 
• Vendor agnostic, amenable to new technologies 
• Reuse 
• Service-Oriented Architecture (SOA) and Microservices 
• Enterprise Services 
• Common Platform Services 
• Cloud First 
• Use of Open Source Software 
• Automation 
• Sustainability 

Defense-in-Depth 

Defense-in-Depth employs multiple, coordinated security countermeasures to protect against security issues throughout the infrastructure. 

A Services Framework architecture separates services by their function and encapsulates them with their own layers of protection/defense providing adaptable layers of depth. 

A multi-zone architecture, which is a type of Services Framework architecture, places multiple layers of protection/defense on each zone by segregating networks and controlling inter-zone communications. 

Least Privilege 

The CMS TRA adheres to the security concept of least privilege, the security objective of granting users only those accesses they need to perform their official duties. When a user is permitted to “self-elevate” temporarily (e.g., Linux sudo command), this action is logged. 

Vendor Agnostic 

Unless explicitly stated, the CMS TRA does not advocate a preferred vendor or suite of products. One notable exception to this rule is shared services (including security services), where a specific technology has been selected and is mandated for use of or integration with this shared service. CMS encourages innovation of supportable solutions within the parameters of the CMS TRA. 

When selecting software, business owners should evaluate competing product licenses and leverage existing agency purchasing sources before approving new contractor purchases. The focus should be on minimizing costs and promoting consistency across CMS applications and environments. Business owners are required to utilize Inter-Agency Agreements (IAA), CMS Enterprise License Agreements (ELA), and Government Furnished Software (GFS) to the greatest extent possible. These actions will support CIO Directive 25-02 Use of CMS Enterprise License Agreements, issued July 1, 2025. 

CMS maintains enterprise licensing information at: Enterprise Software Licensing 

For more information on IAA, ELA, or GFS agreements, please contact the Software Asset Management Program Management Office (SAM PMO) at SoftwareLicensesCMS@cms.hhs.gov. 

Reuse 

CMS encourages reuse and sharing wherever practicable to avoid creating redundant services/applications. There can be multiple cloud and physical data centers in the CMS environment. Any application can reside in any combination of CMS data centers (including CMS Clouds) and use software services—for example, Identity Management (IDM) and Enterprise Portal—of the other data centers. Application software in one data center may leverage services in another data center. 

The benefits of reuse include: 

• Reduced implementation times 
• Lower project risk 
• Reduced costs 
• Minimized redundancy 
• Improved security 
• Improved interoperability 

CMS employs several strategies for reuse: adoption of a Service-Oriented Architecture, use of Microservices, and the implementation and use of Strategic and Preferred Solutions. 

Service-Oriented Architecture and Microservices 

SOA defines a set of principles for developing software as interoperable, reusable, distributed services to fulfill business functions. For example, the Medicaid Information Technology Architecture (MITA) is a SOA framework that allows CMS and state Medicaid organizations to create, deploy, execute, and manage reusable, modular, and interoperable business, data, and technology services. The Application Development section addresses SOA extensively. 

Microservices (MS) are a modern interpretation of SOAs for building distributed software systems. Each component/ module of an application is developed and deployed separately. This contrasts with a traditional, “monolithic” application in which all components are developed and deployed as one piece. Microservices are well suited to DevOps methods and tools. The Application Development section addresses Microservices, with additional detail in the TRB Research Spotlight, “Microservice Architecture,” published April 11, 2023. 

Strategic and Preferred Solutions 

CMS strongly encourages the use of Strategic and Preferred Solutions. These are solutions which have been designed, tested, and approved for broad use within CMS. Utilizing these existing solutions, which include formally designated Enterprise Shared Services (ESS), shortens the Time-to-Delivery (TTD), facilitates efficient infrastructure use, reduces redundant capabilities, improves access, and leads to more consistent cybersecurity posture. The Office of Management and Budget (OMB) Memorandum M-19-16, Centralized Mission Support Capabilities for the Federal Government, April 26 2019, defines federal IT shared services and policy. (Also see Solutions to Improve Agency Management Efficiency (ussm.gsa.gov) and cio.gov/policies-and-priorities/shared-services) 

Details and guidance for the use of these services are described in the following section, CMS Strategic Guidance and Preferred Solutions. 

Common Platform Services 

Common platform services are technology services provided in support of all hosted applications. The CMS ecosystem now supports platform services across both cloud and on-premises environments. These capabilities are designed to standardize and simplify support and management. 

Common platform services may include (but are not limited to): 

• Network capabilities such as load balancing, domain name services (DNS), dynamic host control protocol (DHCP) 
• Event logging (Syslog, SIEM) 
• Database Administration 
• Operating System (OS) Administration 

Application developers should use enterprise shared services and common platform services where possible rather than implementing specialized or single-use software. 

Cloud First 

The CMS TRA supports the Federal Cloud Computing Strategy’s (OMB/Federal CIO Kundra, February 14, 2011) Cloud First Policy. For details, please refer to the Network Services and Infrastructure Services sections. 

Pursuant to this objective, CMS is closing its on-premises data centers and is migrating all on-premise applications to cloud environments. Any residual on-premises functionality is migrating to cloud-connected collocation facilities. This strategy is aligned with OMB M-19-19 regarding the Data Center Optimization Initiative. “Agencies may not budget any funds or resources toward initiating a new agency-owned data center or significantly expanding an existing agency-owned data center without approval from OMB.” See the full OMB M-19-19 directive for more information. The objective is to drive meaningful improvement to IT infrastructure, achieve cost savings through optimizations and closures, and foster IT modernization. 

CMS has a robust set of recommended cloud services and capabilities available to enable rapid migration to and deployment within the cloud. See the CMS Strategic Guidance and Preferred Solutions section for further detail. 

Use of Supportable Open Source Software 

The CMS TRA permits the use of supportable Open Source software in CMS Processing Environments. For details, please refer to the chapter on Open Source Software in the Application Services Section. Unsupported software in any capacity cannot be patched in a timely manner; accordingly, any Open Source software without a dedicated support matrix violates the CMS ARS. 

Development Methodology Agnostic 

The CMS TRA applies to all CMS Processing Environments regardless of the approach used to develop and maintain CMS Federal Information Security Modernization Act (FISMA) applications (e.g., using Waterfall, Prototyping, Incremental, Spiral, Rapid Application Development, and Agile). 

Automation 

The CMS TRA encourages the appropriate use of automation to reduce variability and increase speed. In code development and deployment process, continuous integration automation (code checkout/build, static code analysis, dependency check, unit testing), continuous deployment release orchestration, Infrastructure as code can be used to avoid manual errors and manage complexity. In production, operational monitoring can be automated by vulnerability scanning, system health, alerts, etc. 

Sustainability 

The CMS TRA encourages projects to consider sustainability as a critical element of architectural solutions. Projects should apply appropriate attention to future scale, cost, security, operational efficiency, technology, and vendor support. The long-term viability of applications and data products must be considered when integrating any solution into the CMS Processing Environments. Risk and mitigation planning for sustainability should address personnel (technical expertise), operational processes (automation), adherence to Service Level Agreements, and total cost of ownership. 

In cloud environment the sustainability for cost, scalability, service level agreements can be achieved by adoption of cloud native features like dynamic scaling up/down of resources based on usage, use of shared instances vs reserved instance and optimal sizing of resources. 

Accessibility and Section 508 Compliance 

Inaccessible technology interferes with an individual’s ability to obtain and use information quickly and easily. Section 508 of the Rehabilitation Act of 1973 was enacted to eliminate barriers in IT, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. CMS operates many programs that are critically important to people with disabilities. IT is often the vehicle for delivering these programs. The most effective and least costly approach to technology accessibility is for CMS to incorporate accessibility into its IT governance, development, and procurement processes. 

Under Section 508, federal agencies must give federal employees and members of the public with disabilities access to Information Communication Technology (ICT) and information that is comparable to the access available to individuals without disabilities. For CMS Processing Environments and applications, adherence to the Agency’s Section 508 policies include: 

• External and internal user interfaces 
• Hardware and software products, including Commercial Off-the-Shelf (COTS) and custom products 
• Development and maintenance tools 
• External and internal reports or other artifacts created by CMS applications or tools 
• Electronic documentation 
• Support services 

CMS Guidance 

CMS provides resources for Section 508 compliance, including policies, validation procedures, and a list of CMS Section 508 Clearance Officers, at: Section 508 and CMS. 

PREFERRED: Additional CMS guidance and resources are found in Application Development, Web-based UI Services, as well as in the CMS Design System. 

The CMS Section 508 Policy provides a clear rationale and compliance road map for CMS Processing Environments and applications and takes precedence over the CMS TRA. The following paragraphs summarize the basis for these requirements, which is explained further in the CMS Section 508 Policy. 

In 1986, Congress added Section 508 to the Rehabilitation Act of 1973. Section 508 established non-binding guidelines for IT accessibility. On August 7, 1998, the president signed into law the Workforce Investment Act of 1998, which included amendments to the Rehabilitation Act. These amendments significantly expanded and strengthened the IT accessibility requirements in Section 508 and made them binding on federal agencies. 

Section 508 applies to Information Communication Technology, previously referred to as Electronic and Information Technology (EIT). Section 508, as amended, specifically requires that, when federal agencies develop, procure, maintain, or use ICT: 

1. Individuals with disabilities who are federal employees shall have access to and use of information and data that is comparable to the access to and use of the information and data by federal employees who are not individuals with disabilities; and 
2. Individuals with disabilities who are members of the public seeking information or services from a federal department or agency shall have access to and use of information and data that is comparable to the access to and use of the information and data by such members of the public who are not individuals with disabilities (FAR 39.201 and 36 CFR 1194.1). 

Section 501 of the Act requires CMS to be a model employer of people with disabilities. Section 504 requires CMS to ensure equally effective access to its programs and services. CMS can reach both objectives only if it adheres to the requirements of Section 508. 

Relevant Section 508 Standards for CMS IT 

The CMS Section 508 policy is based on the standards described in the following subtopics. 

U.S. Access Board 508 Standards for Information Communication Technology 

The U.S. Access Board’s Information and Communication Technology Revised 508 Standards and 255 Guidelines apply to a wide range of products and services, including but not limited to, the following: 

• Computers 
• Telecommunications equipment 
• Multifunction office machines (e.g., copiers/printers, software, websites, information kiosks, and transaction machines) 
• Electronic documents 

The final rule jointly updates requirements for information and communications technology covered by Section 508 of the Rehabilitation Act and Section 255 of the Telecommunications Act. The Section 508 Standards apply to electronic and information technology procured by the federal government. The Section 255 Guidelines address access to telecommunications products and services and apply to manufacturers of telecommunication equipment. 

Web Content Accessibility Guidelines 2.1 

Web Content Accessibility Guidelines (WCAG) 2.1 define how to make web content more accessible to people with disabilities. WCAG 2.0 is developed through the World Wide Web Consortium (W3C) process in cooperation with individuals and organizations around the world. The goal is to provide a shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.0 is designed to apply broadly to different web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. WCAG 2.0 has three conformance levels, including A (lowest), AA, and AAA (highest). CMS requires that the WCAG 2.0 standards be met at both the Level A and Level AA conformance level. 

Web accessibility depends on accessible content as well as accessible web browsers and other user agents. Authoring tools also have an important role in web accessibility. For an overview of how these components of web development and interaction work together, please refer to the following links: 

• Essential Components of Web Accessibility 
• User Agent Accessibility Guidelines (UAAG) Overview 
• Authoring Tool Accessibility Guidelines (ATAG) Overview 

PDF / UA 

The Portable Document Format/Universal Accessibility (PDF/UA-2) standard, defined by ISO 14289-2:2024, describes technical requirements for universally accessible PDF documents by identifying a set of relevant PDF functions (including text content, images, form fields, comments, bookmarks, and metadata) based on ISO 32000-2:2020 (PDF 2.0) and specifies how they should be used in PDF/UA-compliant documents. Successful access to content within PDFs depends both on compliant documents and compliant PDF programs and assistive technology. PDF/UA therefore also specifies requirements for compliant assistive technology. 

For assistive technologies to work properly with PDF/UA, they must meet the following requirements: 

• They must be able to recognize all structural elements, attributes, and key values used in the specification and output them for the user of a PDF document. 
• They must allow the user to navigate through the document by page number, through the structure tree, or by using bookmarks. 
• They must allow the user to easily set and change the magnification of a PDF document at any time. 

Document Accessibility at CMS and HHS Section 508 Compliance Checklist 

For information about designing accessible documents that adhere to HHS’s requirements, please refer to the HHS Section 508 Accessibility Conformance Checklists. 

HHS Guidance 

HHS Web Standards apply to all HHS Office of the Secretary (OS) websites—including all Operating Divisions (OPDIVs) / Staff Divisions (STAFFDIVs) and Secretarial Priority websites, whether aimed at internal or external audiences. These standards are required for the design and development of all HHS/OS websites and may be adopted by OPDIVs. 

The Framework covers all HHS web sites, internal or external, that are owned, managed, or funded by Operating and Staff Divisions, including CMS, whether developed by staff or acquired through contracts, cooperative agreements, grants, and/or formally established partnerships with other government entities and/or the private sector. The Framework covers traditional web content, including all attached or linked HHS files, and all news and social media, including videos, podcasts, blogs, Wikis, and associated applications on all HHS web sites. 

CMS Testing for 508 Compliance 

CMS uses the following tools and methods to test IT products and artifacts for Section 508 compliance: 

• Manual code review 
• Review of system development test plans 
• JAWS screen reading software 
• Dragon translation software speech-to-text 

• Zoom Text screen magnification software 

   

CMS Strategic Guidance and Preferred Solutions 

Introduction 

The architectural guidelines described by the CMS TRA are designed to provide flexibility to development teams in choosing a technical approach, and yet there are cases where CMS has a strongly preferred approach or solution option. This section provides information about such Strategic Guidance and Preferred Solutions. 

CMS systems and data must be protected from a constantly evolving threat and vulnerability landscape. Aligning to strategic guidance and utilizing preferred solutions strengthens CMS security posture through extending the use of thoroughly validated and tested security controls and procedures. Maintaining CMS data within the CMS security boundary facilitates CMS stewardship of the data. 

The use of preferred solutions also shortens time-to-delivery, reduces redundant development, facilitates efficient use of infrastructure, and leverages CMS strategic investments and economies of scale. This aligns to the TRA Guiding Principle of Reuse as well as broader federal IT policy (see Office of Management and Budget (OMB) Memorandum M-19-16, Centralized Mission Support Capabilities for the Federal Government, April 26 2019, and Federal Shared Services). 

The goal is to speed secure system deployment by utilizing existing solutions that may provide built-in automation, approved security configurations, and pre-authorized infrastructure. Use of these solutions is strongly encouraged unless there is a more compelling business case for an alternative. 

CMS encourages its organizations to maximize the benefits of utilizing the Microsoft 365 Government Community Cloud (GCC) capabilities through the CMS tenant. All CMS email accounts include G5 subscriptions that provide access to Office 365 applications, storage, and other advanced security and data management features. CMS has completed transition from Zoom to Microsoft Teams for all CMS-hosted meetings and is migrating from the on-premises SharePoint 2019 environment to SharePoint Online. 

The CMS TRA will provide high-level information about preferred solutions. Detailed information including their setup and use will be found through the supplementary sources/ links to additional information. 

Note that hyperlinks in this section may refer to CMS internal information sources; a CMS EUA ID and access to the CMS intranet may be required for access. 

Additionally, links to Strategic Guidance and Preferred Services will be included throughout the TRA, aligned to associated TRA guidance. 

PREFERRED - CMS strategic guidance and preferred solution information throughout the CMS TRA will appear like this. 

Enterprise Services 

The preferred solutions in this section are CMS “enterprise services”, based on an expanded definition of the term. The updated CMS definition of enterprise services reflects that these capabilities may be developed and provided by any CMS Center or Office or by a vetted partnership of Centers/Offices. This includes but extends well beyond centrally provided “shared services”. In the new model, enterprise services can be leveraged as a shared capability or provide a pattern for a new implementation if required. 

A CMS enterprise service may be leveraged without onboarding with an established support organization or a central enterprise instance. CMS encourages the use of the most appropriate deployment model depending on business requirements. A project might, for example, choose to deploy a parallel instance but still use the standards and processes of the enterprise instance, potentially enabling them to utilize existing support staff. An existing, validated solution can be used as an architectural pattern, with any refinements shared back with the original. 

The overall group of enterprise services form a federated set of capabilities which development teams can tap into, avoiding duplication and aligning with CMS standards. 

Data Stewardship and Governance 

Sound data stewardship practices are essential to the protection of CMS data. The risk of data compromise is exacerbated when CMS data is moved or copied outside of the CMS security boundary. With the shift to flexible cloud computing environments, CMS now has the capability and capacity to provide for very large and complex data storage and analytics requirements. Keeping CMS data and associated data processing and analysis within the CMS security boundary enables CMS to maintain provenance and proper stewardship of CMS data. 

As such, CMS policy is that all CMS data remain within CMS authorization boundaries, except for public data released by CMS. Business requirements to do otherwise will be reviewed on an exception basis to ensure appropriate controls (which may include a Data Use Agreement) are in place. A new TRA section, Data Sharing and Governance provides additional information on this topic. It also introduces Business Rule BR-DG-1, which reinforces the imperative to keep CMS data inside CMS boundaries, while Recommended Process RP-DG-2 suggests some ways to accomplish this. 

CMS Cloud is the preferred environment for CMS data storage and analytics. 

Preferred Solutions 

CMS Preferred Solutions are presented here in the following categories: 

• CMS Hybrid Cloud 
• CMS Enterprise Data 
• CMS DevSecOps Support 
• CMS Collaboration Capabilities 

Note that the list of Preferred Solutions will evolve over time. Additional sections and solutions will be added in future TRA releases. 

CMS Hybrid Cloud and CACHE 

The CMS TRA supports the Federal Cloud Computing Strategy’s (OMB/Federal CIO Kundra, February 14, 2011) Cloud First Policy as well as the Federal Cloud Computing Strategy’s (OMB/Federal CIO Kent, June 24, 2019), Cloud Smart Policy. 

CMS Hybrid Cloud is the strongly preferred hosting platform for all CMS developed applications. It provides the most operationally integrated and cost-effective platform solutions. In addition to “self-service” cloud computing with guardrails, CMS Cloud features managed Infrastructure-as-a-Service (IaaS) environments for both Amazon Web Services (AWS) and Microsoft Azure Government (MAG), as well as for CMS on-premises data centers. 

The CMS TRA chapters on Cloud Infrastructure and Virtualization, among others, address CMS Hybrid Cloud services. 

CACHE and DRaaS-CACHE 

The Continuously Available CMS Hosting Environment (CACHE) service offerings provide the primary on-premise infrastructure hosting platform, with seamless integration with the overall CMS hybrid enterprise environment. These include: 

• Geo-diverse data center and hosting within the DRaaS-CACHE FISMA boundary 
• Full Infrastructure-as-a-Service (Iaas) virtualized environment 
• Application Workload hosting across multiple computing platforms, including Mainframe, Open Systems (x86), and hybrid cloud, as well as multiple storage platforms, including disk, tape, and file-level 
• Comprehensive Disaster Recovery as a Service (DRaaS) with next-gen replication capabilities across multiple technology platforms 
• Enterprise Services that include robust Application and Network Load Balancing, Domain Name Service (DNS), Directory Services (LDAP), and Time Services (NTP) 

Critical applications that support CMS programs and operations should, if managed by CMS, rely on DRaaS-CACHE to protect both their system availability and their data. 

CMS Enterprise Data 

CMS maintains several preferred solutions for accessing and managing CMS program data: 

• The Integrated Data Repository (IDR) Cloud is a high-volume cloud data platform integrating Medicare claims with beneficiary and provider data sources, as well as such ancillary data. This robust, integrated data supports mission-essential analytics in CMS and in other government agencies. It also helps to prevent the proliferation of replicated data sources that perpetuate data inefficiency, duplication, inconsistency, inferior quality, and increased costs for associated infrastructure. 
• The IDR Enterprise Data Product (EDP) now supports the data mesh functions of the previous Enterprise Data Mesh (EDM), which was decommissioned in 2024. Based on the IDR’s Snowflake implementation, the EDP maintains a central point where systems and individual users can find, locate, access, and use CMS enterprise information with “data in place.” This enables data owners and curators to focus on data and data quality while also enabling consumers to bring their own preferred compute resources, analytics, and APIs. Additionally, the EDP enables a wide spectrum of programs and consumers to leverage program data sets with close to zero provisioning time with their choice of tools and technologies optimal for their use case. 
• CMCS DataConnect is an all-in-one cloud analytics platform for the Center for Medicaid & CHIP Services (CMCS) data. DataConnect provides a range of capabilities to streamline Medicaid and CHIP program analysis, monitoring, and oversight. It includes dashboards, tools, and datasets to enable CMCS staff, researchers, and other data experts to produce meaningful insights from complex data. 
• CMMI Analysis and Management System (AMS) holds key information about CMMI models and demonstrations. AMS helps stakeholders access information about, and collected by CMMI models. 
• CMS Master Data Management (MDM) has provided a single point of access to a singular, synchronized, comprehensive and ID-resolved authoritative source of Provider and other data for use by CMS and other external organizations. MDM provided support across multiple CMS business units with a focus on eliminating redundancy, inconsistency, and fragmentation of CMS data. IDR, IDR Enterprise Data Product, and CMCS DataConnect have all relied on this authoritative data. 

MDM is scheduled to be retired in February 2027. Support of this data management functionality is migrating to the CMMI Analysis and Management System (AMS), Integrated Data Repository (IDR) Cloud, IDR Enterprise Data Product (EDP), and CMCS DataConnect. ID Resolution will be performed as needed within these systems, as well as by the Center for Clinical Standards & Quality (CCSQ) and the Center for Program Integrity (CPI). 

• CMS Research Data Assistance Center (ResDAC) provides technical assistance to researchers interested in CMS Medicare and Medicaid data. Various data sets are available; however, access is restricted to approved research requests. Public use data files (which contain no protected information) are available via data.CMS.gov 

CMS DevSecOps Support 

A key goal of the CMS TRA is to support sound and secure software development practices. The DevSecOps tooling landscape is vast, and it can be challenging to determine which solutions are the best match for project requirements. CMS has preferred platform and tool options available which can help development teams manage and secure development pipelines. 

Enterprise Services are preferred over other project specific services as they offer potential operational and/or cost benefits. Existing systems are encouraged to utilize enterprise services wherever possible. 

• CMS DevOps Tools 
  • GitHub is a common repository platform, used to distribute open-source software and other content. Thus, it is both a DevOps and a collaboration tool. Premium Enterprise GitHub provides advanced management and security features. CMS has implemented GitHub Copilot, an AI coding assistant (see TRA recommended practices for AI-Assisted Coding). 
    • SaaS GitHub instances include OC Tools-supported CMSgov and theCMCS | MACBIS organization that collaborates with states and other Medicaid and CHIP partners. 
    • CMS Hybrid Cloud supports SaaS-based OIT Enterprise GitHub, which provides enterprise-grade collaboration, security, and administration. 
    • OC GitHub Enterprise is supported by the Web Help Service Desk. It is primarily for support of public-facing medicare.gov, healthcare.gov, cms.gov, and their related applications and ADOs. During the first half of 2026, the OC Web and Emerging Technologies Group (WETG) is migrating these repositories from this internal GitHub to CMSGov. 
    • CCSQ manages an additional GitHub Enterprise instance. 
    • The Open Source Program Office provides an additional GitHub repository containing additional tools, templates, and other information about using and share open source software. 
  • CloudBees CI is a continuous integration, deployment, and delivery (CI/CD) server solution 
  • JFrog Platform is comprised of Artifactory, a binary repository manager and XRay, an add-on to the Artifactory product used to enhance the security posture 
• CMS Testing 
  CMS provides Testing as a Service (TaaS), a CMS Cloud offering that provides a suite of products support application teams with test case management, functional and regression test execution, and performance test execution. This includes: 
  • Selenium Box 
  • Enterprise TestRail 

  • Distributed Load Testing on AWS (DLTA) 

     

• CMS Security Scanning and Analysis 
  These CMS Cloud inspection and analysis tools support application security and vulnerability management for both developers and the security team: 
  • SonarQube, which provides static code analysis. Static code analysis attempts to highlight possible vulnerabilities within ‘static’ (non-running) source code by using analytic techniques. 
  • Snyk (“sneak”), a SaaS-based system composition analysis (SCA) tool that enables applications to be developed and built securely. SCA identifies the open-source software in the codebase. This analysis is performed to evaluate security, license compliance, and code quality. It proactively finds and fixes vulnerabilities in codes, open-source dependencies, container images and Infrastructure as Code (IaC) configurations, and offers context, prioritization, and remediation. 

CMS Collaboration Capabilities 

A number of enterprise collaboration tools are available within the CMS environment to facilitate data sharing and team communications, supported by OIT and the Office of Communications (OC). These include: 

• Jira and Confluence: 
  • Atlassian Jira is an application lifecycle management solution that helps teams plan, manage, and report on their work. It is used for bug tracking, issue tracking and project management. 
  • Atlassian Confluence is a team workspace providing teams a place to create, capture, and collaborate on project information including text, tables, images, and other content. 

The CMS Cloud Agile Tools Team supports Enterprise Confluence and Enterprise Jira, with integrated TestRail. The Office of Communications provides OC Jira and OC Confluence, primarily for support of public-facing medicare.gov, healthcare.gov, cms.gov and their related applications. 

• SharePoint is an application platform that allows organizations to store and organize any content and information. That includes documents, images, videos, news, links, lists of data, web pages, and tasks. The CMS Enterprise SharePoint Support (ESS) team supports the SharePoint Online (SPO) environment. 
  • CMS SharePoint Online (SPO) is the new home of CMS-wide enterprise information. In addition to new sites being created for all CMS Centers and Offices, the entire contents of the decommissioned On-Premise SharePoint have been migrated to cmsgovonline.sharepoint.com. These include: 
    • share.cms.gov 
    • capms.cms.gov 
    • cmsintranet.share.cms.gov 
    • mysite.share.cms.gov 
    • pbrs.cms.gov 
  • SharePoint Online is part of the CMS Microsoft 365 SaaS enclave. 
• Slack is a workplace messaging tool through which CMS employees and contractors send messages and files, defining and using specialized and general channels that contain message threads. Some chat and meeting functions will migrate to Microsoft Teams. 
• Microsoft Teams is also part of the CMS Microsoft 365 Government subscription. Microsoft Teams is a collaboration tool designed to enhance productivity by integrating with other Microsoft products and providing a centralized space for communication, file sharing, chat, and meetings. Preliminary guidance is available. Transition to Teams from Zoom Workplace took place during 2025. Partial transition from Slack is also planned. 
• Another feature of Microsoft 365 is OneDrive. OneDrive provides backing cloud storage for M365 tools such as Word, Excel, PowerPoint, Teams, and SharePoint. Note that CMS Enterprise SharePoint Online is managed separately from SharePoint sites for Teams and Channels. CMS is migrating CMS Box users to OneDrive, primarily for secure sharing within CMS. Box remains available, primarily for external sharing. 

Please also see CISO Memorandum 25-01: Updated Best Practices and Guidance for the Use of Approved CMS Collaboration Tools. 

Artificial Intelligence Guidance 

Introduction 

Artificial Intelligence (AI) tools and technology are rapidly evolving with the promise of enabling increased efficiency, insight, and analysis across a broad range of use cases. CMS is embracing AI to improve health care administration and delivery. At the same time, policies, processes, and mechanisms are being established to ensure that AI-enabled systems at CMS are developed, deployed, and used responsibly and ethically, mitigating risks and protecting sensitive information while also maximizing benefits for CMS and beneficiaries. 

Aligned to federal guidelines (see ai.cms.gov), this section provides current AI-related policies and recommended practices at CMS. Given the dynamic nature of the AI domain, frequent updates and changes are expected. It is not intended as a primer on AI technologies or approaches. Additional information on those topics can be found within the CMS AI Playbook and Technical Application Resources. 

More policy guidance can be found in the HHS Intranet: “Reminder of Existing HHS IT User Policies Relevant for Third-Party Generative AI Tools,” “HHS Policy for Securing Artificial Intelligence (AI) Technology,” and “HHS Policy for Rules of Behavior for Use of Information and IT Resources.” 

Additional Considerations 

Accountability and Oversight 

All individuals and teams employing AI or Machine Learning (ML) at CMS are responsible for the system's output, regardless of the model or tools used. The “owner(s)” of this output are also required to use the appropriate mandated security controls for “sensitive” and especially “privacy data” assets. Continuous human oversight is required to ensure CMS and federal guidelines are met. 

Risk Management and Security 

AI Model Supply Chain and Provenance 

In the modern information security landscape, AI-driven supply chain attacks are a concern. These can introduce malicious code through compromised AI models, data, or code repositories. Teams deploying AI models should ensure the provenance and integrity of AI components used in production. 

Example: The “Model Namespace Reuse” attack, demonstrated against Google and Microsoft products, highlights the risk of trusting a model based on its name alone. This form of attack can enable a threat actor to gain code execution permissions and gain access to underlying infrastructure. 

Recommendation: Implement System Composition Analysis to verify the origin and integrity of AI dependencies. 

Embracing a Zero-Trust Architecture for AI 

Using AI technology that can perform outbound internet requests can introduce risk to CMS environments, including sensitive code and data that could be transmitted outside the network. 

Recommendation: Teams should perform threat-modeling and risk assessments to ensure proper network segmentation and limit an AI tool’s access to only the necessary resources to contain the blast radius of any potential breach. Implement Data Minimization principles to ensure AI tools access only the information strictly necessary for their function. See The TRA section Zero Trust Architecture. 

Monitoring, Versioning and Observability for AI and Production Operations 

System maintainers must implement observability to understand how their AI systems are behaving over time. This requirement supports debugging, security, and continuous improvement, and ensures alignment with OMB M-25-21 and M-25-22. 

Recommendation: Track traces, evaluations (EVALs), prompt management or versioning, and key metrics for production systems using AI. 

Recommendation: Prompts — AI system prompts used for production at CMS systems should be versioned (See BR-SCM-1). Store prompts (or reusable “recipes”) and review them and measure their performance over time. 

Data Handling, Data Retention and Privacy 

Privacy-Preserving Techniques 

When developing and testing AI models that handle sensitive data, teams should adopt privacy-preserving techniques like federated learning and homomorphic encryption. These methods allow for model training and inference on encrypted or decentralized data without direct sensitive data exposure. 

Use of Synthetic Data for AI Initiatives 

The use of synthetic data is highly recommended to avoid the use of sensitive Personally Identifiable Information (PII) or Protected Health Information (PHI) in development and lower environments entirely. This mitigates the risk of exposure and simplifies compliance. 

Examples: AI techniques like Generative AI, GANs and VAEs, and initiatives like SyntheticMass and Synthea™ [can also be used to avoid the use of sensitive PII or PHI from development and lower environments entirely at CMS. 

Review Data Rights, Retention Policies prior to the use of External AI Tools and Services 

The use of AI tools, services or infrastructure external to CMS may introduce risks, including companies that train or fine-tune AI models using CMS non-public code, data or metadata. 

Recommendation: Application teams, CMS system owner or business owners introducing new AI technology into their systems should ensure compliance with CMS security and privacy requirements, and that appropriate data use agreements are in place before incorporating external AI systems that can access non-public CMS data . Teams should be especially careful with Terms of Use and Agreements that enable the training, share or selling of CMS data. For inquiries, consult with the CMS Privacy Office. 

AI Services and Data Retention: Content generated by your AI system may be subject to Data Retention policies and FOIA. For inquiries, consult with Records_Retention@cms.hhs.gov. . 

Overall AI Business Rules 

BR-AI-1: AI Tools and Services Must Meet Federal AI, Cybersecurity and Privacy Standards in the Handling of Sensitive Data 

Sensitive data, including Protected Health Information (PHI), Sensitive Personally Identifiable Information (SPII), classified, export controlled, trade secret and other confidential information may only be used with AI tools and services that meet HHS and CMS Cybersecurity Standards. 

To ensure compliance and protect privacy, consult with the CMS Privacy Office in relation to AI tools and Services that could handle sensitive data. 

Rationale: 

All HHS and CMS policies regarding AI use, Personally Identifiable Information (PII) protection, and data security (including storage, transmission, and sharing) must be adhered to in order to ensure proper implementation of AI risk management practices per the HHS AI Strategy and HHS Compliance Plan for OMB Memorandum M-25-21. 

Also see in the TRA: BR-F-5: Any System That Processes CMS Data Must Be Covered by a CMS ATO; BR-SQ-6: De-Identification of Production Data Is Required in Non-Production Environments; NIST SP 800-122, “Guide to Protecting the Confidentiality of Personally Identifiable Information (PII);”NIST SP 800-18, ”De-Identifying Government Datasets: Techniques and Governance.” 

BR-AI-2: High-Impact AI Use Cases Must Meet Minimum Risk Management Practices 

A high-impact use case, as defined in the Office of Management and Budget (OMB) Memorandum M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, is one where the AI’s output serves as a principal basis for decisions or actions that have a legal, material, binding, or significant effect on specific critical areas. 

A CMS AI Governance risk assessment will determine if an AI use case is high-impact. All CMS high-impact use cases must apply minimum risk management practices in accordance with M-25-21. 

Contact CMS IT_Governance for an AI Governance Risk Assessment. 

Rationale: 

Non-approved AI tools may retain or use submitted information in ways that could expose CMS sensitive data. Attackers may be able to steal sensitive data by manipulating prompts or exploiting vulnerabilities in AI systems. Non-approved AI tools may not be compliant with evolving federal regulations regarding data protection, records retention, consumer rights, and algorithmic transparency. Additionally, these tools may lack the security controls and oversight mechanisms required for handling federal government data within established security boundaries. 

BR-AI-3: Foreign Entity AI Tools May Only Be Used if Deployed on CMS Infrastructure 

With the rapid introduction of new AI capabilities into the market, it can be difficult to determine which are aligned to federal government requirements. AI technology from foreign entities can be used if it’s deployed on CMS infrastructure and does not send data to the internet. This aligns with the principle of CMS data staying within the United States (see BR-SAAS-8: CMS Data Must Always Reside in the U.S.). Such deployments must utilize normal CMS and AI governance processes, including the CMS Risk Management Framework and the NIST AI Risk Management Framework. 

Rationale: 

The use of unapproved or foreign AI tools and models could compromise CMS information. Foreign AI models, especially those from countries with broad government access to data, could be used for surveillance and the collection of sensitive personal information. Third-party AI models may lack sufficient security controls, potentially exposing the systems to data breaches. 

BR-AI-4: Human Review Must Follow Use of AI Tools to Write CMS Policies 

Individual CMS employees are accountable for official CMS policies. AI tools are only to be used in support of and not as a substitute for human decisions and oversight of CMS strategic or compliance-related activities. Humans must be in the loop. 

Rationale: 

AI tools lack the capacity for human judgment and critical thinking, which is crucial for interpreting complex situations, considering ethical implications, and crafting policies that fully align with CMS’ values and objectives. AI tools may generate false or misleading information as factual and may reflect biases present in their training data. 

BR-AI-5: Do Not Rely on AI for Final Decisions for “High Impact” Cases 

AI should provide advice or recommendations; final decisions must be made by qualified staff with documented oversight. AI use cases for these purposes are considered potentially “High-Impact AI,” and actions they support may risk compliance with privacy and civil rights requirements. 

Rationale: 

OMB memorandum M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust defines “High-Impact AI” as “AI with an output that serves as a principal basis for decisions or actions with legal, material, binding, or significant effect on: 

1. “an individual or entity’s civil rights, civil liberties, or privacy; or 
2. “an individual or entity’s access to education, housing, insurance, credit, employment, and other programs; 
3. “an individual or entity’s access to critical government resources or services; 
4. “human health and safety; 
5. “critical infrastructure or public safety; or 
6. “strategic assets or resources, including high-value property and information marked as sensitive or classified by the Federal Government.” 

AI tools lack the capacity for human judgment and the nuanced perspective necessary to make complicated decisions. High-Impact AI risks need to be managed. 

BR-AI-6: AI-Supported Official Actions Are Subject to Records Retention Requirements 

When AI provides work products in support of official CMS actions that would be subject to records retention, those work products become part of the record and must be retained according to the applicable records retention schedule. Those AI-created work products must include the AI model version and the prompt(s) used. 

Rationale: 

“Adequate and proper documentation” (per 44 U.S.C. Chapter 31 §3101) supporting official CMS actions are part of the action. This supports transparency of AI use. For more information, consult with the OSORA Issuances, Records & Information Systems Group. 

AI-Assisted Coding Guidance 

Threat Modeling for AI Systems 

See TRA Recommended Practice AD-SS-8: Perform Threat Modeling During the Design Phase to Identify Potential System Threats. Additional recommended practices regarding performing Threat Modeling for AI systems can be found in A Practical Understanding of Threat Modeling for AI Systems 

AI Recommended Practices 

This section provides Recommended Practices information for AI overall and for specific AI concepts. 

RP-AI-1: Release and Maintain AI Code as Shareable Open Source Software 

CMS projects must prioritize sharing AI code, models, and data government-wide, consistent with the Open, Public, Electronic and Necessary (OPEN) Government Data Act. Custom-developed AI code is also covered by the SHARE-IT Act and OMB M-25-21. More information is found in the TRA Application Development section on Open Source Software. 

AI Prompt Crafting 

Prompt Crafting is the practice of writing clear and helpful directions that a large language model (LLM) can use to generate more accurate, relevant, and useful outputs for a given task or question. This is like providing a person the right level of contextual detail and specific instructions to complete a task in the manner it is to be completed. For the best results using LLMs, it is important to build instructions and relevant details in a similar manner- by providing the task to accomplish, the role that the AI is taking on to complete it, any relevant reference materials as context, and the desired response format. 

Prompt Crafting is the bridge between human intent and LLM capability. It is the heart of what determines the quality and usefulness of AI-generated responses from LLMs. In the context of CMS Chat, effective prompting enables users to interact with documents, synthesize information across sources, and generate new content effectively. 

For CMS, effective Prompt Crafting matters because it: 

• Improves the accuracy and reliability of AI-generated outputs 
• Increases consistency in AI interactions across the organization 
• Reduces the likelihood of AI hallucinations or incorrect responses 
• Enhances the user experience of staff using CMS Chat 
• Increases the efficiency of the AI and reduces time and compute costs 

The following best practices can be applied to effectively use chatbots like CMS Chat to enhance the user experience and ensure more accurate and useful AI interactions 

RP-AI-2: Clearly define the context of the prompt 

Be specific about which aspects the AI is to focus on and what type of analysis is needed. Provide relevant background information, specify limitations, include domain-specific terminology, and define the scope of the response 

Example: “Within the context of the 2024 Medicare Physician Fee Schedule final rule, focusing specifically on telehealth provisions, analyze the requirements for audio-only services.” 

RP-AI-3: Clearly define the role the AI should adopt 

This approach provides clear context for the AI’s responses, helps maintain consistent tone and expertise level, and enables more targeted and relevant outputs. 

Example: Instead of “Tell me about Medicare Part B coverage,” use “Within the context of the 2024 Medicare Physician Fee Schedule final rule, focusing specifically on telehealth provisions, analyze the requirements for audio-only services.” 

It is also possible to provide roles that the AI can use to tailor the generated output. 

Example: “Act as an experienced Medicare benefits counselor with 15 years of experience explaining coverage to beneficiaries. Explain Medicare Part B coverage in simple terms.” 

RP-AI-4: Break down complex requests into clear, sequential steps 

This approach helps AI systems provide more organized and concise responses. When analyzing documents or synthesizing information, structure prompts to guide the AI through the process. 

Example: “First, analyze the key points of this policy document. Then, identify any changes from the previous version. Finally, summarize the potential operational impacts for the policy team.” 

Sometimes, it’s best to break these steps into separate prompts for each step. AI have a maximum amount of response length they can provide, so allowing them to focus on one step at a time, with a full response at each stage, may provide better end results. This is also true when you have large documents. The AI can be asked to review the first chunk of text, then the next, and so on until the needed details are derived from the entire document. 

Example: 

• Prompt 1: “Analyze the key points of this policy document.” 
• Prompt 2: “Review the key points provided and identify any changes from the previous version.” 
• Prompt 3: “Based on the output in the previous response, summarize the potential operational impacts for the policy team.” 

RP-AI-5: Provide Guidelines 

Outline any scoping, rules, writing styles, or specify any specific format requirements for the response, such as using headers, bullet points, or specific citation formats. Clearly communicate how the information should be presented. 

Example: “Present your findings in a structured format using headers to break up the text, followed by a few sentences that explain the header, and then bullet points to breakdown the main points.” 

Sometimes, more complex guidelines and response formats are necessary. It’s possible to instruct many AIs to respond in structured formats while also demanding it utilize a specific approach, style, or scope. 

Example: “Present your findings in a structured table format. I’d like columns A, B, C, and in A, please create categories for the text, followed by a brief description of each in B, then bullet points to breakdown the main points in C. Write in the style of a CMS Policy Expert but be concise and clear. Avoid jargon or complex topics. Instead, focus on clarity and simplicity.” 

RP-AI-6: Create New Chats or Sessions When Switching Topics 

It is best to create a new chat or discussion session when switching topics. The context of conversations in generative AI prompting sessions is typically stored and available throughout a single chat. Unless the context of the entire chat is needed for the next query, it is recommended to create a new conversation, so the AI does not hallucinate or conflate topics. For example, if the AI was asked in one chat to clean up a project presentation, then instead of asking how to write a policy document in the same chat, start a new one with the right level of context provided to ensure the AI has no distractions from the desired intent. 

RP-AI-7: Use Structured Prompts 

The best prompts are structured with all the details covered in the previous best practices in mind. A recommended structure template to get the best results is: 

[Task] + [Role] + [Guidelines] + [Reference Context (Reference Materials)] 

Each are further defined below: 

• [Task] – The action(s) you wish the AI to take based on the [Role], [Guidelines], [Format Requirements], and [Reference Context (Reference Materials)] 
• [Role] – The role that the AI is to take on to complete the [Task] 
• [Guidelines] – Rules or guidance for the AI to ensure it accomplishes the task as expected. This may include the expected output structure/format or instructions on how to write (perspective, style, etc.), and other guidance for the AI 
• [Reference Context (Reference Materials)] – Relevant attachments, details, documentation, resource materials, etc. that can act as the source of truth for the AI to accomplish its [Task] 

Example: 

Task: “Please create a categorized list of Medicare Part B rules relevant to a retiree from Tennessee.” 

Role: Act as an experienced Medicare benefits counselor with 15 years of experience explaining coverage to beneficiaries. Explain Medicare Part B coverage in simple terms. You complete TASKS based on the GUIDELINES and REFERENCE CONTEXT and respond as outlined by the FORMAT REQUIREMENTS 

Guidelines: Please respond in a bulleted or tabular format. Responses should be concise, but fully explained in a style most suitable to the intended audience. Note if any relevant details may be missed and what additional actions should be taken to ensure the [Task] can be completed. 

Reference Context: *Attached Document* “OR [Copy/Paste text from the appropriate documentation]” 

RP-AI-8: Use Iterative Refinement 

Prompt Crafting is not a one-time process but rather an iterative approach that involves starting with a basic prompt, evaluating the response, refining the prompt based on the output, and then testing and validating any improvements. It is also a creative process — one that benefits from continuous experimentation and adjustment to ensure the AI’s responses align with evolving requirements and user needs. By reviewing each new output, identifying gaps or inaccuracies, and incorporating feedback into the next version of the prompt, steady improvements will be achieved in both the clarity and effectiveness of AI interactions. 

RP-AI-9: Recommended AI-Assisted Development Methodologies 

Recommended Workflow Steps: 

1. Specify: Create a formal, human-readable specification that defines the goals in accordance with best-practices. 
2. Plan: Use AI to generate a technical plan based on the spec and enterprise standards. 
3. Implement: Use AI to break down the plan into small, testable tasks and generate code. 
4. Review and Verify: A developer reviews each code change for accuracy, security, and quality. Automated testing and security checks run in CI/CD. 
5. Iterate: If issues are found, refine the specification or prompts and re-run the cycle.  

CMS Processing Environments 

A CMS Processing Environment is defined as any computing environment that creates, consumes, and/or stores CMS data, as defined in the CMS Data and CMS Sensitive Information definitions. The CMS TRA applies to all CMS Processing Environments that CMS controls. This includes all production environments having a CMS Authorization To Operate (ATO) and any development or testing environments residing in data centers that host CMS workloads. 

The CMS TRA refers to production environments as ATO(ed) environments. CMS TRA guidance for production environments also applies to any non-production environment with an active CMS ATO, as such environments must be managed and secured like a production environment to maintain its ATO. 

By convention, there are three types of processing environments: Development Environments, Validation Environments (sometimes known as Implementation), and Production Environments (also known as Operational environments). These environments provide a set of high-level stages corresponding to a software promotion model, which follows the baseline progression as follows: 

• Development environments support multiple business application baselines, including the execution of functional testing, unit testing, application integration testing, and regression testing. When there is a significant defect in a baseline in one of the other environments, the baseline returns to the Development environment for repairs and other corrective actions. 
• Validation environments provide a staging area for production releases and evaluation of the final release versions of production code, database, and related packages for business applications. Many non-functional requirements (security, privacy, performance, and various “ilities” such as scalability and reliability) are tested here. CMS intends the Implementation environment for performance and stress testing, system and user acceptance testing, final integration testing, and security assessment. The Validation environment should be comparable to the production environment to promote CMS business owner confidence in the performance and functionality of the system. 
• Production environments provide stability and security for the final release versions of production code, database, and related packages. All production environments are required to have a CMS ATO. 

Projects may select different naming conventions for their lower environments. CMS recommends, however, using Development and Validation because of their frequent use in CMS IT. Projects may choose to create additional lower environments as required to facilitate testing (e.g. Test environment; Integration environment). Projects may choose to perform activities such as Independent Validation and Verification (IV&V) or User Acceptance Testing (UAT) in whichever environment makes the most sense for the project. 

Each environment should emulate the production environment; accordingly, the infrastructure must mirror production in versions, patch levels, configurations, and network. Development and testing services may be provided, such as performance testing, functional compatibility testing, and performance monitoring. 

Business application code and database changes, including break-fix, must be tested successfully in a development or test environment before promotion to the next higher environment. Related changes to infrastructure services (such as firewalls and switches) must be tested in a development or test environment before deployment to the implementation environment. 

Non-ATO(ed) environments may not contain sensitive information. As described in Business Rule (BR) BR-F-5, CMS prescribes the removal or replacement of personal identifiers, other personalizing information, and other CMS sensitive information to render information anonymous before it may be loaded into an environment not covered under an ATO. Redaction of sensitive data must occur in an environment covered under an ATO. Existence of Personally Identifiable Information (PII), Protected Health Information (PHI), or other CMS sensitive information in any environment causes that environment to require production-level security, privacy controls, and coverage by ATO, regardless of its name. 

Development Environments 

A development environment supports business application baselines during code and database development, and for development testing functions. The data center may support multiple instances of a development environment to accommodate development of multiple variants of a business application. 

Validation Environments 

The validation environment provides a secure, locked-down staging area for production baselines and for evaluating the final release versions of the production code, database, and related packages for the business applications. It is used to perform implementation testing and to complete business application testing before release into the production environment. This includes validating system performance, events, alerts, and notifications. CMS may provide support from this environment for end-user training on system usage and functionality as well as for access to training data. 

There may be multiple instances of a validation environment to support the testing of a business application (or multiple versions) and its preparation for promotion to the production environment. The validation environment must maintain an image of the last successfully tested version of a business application code and database. 

The validation database should be approximately the same size as the production database (for realistic performance testing) and, if it has been issued an ATO, may contain sensitive information. If it contains sensitive information, the implementation database must be protected to the same standards as the production database (please refer to BR-F-5.) 

All changes to the validation environment must be subject to CMS change management. Additional requirements and constraints include, but are not limited to: 

• Scheduling of operations in the implementation environment must include adequate time to roll back any changes, for example, changes to business application code and databases, and any infrastructure changes. 
• Troubleshooting of business application code and database errors will be limited to Root Cause Analysis (RCA) only. 
• Business application code and database changes, including break-fix changes, must be tested successfully before their promotion from the implementation environment to the production environment. 
• Changes related to infrastructure services must be tested successfully in the implementation environment before promotion to the production environment. 

CMS ATO(ed) and Production Environments 

CMS production environments are required to be ATO(ed) environments. CMS TRA guidance for production environments also applies to any non-production environment with an active CMS ATO, because such an environment must be managed and secured like a production environment to maintain its ATO. 

An ATO(ed) environment provides a stable, secure, locked-down operational environment to complete the business application production baseline. This environment is inaccessible except to authorized operations and security personnel. Access to business applications will be provided via approved user interfaces only. Only the Administrator role will be granted server-level access to the CMS business applications in the ATO(ed) environment. (and must follow a Software Development Life Cycle (SDLC) driven promotion process). 

All changes to the ATO(ed) environment must be subject to CMS change management. Additional requirements and constraints include, but are not limited to: 

• All production environments are required to have a CMS ATO. 
• All business application code and database changes, including break-fix, must be tested successfully in the implementation environment before promotion into a CMS production environment. 
• All related changes to infrastructure services must be tested successfully in the implementation environment before deployment to the CMS production environment. 
• Production-readiness testing is required for all initial deployment of business applications. Troubleshooting of business application errors will be limited to RCA only. 
• Monitoring & Reliability Testing is required for all initial deployment of business applications. New business application code, databases, and infrastructure migrated into the ATO(ed) environment will become part of the production baseline. 

The quality of CMS’s production environments reflects on the organization’s reputation and public trust. Although the production environment may be used for quality assurance and testing, the CMS TRA generally discourages such use, suggesting instead that the validation environment be used for such tasks. This is true if the code or data tested could lead to incorrect or misleading results or behavior. The production environment may also be used for community verification of quality assurance of data. 

Non-CMS Processing Environments 

The CMS Processing Environments may interact with non-CMS processing environments. 

Third-Party Websites and Applications 

The HHS Office of the Chief Information Officer (OCIO) Policy for Social Media Technologies, March 07, 2012, Policy 2010-0003.1 includes managing the use of Third-Party Websites and Applications (TPWA) and establishes requirements for Department access to web-based technologies that are not exclusively operated or controlled by HHS. This policy is consistent with federal guidelines and regulations. 

HHS-OCIO directs that TPWAs must be addressed in a Privacy Impact Assessment (PIA) and may require a Security Impact Analysis (SIA). 

OMB Memorandum M-10-23, Guidance for Agency Use of Third-Party Websites and Applications, states: 

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. 

Social Media 

The use of social media at CMS is governed by the Guidelines for Secure Use of Social Media issued by the CIO Council, and by HHS-OCIO Policy for Social Media Technologies. Also, see HHS Social Media Policies.  

Services Framework Architecture 

Services Framework - Concept 

The CMS Services Framework provides a standardized template for implementing systems at CMS. This template or pattern details security and interoperability requirements. The goal of the framework is to maintain the integrity of CMS applications and data. 

CMS Services Framework - Principles 

CMS utilizes a Defense-in-Depth (DID) and a least privilege strategy to protect its assets. Defense-in-depth is a security strategy that uses a series of layered, redundant defensive measures to protect sensitive data, personally identifiable information (PII) and information technology assets. If one security control fails, the next security layer thwarts the potential cyber attack. Least privilege is the concept of restricting access rights of users to only those resources that are required for performing their legitimate functions. CMS’ services framework provides a structure for implementing security challenges to ensure CMS resources are protected. 

The goal is to protect CMS assets and reputation. CMS data must be protected from unauthorized access. To minimize the impact of any breach, the egress of data from CMS must also be protected. Too many security implementations concentrate on protecting from unauthorized access but do very little in protecting the egress of data if a breach was to occur. The implementor must address the complete security picture, prohibiting unauthorized access to the data, as well as minimizing the ability to obtain (download) data when a breach has occurred. Security implementations are always a trade-off between risk and cost. The implementor should work with their ISSO (Information System Security Officer) to validate appropriateness of security controls for any implementation. 

A key guidance to protect CMS data is to ensure that the overall architectural design is consistently putting CMS’ valuable data at least three independent legitimacy tests away from the open Internet. A legitimacy test is defined as the challenge, filtering or transformation of the data to obfuscate the technical details regarding the sensitive data. For more information regarding challenges, see the information on Mediation Principles. Within the CMS network, services may interface with any other available service, given that the proper authorization is in place. 

The following topics will define the CMS services framework from a services perspective to detail the zoned architecture and the security obligations required to protect CMS assets. The TRA Multi-Zone architecture will be depicted as a services framework defined by requirements and risks rather than network routers, and will consider the role of each service, its interfaces, its parent services, and its dependent services in supporting TRA compliance.  

Services Framework Architecture 

CMS Services Framework 

The architecture will be described by the set of services within the architecture, detailing the functions these services provide and the objectives for protecting these services. The following section of the TRA will discuss how these services can be applied. 

The services framework is centered around core data, application, and edge services, integrated with management and security services. See the Elements of the Services Framework diagram below. Management and security services both enable administrative access to the system. Security services assist in cybersecurity threat detection and protection, as well as the compliance with CMS security policies. The management and security services are housed in different subnets, accessible only through a virtual private network (VPN). 

Elements of the Services Framework  (page 7)

Core Services 

Core services include data, application, and edge services. These services are detailed below. 

Data Services 

Data services are fundamental and the most basic component protecting the data. They are the components of the architecture that reside in front of and provide access to the data. 

Services Framework Data Services (page 4) 

The data services must: 

• Restrict access to the data 
• Validate the caller (service consumer) has the appropriate access rights to the data services (producer) 
• Obfuscate implementation details from the consumer, not exposing data formats, credentials, etc. to the consumer. 
• CMS expects non-data services to front CMS data services. Data services are not directly accessible from outside a CMS data center. 

Application Services 

Application services are the components of the architecture that are generally responsible for housing the business logic. They are the consumer of data services and the producer of edge services. 

Services Framework Application Services (page 3) 

The application services must: 

• Validate the caller (service consumer) has the appropriate access rights to the application services (producer) 
• Provide access to data services 
• Act as the mid layer between data and edge services, obfuscating the access details of the data from services which are accessing that data 

Edge Services 

Edge services interface with external components from non-CMS systems. 

Services Framework Edge Services (page 5)

The edge services: 

• Must restrict access to the application services 
• May, depending on architecture, provide authentication services. 

Mediation Principles 

Mediation principles are implemented as part of the data, application, and edge services to enhance the security by obfuscating the access details to the data. As the request proceeds through the services framework, the request must pass legitimacy tests and be filtered or transformed to provide the necessary obfuscation of critical system components and data. An inbound data request, in most use cases, passes through edge, application and data services. Therefore, at each level, validations and transformations are performed to protect the underlying service. Some systems need to support outbound connections, and these must also follow the path out through the edge services. As outbound calls provide a ‘bad actor’ with a pathway for extracting data from a CMS data center, this pathway is restricted out to only those specific components which are required to be traversed. The outbound calls to a specific destination are also limited. 

When implementing the data, application and edge services, the system designer should consider the following mediation principles: 

Challenges -– Using rules to allow authorized access or the routing of messages and network packets. 

Filtering -– Using criteria and rules to select data, permit a request, or check the validity of data, messages, or network packets. 

Transforming -– Changing a structured request, query, result, or response, into a different structure or syntax. Changing only the headers and routing envelopes of messages or network packets does NOT qualify as transforming. 

Management Services 

Management services assist the system administrators in maintaining the system. The tools required are placed in a management zone, accessible only through the VPN, which provides two factor authentication. 

The tools included within the management zone vary by application, but typically include the tools necessary for software releases and patching. 

Security Services 

The security zone houses any security tools for the application. CMS has enterprise logging and monitoring tools that are available to the system maintainers, so not all applications require a separate security zone. 

CMS Services Framework - Summary 

In summary, the CMS Services Framework enables applications to be orchestrated and/or composed of a service-fabric that integrates a set of services which enable access to and provide protection of CMS data. The architecture should implement a service as the authorized channel to access the application data. Users from external networks, CMSNet, or the CMS LAN must be authenticated to access the service fronting the data. Additionally, the file storage service must be configured to deny access to all unauthenticated users and all unauthorized users. Furthermore, users from external networks, CMSNet, or the CMS LAN must not have direct access to the CMS files persisted by the storage services.  

Services Framework Architecture 

CMS Multi-Zone Architecture 

Introduction 

The CMS TRA specifies a zone architecture that provides defense against security attacks and implements layers of challenges to ensure only authorized access to CMS resources. The services framework details the functions provided by each of the service types, and these services are represented by zones in the CMS multi-zone architecture. In general, the service names match the zone terminology (e.g., Data Services and Data Zone) except for Edge services which corresponds to the Presentation Zone. As the use of cloud platforms and cloud services (such as content delivery networks) have become more prevalent within CMS, the term “Edge Services” has been adopted to represent the services that front and protect CMS internet-facing resources. 

The multi-zone architecture is focused on protecting CMS assets via security challenges and enforcing defense-in-depth principles. Zones are a way of grouping and sharing resources based upon a shared security posture. Distinct zones generally exist in legacy data centers but are not as prevalent in cloud implementations where virtual resources, such as network, compute, and storage are usually project based implementations and there is tight integration with other cloud service provider (CSP) provided services. CMS does not require distinct zones for protecting assets, but it does require that data is protected by at least three security challenges. This is a minimum requirement, as additional security measures may be helpful in reducing the risk of a security breach. In addition, the security measures should not be housed on the same resource. This is done to ensure that if one resource is compromised, other security measures are in place to thwart an attack. 

The following subtopic will diagram and discuss the multi-zone architecture, detailing the relationship between the zones and the services framework. Note that the depiction is reminiscent of the CMS three-zone architecture as the three-zone model is one instance of the CMS multi-zone architecture. This is a result of the physical nature of the three-zone architecture and its implementation with CMS data centers. The services framework and multi-zone architecture is applicable to cloud environments, where the delineation of the zones is not as obvious. Cloud implementations that utilize a combination of CSP services and CMS services obscure specific zones implemented by the system developer. The specific zone is not as significant to the design as the need to implement challenges to protect CMS assets. 

After the discussion of the multi-zone architecture, examples of typical use cases are provided that demonstrate how the function could be implemented in the three-zone architecture as well as the cloud. These examples will support the reader's understanding of the architecture and security requirements. Please note, since system requirements and design vary greatly, these examples are to demonstrate the principle of protecting system assets, but the specific example may not apply to every system design. It must be stressed that the system developers should work with their ISSO in developing and implementing protections to CMS assets. 

Zone Architecture 

CMS defines a zone as “a portion of the network isolated by firewalls that serves a specific business function”. These firewalls may be physical or virtual, or implemented by other means (e.g. Security Groups in AWS, Network Security Groups in Microsoft Azure, etc). 

CMS data centers have typically utilized a three-zone architecture design. While CMS does not dictate the actual number of zones, in CMS data centers the common practice was the implementation of three zones based around data, application and edge services. As a result of the hierarchical nature of the implementation, using specific zones allowed for ‘like’ services to communicate (e.g., application to application service) in and between data centers as long as the CMS network was utilized. In addition, this implementation method also allowed for services to communicate with other services one layer below their own (e.g., edge services to application). Therefore, data services are not directly accessible from outside a CMS data center. Services on the same level are assumed to have passed through the same levels of security and may be accessed directly, although common practice is to restrict consumers of a service to just those components that require the use of the service. Systems implemented in the cloud do not generally have this distinct segmentation and assumptions about the security posture do not exist. 

In today’s more dynamic, elastic, and transient cloud environments, the multi-zone architecture is still relevant, but the security challenges may be implemented within Cloud Service Provider (CSP) services or within resources implemented by the CMS development organization. Clouds, microservices, software defined networks, and other emerging technologies present new paradigms for application architecture and often favor new design patterns for performance, security, and cost avoidance. Also, applications may resemble a fabric of services running on a dynamically changing cloud of virtual resources connected through networks often more defined by permissions than wires. These newer cloud environments and implementations rely upon CSP’s services which leads to a collaboration between the CSP and system implementor for implementing security. 

CMS Processing Environments are composed of one or more of the following zones to provide Defense-in-Depth, as depicted in the CMS TRA Multi-Zone Architecture figure below: 

• Presentation Zones (PZ) – Edge services that support the presentation of content. Presentation Zones are accessible to external networks via firewalls through a Trusted Internet Connection (TIC). 
• Application Zones (AZ) – Application services which support business logic for applications and creating dynamic user presentations. 
• Data Zones (DZ) – Data services that contain data and data services used by applications. 
• Management Zone – To support specialized services, such as Public Key Infrastructure (PKI), Domain Name System (DNS) services, and system management services. 
• Security Zone – A shared mediation service to support security services. 

As the CMS TRA Multi-Zone Architecture diagram shows, the Presentation Zone controls the ingress and egress of all external communications into the CMS Processing Environment. The Application and Data Zones may communicate with corresponding Application Zones and Data Zones in other CMS data centers only. CMS has the capability of communicating from a zone in a CMS data center to a CMS cloud environment. Application and Data Zones would be allowed to communicate to equivalent zones in the cloud. These equivalent zones would be part of a CMS private subnet within the CMS enclave at the service provider. 

In the CMS vernacular, a Management or Security Zone is a network segment whose primary function is in support of security or infrastructure, and typically provides services to all the other zones. These Zones generally follow the same rules as other zones though there are a few additional rules. A data center may choose to group infrastructure functions into more zones than those listed here. Note: CMS TRA Multi-Zone Architecture represents the conceptual connections between zones and does not depict network implementation such as Trusted Internet Connections (TIC) integration and Virtual Routing and Forwarding (VRF), which are covered in more detail in TRA Network Services. 

CMS TRA Multi-Zone Architecture (page 10)

Transactions within a zone are permitted without restriction unless the traffic is firewalled between data centers. Transactions traversing the zones are controlled and protected via firewalls and other security mechanisms. This multi-zone architecture allows CMS to monitor and control business application transactions within and between zones. The Transport and Management Zones provide infrastructure and supervisory services to manage the core zones. 

Presentation Zone 

The Presentation Zone contains the front-end components of applications. The Presentation Zone receives requests from external sources, performs data validation, and proxies the requests to the Application Zone for processing. No business logic or database processing is performed on Presentation Zone servers. The Presentation Zone function is to proxy communication requests to the Application Zone (i.e., application-related connections must originate in the Presentation Zone). It is also the zone where business applications first receive data from external sources and is therefore the first zone to challenge requests for validation, authorization, and malicious content. 

For outbound communications, the Presentation Zone is the last zone traversed before reaching the Internet. 

Application Zone 

The Application Zone contains the business logic components of an application. It receives requests from the Presentation Zone and requests necessary data from Data Zone components. The Application Zone can host proxy services to the Data Zone. 

Data Zone 

The Data Zone contains all data sources, including data stores supporting directory services, authentication functions, data lakes and meshes as well as the applications’ operational databases. All interactions between the Application Zone and the Data Zone must use mediation and data access services. CMS permits the use of database-stored procedures that may reside on database servers in the Data Zone. 

Management Zone 

The Management Zone provides services to all zones and includes such functions as: 

• DNS servers 
• Backup servers 
• Logs 
• Remote Access Services 
• System monitoring applications 
• Asset/vulnerability management 
• Application deployment functions 
• System configuration management function 

The specific services provided by the Management Zone will vary from data center to data center. Projects are encouraged to discuss specifics with their data center provider. The Management Zone is the appropriate zone for hosting development and operations automation, such as DevOps deployment components. 

Security Zone 

The Security Zone provides services to all zones and includes such security functions as: 

• Security monitoring and response 
• Network and Host Intrusion Detection Systems (NIDS/HIDS) 
• Intrusion Protection Service (IPS) 
• Asset/vulnerability management 
• Recording and monitoring of system, security, and audit logs 
• Antivirus monitoring and analysis of server based anti-malware agent 
• Enterprise-level security monitoring by integrating with the CMS Cybersecurity Integration Center (CCIC) 

Applying Zoned Architecture 

As described above, CMS implements defense-in-depth principles in a multi-zoned architecture. In the subtopic above, we talked about defense-in-depth and how each zone within the architecture contributes to protecting CMS resources. 

In the cloud, the definitive lines between zones are not as clearly defined, and utilizing services from the cloud providers further obscures the responsibility for implementing defense-in-depth. Firewalls may not be implemented, but the team may use security groups (in AWS environments) or their equivalent within their respective cloud for controlling access and flow through the system. CMS requires at least three challenges before allowing access to sensitive data. In the cloud environment, these challenges may not be as clearly separated into zones as CMS data centers would support. The reader should take ‘three’ challenges as a minimum to implement security needs. As such, the implementor should strive to deliver the most secure implementation, limiting risk, that resources can support. 

We will detail some common implementations within the cloud environment below and discuss how defense-in-depth can be implemented. Remember these examples are to demonstrate possible implementations and the implementor should work with their ISSO to validate the security adequacy of the design. Note that the current practice is for CMS cloud engineers to provide the implementor with a private and public subnet. The implementor creates the zones or the defense-in- depth using this model. For example, the application zone and data zone could be implemented within the private subnet, controlling flow and access using security groups. 

Example 1 – API Implementation

In this example, the implementor desires to implement an API to access CMS sensitive data for users external to CMS. The API endpoint should be protected by a Web Application Firewall (WAF) which may implement one or more of the security challenges and mediation principles (e.g. Geo fencing). A typical implementation would include: 

1. Multi-factor authentication prior to accessing the APIs that front sensitive data 
2. Authorization that the user has adequate permissions/roles to access the API. This could be accomplished using a directory. 
3. The API endpoint should obfuscate (see Mediation Principles) the data access details to avoid providing the end user with any type of information regarding the type of database, location, etc. 

The diagrams below depict the zonal mapping of the API example to a CMS data center implementation and a cloud model where the implementation is supported with cloud services. Amazon Web Services (AWS) is used in the example, but the example holds for any CMS approved cloud. Please note that in the cloud example, we do not explicitly name the presentation and application zones. In this example, the implementation utilizes services provided by the cloud service provider (CSP). While not explicitly named, the reader can infer the web application firewall is analogous to the presentation zone and the API gateway to the application zone. 

Example 1 - API Implementation (page 1)

Additional security challenges/features, such as data masking, may be applied to further protect CMS sensitive data. The implementation should also prohibit the egress of data using the API or the resources that house the API. 

Example 2 – Business Intelligence Tool Implementation 

In this example, the implementor intends to utilize a cloud service that will use a virtual desktop/BI tool to access CMS data. In this example, due to the nature of the data, multi-factor authentication must be used. 

1. A typical implementation would utilize multi-factor authentication, either through a CSP or CMS service to validate the user. 
2. Once authenticated, the user’s authorization must be validated to ensure that access to the data is appropriate. This could be achieved through a sign-in or verification check within the database or CMS directory for roles/permissions. 
3. The virtual desktop/BI tool should also be restricted to access only the targeted CMS data source, such as for example the CMS Enterprise Data Mesh (EDM). This could be accomplished by using security groups, or locking down the IP/ports that the cloud-based virtual desktop/BI tool is permitted to access within the CMS enclave. 

The diagrams below depict the zonal mapping of the Business Intelligence Tool example to a CMS data center implementation and in the cloud where the implementation is supported with cloud services. AWS is used in the example, but the example holds for any CMS approved cloud. 

Example 2 - Business Intelligence Tool Implementation (page 2)

Additional security challenges/features may be implemented depending on the risk posture of the system. For example, data masking can provide additional security as well as configuring the desktop/tool to limit the ability of the user to download or obtain the data. 

Sharing Components and Capabilities 

The following definitions are critical to understanding the components of the CMS Processing Environments. These definitions apply to all virtual and physical components of information processing systems: 

• Dedicated components – are those physical resources provided exclusively for CMS Environments. 
• Shared component – means the physical or virtual component is shared among multiple tenants in a data center, in a virtualization hosting system, or in a community or public cloud environment. Details of CMS cloud shared services are available at CMS Cloud Services. 
• Independently managed component – means the physical or virtual component is independently usable and managed by CMS, in isolation from other tenants. 
• Third-Party Websites and Applications – are web-based technologies (covered within the CMS ARS) that are not exclusively operated or controlled by HHS. The CMS TRA covers TPWAs linked to or accessed by CMS applications. 
• Single-purpose component – means the physical or virtual component is a standalone custom or commercial device or appliance product (including hardware, firmware, software, and/or operating system) designed for a specific purpose, and not to perform general purpose processing. An example would be a firewall appliance that consists of firewall software running on a virtual machine (VM) with a highly customized operating system that is designed to run only the firewall application. 

Network Connectivity and Trust Boundaries 

CMS data centers and the CMSNet connections between them are within the CMS security perimeter and currently operate with an elevated level of trust. The movement towards newer security models such as zero trust will continue to reduce the inherent trust at the network connectivity level, and best practice is to authenticate all network connections. Although individual data centers may connect to the untrusted Internet, connections between CMS data centers should preferably traverse CMSNet. Connections to external entities must be covered by an Interconnection Security Agreement (ISA) approved by the CMS Authorizing Official. 

CMS Data and CMS Sensitive Information 

The CMS TRA uses the term “Sensitive Information” as defined in the NIST Glossary and the Guide to Cyber Threat Information Sharing, SP 800-150 and referenced in Executive Order 13556 -- Controlled Unclassified Information, with guidance in the NARA CUI Registry. It is the responsibility of the business owner, in consultation with their Group Director (GD), Information Systems Officer (ISO), Information Systems Security Officer (ISSO), Cyber Risk Advisor (CRA), Chief Information Security Officer (CISO), Administrative Officer (AO), Data Guardian, and Privacy subject matter expert to determine what data are sensitive. This includes all data that require protection due to the risk and magnitude of loss or harm, such as PII, PHI, and Federal Tax Information (FTI). 

There are some system data elements in ATO(ed) environments that should always be considered sensitive: 

• Passwords and private keys, including application programming interface (API) keys and other keys used to access or configure sensitive CMS data, services, or IT resources 
• Final release of code, executables, and configuration files that will be or are deployed in ATO(ed) environments 
• Configuration “Reference Data” such as configuration files or metadata used for configuring virtual resources and services in ATO(ed) environments 
• Internal network addresses, and unique addressable device identifiers—such as Media access control (MAC) addresses, Virtual Machine identities (ID), etc. in ATO(ed) environments 

The Privacy Impact Assessment (PIA) is a critical tool for spotting privacy risks and compliance with federal regulations or laws, tracking implementation of privacy controls, identifying instances where CMS collects or handles Personally Identifiable Information (PII) and/or Protected Health Information (PHI) and for identifying CMS systems subject to the Privacy Act of 1974.  PIAs must be conducted as part of the ATO process for CMS IT systems, and must be reviewed at least every three years and/or upon a major change to the IT system or electronic information collection. For additional information, reference the CMS Privacy Impact Assessment (PIA) Standard Operating Procedures and ARS SC-7(24) - Personally Identifiable Information. 

Designating High Value Assets 

A High Value Asset (HVA) is an asset used as a mission-critical information resource supporting infrastructure providers and suppliers or partnering organizations. The unauthorized disclosure, modification, destruction, or disruption of access to this information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. 

The business owner of a CMS information system must categorize the system in accordance with Federal Information Processing Standards (FIPS) 199, and document the system attributes used to identify PII, PHI, and HVAs. The CIO determines whether a system is an HVA. If the CMS CIO identifies a system as a High Value Asset, an HVA Designation Letter must be on file. Please refer to TRA Network Services, Cyber Security Operations / Risk Management for more information.  

Zero Trust Maturity Introduction 

Introduction 

The Federal Government has directed agencies to modernize their approach to cybersecurity. Executive Order 14028, “Improving the Nation’s Cybersecurity”, and OMB Memorandum M-22-09, “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” direct Federal Civilian Executive Branch (FCEB) agencies to base their enterprise security architecture on Zero Trust principles. While HHS and CMS have not published new policies regarding Zero Trust, the CMS Zero Trust Workgroup is working to evolve the Zero Trust Maturity of all CMS environments through incremental change, with “Advanced” or “Optimal” maturity being the objective for systems, based on their sensitivity (the results of a recent data call for Zero Trust Maturity for AWS for CMS Cloud suggests an overall maturity level of "Advanced" for CMS Cloud). 

CMS is in the midst of defining its Zero Trust strategy, policies, and approach. As such, this TRA section does not introduce any new business rules. However, to assist CMS in preparing for and aligning with Zero Trust objectives, the following topics illustrate how existing TRA business rules and recommended practices align with Zero Trust Maturity capabilities. This information can aid development teams in understanding which areas may need additional focus along the Zero Trust Journey. This is not per se a Zero Trust primer. See below for additional resources. 

Overview 

The Federal Zero Trust Architecture (ZTA) strategy involves migration from existing perimeter-based defenses to a “Zero Trust” approach. Zero Trust is not a single architecture, but a set of guiding principles that can improve the security posture of agency applications and environments. These seven tenets outlined in NIST SP 800-207 guide its implementation: 

1. All data sources and computing services are considered resources. Including: 

• Multiple classes of devices 
• Small footprint devices 
• Personally owned devices (BYOD) 

2. All communication is secured regardless of network location. 

• Both enterprise-owned network infrastructure and any other non-enterprise-owned network 
• In the most secure manner available 
• Access requests from inside must meet same requirements as from outside the enterprise 

3. Access to individual enterprise resources is granted on a per-session basis. 

• Trust in the requester is evaluated before the access is granted 
• Access is granted with the least privileges needed to complete the task 
• Authentication and authorization to one resource will not automatically grant access to a different resource 

4. Access to resources is determined by dynamic policy, including: 

• The observable state of client identity, application/service, and the requesting asset 
• May include other behavioral and environmental attributes, such as security posture 
• Rules and attributes are based on the needs of the business and acceptable level of risk 
• Least privilege principles restrict both visibility and accessibility 

5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. 

• No asset is inherently trusted. 
• Evaluates the security posture of the asset when evaluating a resource request. 
• Continuous diagnostics and mitigation (CDM) systems monitor the state of devices and others. 

6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. 
7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture. 

CMS-specific guidance for ISSOs and ADOs can be found at The 7 Tenets of Zero Trust for ISSOs and ADOs. Zero Trust Maturity is the degree to which ZTA principles have been implemented across the agency. CMS assesses this using the CISA Zero Trust Maturity Model, which is organized around a structure that is shown with five pillars: 

Figure 1: Zero Trust Maturity Model Pillars (page 9) 

• Identity: Federal staff, as well as partners and end users, use enterprise-managed accounts to access everything they need to do their job, protected from phishing and other attacks. 
• Devices: The devices that Federal staff use are consistently tracked and monitored, with those devices’ security postures used to grant access. 
• Networks: Agency systems are isolated, with encrypted network traffic flowing between and within them. 
• Applications and Workloads: Enterprise applications can be made available to staff securely over the internet. 
• Data: Federal security teams and data teams develop data categories and security rules to automatically detect and ultimately block unauthorized access. 

Below the pillars are three steps: 

• Visibility and Analytics: Collecting information about the systems to identity how things in the Pillar are working. 
• Automation and Orchestration: Methods for automatically creating and maintaining the different entities and assets in a Pillar. Manual configurations can introduce errors over time, and automation helps prevent that. 
• Governance: The set of policies that tell how you control and direct different assets and entities in your environment. This can include how teams create new users, decide on data classifications, and manage servers. 

High-level Summary 

Below are the characteristics of the maturity levels assessed for CMS environments. 

Resources and References 

Find more information about Zero Trust within CMS OIT and the Federal Government at large. Some are out of the scope of the CMS migration. 

Internal 

• CMS Cloud Zero Trust documentation 
• CyberGeek Zero Trust 

External 

OMB 

• Executive Order 14028, “Improving the Nation’s Cybersecurity”, 
• OMB Memorandum M-22-09, “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” 
• Cyber.gov, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles 

NIST 

• Special Publication 800-207, Zero Trust Architecture 
• Special Publication 1800-35(A-E), Implementing a Zero Trust Architecture, (2nd Preliminary Draft) 

CISA 

• Zero Trust Maturity Model (Version 2.0) 
• Cloud Security Technical Reference Architecture 

Zero Trust Maturity Model Pillars 

The sections that follow show ways in which the CMS TRA aligns with capabilities required for Zero Trust Maturity. The CMS objective is to implement these capabilities at the Advanced or Optimal maturity level.  

Zero Trust Maturity Identity Pillar 

Introduction 

This section covers the capabilities needed for the Zero Trust Maturity Identity Pillar. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities. 

CMS Guidance 

The identity pillar considers how accounts are created and how users log into systems. The ability to identify every user and entity requesting system access is foundational to the concept of zero trust. 

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Identity Pillar. This includes: 

• How to store identities of users as well as authenticate them 
• Consideration of identity for the developers and admins creating the system and the end users of the system like providers or the public 
• Consideration of non-person entities such as devices, service accounts, and APIs 

Capabilities 

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH. 

• BR-ACID-2: Known Identity Required to Access CMS Information Systems 
• BR-ACID-13: OIT Is Responsible for Identity Management of Users with Credentials Provisioned in the CMS Enterprise Directory 
• BR-SA-2: Integrate with the CMS Identity Management Services 
• BR-UI-12: Authentication 
• BR-WS-11: Use Certificate-Based Mutual Authentication for Machine-to-Machine Web Services 

• BR-BI-3: Authentication, Auditing, and Logging of All BI User Accounts Must Be Managed from the CMS Enterprise LDAP Directory and Enterprise User Administration 
• BR-ACID-3: Single Identity Record for Each Individual Accessing CMS Systems 
• BR-ACID-4: User Identities Must Be Vetted and Managed Using a Common Framework 
• BR-ACID-10: EUA Manages UserIDs of CMS Employees and Contractors 
• BR-SA-2: Integrate with the CMS Identity Management Services 
• RP-SAAS-4: Integrate SaaS with CMS Identity Management Systems 

• BR-SEC-Gen-22: All Information Systems Must Have a System Risk Assessment in CFACTS 
• BR-CCIC-02: Assessment of Information Security and Privacy Risks 

• BR-ACID-1: Valid Purpose Required to Access CMS Information Systems 
• BR-ACID-11: CMS Business Owners Provide Privilege Administration 
• BR-ACID-13: OIT Is Responsible for Identity Management of Users with Credentials Provisioned in the CMS Enterprise Directory 

Zero Trust Maturity Devices Pillar 

Introduction 

This section covers the capabilities needed for the Zero Trust Maturity Devices Pillar. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities. 

CMS Guidance 

The devices pillar highlights the importance of consistently tracking and monitoring devices to understand their security posture prior to granting access to systems. For applications, this will include physical servers as well as digital assets such as virtual machines and containers. 

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Device Pillar. This includes: 

• How to maintain a complete inventory of every device a system operates through the CDM program 
• Managing supply chain risks for both devices and the software it runs 
• Preventing and detecting incidents on those devices 

Capabilities 

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH. 

• BR-SEC-Gen-2: Software and Hardware Components Must Adhere to a Secure Baseline Configuration 
• BR-SEC-Gen-3: Disable All Unnecessary Features and Capabilities 
• BR-SEC-Gen-11: Periodic and Continuous Configuration Compliance Scanning Is Required 
• BR-CCIC-14: Hardware Asset Management Capability 
• BR-CCIC-16: Configuration Settings Management Capability 
• BR-SV-12: Perform Asset Management of Virtual Instances 
• RP-SV-14: Use VM Configuration Templates 
• BR-IoT-1: CMS IoT Platforms Must Comply with CMS Requirements for CMS Processing Environments 

• BR-CI-4: Obtain TRB Approval for CMS-Owned Equipment 
• BR-CI-5: Acquisition of New IaaS or PaaS Cloud Service Providers 
• BR-F-6: Mainframes Must Be Dedicated to CMS 
• BR-IoT-1: CMS IoT Platforms Must Comply with CMS Requirements for CMS Processing Environments 
• RP-IoT-1: CMS-Managed IoT Devices Should Comply with NIST SP 1800-15 and the Latest MUD Specifications 
• BR-SEC-FW-11: Utilize Firewalls from Two or More Different Vendors 

• BR-F-3: The CMS TRA Defines a Zoned Architecture 
• BR-F-4: Within a CMS Processing Environment, Communication Must Flow Only between Adjacent Zones or within a Single Zone 
• BR-EFT-11: CMS Data Files May Only Be Transferred to the Data Zone 
• RP-DSS-5: A Storage Service Data Store Should Not Be Accessible from More Than One Zone 
• BR-F-12: Role-Based Security AAA Must Be Used for Management and User Roles 
• BR-SV-1: Apply Separation of Duties to Virtualization Administration 
• BR-SV-2: Provide Hypervisor Root Access Only to Specific Administrative Accounts 
• BR-SV-3: Different Administration Account on Blade Controllers and Hypervisors 
• BR-SV-16: Originate Administrator Access to Blade Controllers and Hypervisors from the Management Zone 
• BR-SA-4: Use TRB-Validated Mediation and Data Access Services to Access Data in the Data Zone 
• BR-WS-4: Use TRB-Approved Data Zone Mediation and Data Access Services to Access Data in the Data Zone 
• BR-WS-9: Inter-Zone Web Services Must Transverse a Mediated Service 
• BR-WS-12: Messages Must Pass through All Intermediate Zones 

• BR-PMM-3: Monitor Production Environments 
• BR-SEC-Gen-11: Periodic and Continuous Configuration Compliance Scanning Is Required 
• BR-SEC-Gen-12: Host Intrusion Detection Capabilities on All IT Components 
• BR-SEC-Gen-21: Malware and Malicious Code Scanning Results Must Be Sent to the Security Zone 
• BR-CCIC-09: Local Information Sharing and Cyber Threat Intelligence Support 
• BR-CCIC-25: Insider Threat Detection 

Zero Trust Maturity Networks Pillar 

Introduction 

This section covers the capabilities needed for the Zero Trust Maturity Networks Pillar. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities. 

CMS Guidance 

A network refers to an open communications medium including typical channels such as agency internal networks, wireless networks, and the Internet as well as other potential channels such as cellular and application-level channels used to transport messages. 

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Network Pillar. This includes: 

• Encrypting traffic that leaves the CMS boundary, as well as encrypting internal traffic 
• Focusing on network resilience from both normal use and adversaries 
• The need to begin executing a plan to break down the perimeters into isolated environments 

Capabilities 

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH. 

• BR-F-3: The CMS TRA Defines a Zoned Architecture 
• BR-F-4: Within a CMS Processing Environment, Communication Must Flow Only between Adjacent Zones or within a Single Zone 
• BR-SEC-FW-1: Separate Network Interfaces for Each Network Segment and Zone 
• BR-WAN-S-3: Communication between CMS Data Centers Is Only Permitted between Like Zones 
• BR-WAN-S-12: Management of CMSNet Is Via a Dedicated Logical Network 

• BR-CCIC-07: Local Security Information and Event Management Capability 
• BR-CCIC-12: CyberScope Data Feeds 
• BR-CCIC-18: Perimeter Monitoring Prerequisites 
• BR-PMM-3: Monitor Production Environments 
• BR-SAAS-7: Integrate with CMS CCIC 
• RP-SAAS-3: Continuous Monitoring 
• BR-SA-9: Systems Must Define Metrics for IT Health Monitoring 

• BR-SA-6: Network Communications Must Meet the TRA Rules for Encryption 
• BR-SEC-Int-3: HTTPS on CMS Public-Facing Websites and Services on the Internet 
• BR-CCIC-24: FIPS 140-2 or FIPS 140-3 Validated Encryption Use 
• BR-WAN-S-0: Use Mutual Authentication and Encrypted Tunnels between Data Centers 
• BR-WAN-S-1: The WAN Must Implement FIPS 140-2 or FIPS 140-3 Compliant Encryption 

• BR-CCIC-12: CyberScope Data Feeds 
• BR-DR-1: Annual Review of Disaster Recovery Plans 
• BR-DR-2: Disaster Recovery Tier Selection 
• BR-DR-3: All CMS FISMA systems must have a plan for DR 
• BR-DR-4: Required Risk Analysis, System BIA, and ISCP 

Zero Trust Maturity Applications & Workloads 

Introduction 

This section covers the capabilities needed for the Zero Trust Maturity Applications and Workloads Pillar. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities. 

CMS Guidance 

Applications and workloads include systems, computer programs, and services that execute in on-premises and cloud environments. In mature zero trust deployments, users strongly authenticate into applications, not into the underlying networks. 

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Zero Trust Maturity for AWS for CMS Cloud. This includes: 

• Application-specific threat protections 
• Application security testing at all stages of development and deployment 
• Enabling access to applications based on additional user attributes beyond mere presence on specific networks 

Capabilities 

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH. 

• BR-P-5: Each Portlet Must Control Access to Content / Functionality Based on User and Role Information via the Portal 
• BR-BI-5: Role-Based Authorization Must Be Used to Manage Access to BI Applications, Queries, Reports, Analytic Functions, Tables, Views, and Stored Procedures 
• BR-ACID-1: Valid Purpose Required to Access CMS Information Systems 
• BR-WAN-S-2: CMS Business Partners Only Access the Presentation Zone 
• BR-WAN-S-4: Business Partner Access Restrictions 
• BR-F-12: Role-Based Security AAA Must Be Used for Management and User Roles 
• BR-URL-3: Logs Must Identify the Users Who Access a CMS File Referenced by a URL from the External Networks or CMSNet 
• BR-URL-4: Logs Must Identify the Users Who Upload a File to a CMS Location Referenced by a URL from the External Networks or CMSNet 

• BR-SEC-Gen-21: Malware and Malicious Code Scanning Results Must Be Sent to the Security Zone 
• BR-SEC-Gen-15: Logs Must Be Securely Collected, Aggregated, and Analyzed 
• BR-SCM-2: All Code Must Be Baselined Prior to Release into Implementation, Validation, and ATO(ed) Production Environments 
• BR-SBI-1: All Builds Must Occur in Controlled Environments 
• BR-SBI-2: All Production-Deployed Custom Code Must Be Built and Installed from Version-Controlled Source Code 
• BR-OSS-5: Use OSS Built from a Controlled Source 
• BR-OSS-6: Binary Package Management Is Mandatory 
• BR-OSS-10: CMS OSS Code Released as CMS-Managed Code Requires a Governance and Support Model 
• RP-CA-10: Validate All Third-Party Containerized Applications before Implementation 
• BR-OR-5: Libraries of Containers Must Be Maintained in CMS-Only Stores 
• BR-SEC-Gen-17: Software Assurance Measures 
• BR-SEC-Gen-18: Malicious Code Protection in CMS Processing Environments 
• BR-SAAS-1: SaaS Clouds Are Defined by NIST SP-800-145 

• BR-SQ-4: All CMS User Interfaces Must Meet Section 508 Accessibility Requirements 
• BR-UX-1: Ensure Usability and Accessibility 
• BR-UI-7: No Frames 
• BR-UI-8: Keyboard and Mouse 
• BR-UI-19: Color Contrast Ratio 

• BR-SBI-1: All Builds Must Occur in Controlled Environments 
• BR-SBI-2: All Production-Deployed Custom Code Must Be Built and Installed from Version-Controlled Source Code 
• BR-SBI-3: Production Builds Must Have Zero Compile Errors 
• RP-SBI-4: Use Explicit Library and Build Dependency Management 
• RP-SBI-5: Consider Instituting Continuous Integration 
• BR-PD-1: Software Must Be Packaged for Deployment 
• BR-PD-2: Software Target Packaging Must Be in Either the Operating System or Language Platform Native Form 
• BR-OR-3: The Deployment Infrastructure for Containers Must Be Hardened and Monitored 
• BR-OR-4: Containers Use Must Respect the Multi-Zone Architecture 
• BR-OR-5: Libraries of Containers Must Be Maintained in CMS-Only Stores 
• BR-OR-6: Required Orchestration Capabilities 

• BR-SS-4: Check for Common Security Vulnerabilities 
• BR-SS-5: Use Static Analysis Tools to Catch Common Security Weaknesses 
• RP-SS-6: Use Profiling to Perform Dynamic Code Analysis 
• BR-SS-7: Error Handling Must Not Reveal Information That Could Lead to an Exploit 
• BR-SEC-Gen-21: Malware and Malicious Code Scanning Results Must Be Sent to the Security Zone 

Zero Trust Maturity Data Pillar 

Introduction 

This section covers the capabilities needed for the Zero Trust Maturity Data Pillar. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities. 

CMS Guidance 

Data includes all structured and unstructured files and fragments that reside or have resided in federal systems, devices, networks, applications, databases, infrastructure, and backups (including on-premises and virtual environments) as well as the associated metadata. 

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Data Pillar. This includes: 

• How data should be protected on devices, in applications, and on networks 
• How data should be inventoried, categorized, and labeled, as well as protected at rest and in transit 
• The advantage of cloud security services for monitor access to sensitive data and the preferred practice of implementing enterprise-wide logging and information sharing 

Capabilities 

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH. 

• BR-DBM-1: Systems Must Meet Federal Record Management Requirements 
• BR-DBM-3: Systems Must Meet CMS Data and Database Management Standards 
• BR-DM-5: The EDL does not store raw data or unstructured data. All data in the EDL is fully structured and immediately consumable 
• BR-DM-4: Shared data assets are registered in the Hive Metastore and a user-facing data catalog 

• BR-DM-4: Shared data assets are registered in the Hive Metastore and a user-facing data catalog 
• BR-DM-5: The EDL does not store raw data or unstructured data. All data in the EDL is fully structured and immediately consumable 
• BR-DM-6: Data sets remain within the data owner’s security boundary 

• BR-F-8: Backup CMS Data 
• BR-F-9: Test CMS Backups on a Documented Schedule 
• BR-DR-1: Annual Review of Disaster Recovery Plans 
• BR-DR-2: Disaster Recovery Tier Selection 
• BR-DR-3: All CMS FISMA systems must have a plan for DR 
• BR-DR-4: Required Risk Analysis, System BIA, and ISCP 

• BR-DM-6: Data sets remain within the data owner’s security boundary 
• BR-DM-9: The data owner determines the users, groups, roles, and policies that govern data access 
• BR-AWS-5: Users Must Be Authenticated by AWS S3 Using a CMS-Managed IAM UserID When Accessing Data in CMS S3 Buckets 
• RP-AWS-1: Use Amazon AWS Security / Access Features for S3 

• [Text Wrapping Break]BR-EFT-6: File Encryption Is an Application Responsibility 
• BR-EFT-7: Secured Transmission Is Required 
• BR-EFT-10: Encrypt Files Residing in EFT Mailboxes 
• BR-AWS-1: Encrypt Amazon S3 Data at Rest 
• BR-SA-6: Network Communications Must Meet the TRA Rules for Encryption 
• BR-SS-2: Use NIST SP 800-132-Specified Salted Hashes to Store Passwords 
• BR-WS-7: Web Services Must Follow CMS Encryption Policy 
• BR-P-7: Each Portlet Must Securely Transport Sensitive Content 
• BR-BI-4: All Traffic Must Be Encrypted between a BI User’s Browser, Web Services, or Device and the BI Server 

Zero Trust Maturity Cross-Cutting Capabilities 

Introduction 

This section covers the cross-cutting capabilities needed for the Zero Trust Maturity Foundation. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities. 

CMS Guidance 

Each pillar also implements three cross-cutting capabilities. Visibility and Analytics refers to how we monitor systems. Automation and Orchestration is the process of creating reusable processes that can be automated within our systems. And Governance is the policies we set for the systems as well as how we track how we enforce those policies. 

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Zero Trust Maturity for AWS for CMS Cloud. This includes: 

• Using existing logging, monitoring, and alerting infrastructure where possible 
• Centralizing the implementation of the cross-cutting capabilities over all five of the other pillars 
• Documenting policies and procedures so they can be automated 

Capabilities 

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH. 

• BR-SA-8: Logging Must Be Configurable and Use Common Platform Standards 
• BR-SA-9: Systems Must Define Metrics for IT Health Monitoring 
• BR-SA-11: Servers Should Include Instrumentation for Application Performance Monitoring 
• RP-SD-8: Consider Non-Blocking Service Implementations to Improve Performance and Scalability 
• RP-SC-8: Consider Synthetic Transactions 
• RP-SS-6: Use Profiling to Perform Dynamic Code Analysis 
• RP-D-5: Deployment Should Integrate with Monitoring to Coordinate Outages 
• BR-UX-2: Collect Feedback 
• BR-P-3: Each Portlet Must Log Events via Portlet Container Logging Functions 
• BR-OR-2: Use Security Monitoring on Containers 
• RP-SV-11: Collect Virtualization Performance Metrics 
• BR-CI-7: Cloud Resource Capacity Planning 
• BR-PMM-3: Monitor Production Environments 
• RP-PMM-3: Provide Performance Data to CMS NOC 
• RP-PMM-4: Conduct Performance Management Planning 
• RP-PMM-5: Use a Trouble Ticketing System to Track Performance Problems 

• BR-OR-6: Required Orchestration Capabilities 
• RP-OR-7: Prefer Container Orchestration Tools That Allow for Container Motion 
• RP-D-7: Support Automated Startup, Shutdown, and Maintenance Mode Entry / Exit 

• BR-F-10: Annual Review and Exercise of Data Center Disaster Recovery Plans 
• BR-F-11: Annual Review and Exercise of Contingency Plans 
• BR-CI-4: Obtain TRB Approval for CMS-Owned Equipment 
• BR-CI-5: Acquisition of New IaaS or PaaS Cloud Service Providers 
• BR-SAAS-3: Ensure CMS Security May Perform Periodic Security Assessments 
• BR-SEC-Gen-22: All Information Systems Must Have a System Risk Assessment in CFACTS 
• BR-CCIC-01: Security Authorization of Systems 
• BR-CCIC-02: Assessment of Information Security and Privacy Risks 
• BR-WAN-CM-2: CMSNet Services Must Be Certified Annually 
• BR-ACID-11: CMS Business Owners Provide Privilege Administration 
• BR-ACID-13: OIT Is Responsible for Identity Management of Users with Credentials Provisioned in the CMS Enterprise Directory 
• BR-DNS-13: All DNS Changes Must Be Subject to CMS’s Change Management Procedures 
• BR-ADM-1: Use of the CMS Life Cycle Is Mandatory 
• BR-SA-7: Substantive Changes to the Architecture, Products, or Technology of an Existing Application Must Be Documented and Reviewed by the CMS TRB 
• BR-SQ-5: Manual Code and Design Reviews Are Mandatory 
• BR-CM-3: Significant Changes to Configuration Items of a System or Component Managed by a CCB Requires the Approval of That CCB 
• BR-CM-5: Projects Must Conduct Periodic Audits of CM Activities and Products 

CMS TRA Business Rules 

Guidance in the CMS TRA includes business rules, which are requirements for TRA compliance, and recommended practices, which are strongly encouraged but not required. The format for BRs and RPs is similar. The business rules consist of a brief, binding requirement and a rationale that provides context on the intent of the rule. Where applicable, the rationale also contains references to relevant policies, standards, and specific CMS ARS controls. The following BRs for this topic (i.e., rule numbers beginning with BR-F) provide high-level guidance applicable to all TRA stakeholders. Other topics contain additional business rules relevant to their respective sections. 

BR-F-1: Any Deviations from the CMS TRA Must Be Requested and Approved 

All projects and applications are required to adhere to the CMS TRA unless covered by a Technology Review Board (TRB)-approved exception. The CMS CEA and CIO has have joint approval authority for the CMS TRA. Only the TRB can approve deviations from the CMS TRA. 

Related CMS ARS Security Controls include: CM-2 - Baseline Configuration and CA-6 - Authorization. 

Rationale: 

ARS control CM-2 requires “Baseline configurations of information systems reflect the current enterprise architecture.” The CMS TRA is the CMS Enterprise Architecture standard. In some cases, applications identify circumstances where the benefits of deviating from the CMS TRA may outweigh the risks. The risk/benefit of any deviation from the CMS TRA must be assessed and approved by the TRB before the CIO can determine if the risk is acceptable and the system should be granted an ATO. 

BR-F-2: The CMS TRA Applies to All CMS Processing Environments 

The CMS TRA provides the standard technical reference for all CMS Processing Environments. This includes both physical and virtual server and end-user (e.g., Virtual Desktop Infrastructure) environments, cloud-based environments, and hybrid environments. These standards are effective on publication. A CMS Processing Environment is defined as any computing environment (e.g., CMS data center, virtual computing environment, or cloud computing) that creates, consumes, and/or stores CMS-related data. CMS data includes sensitive and non-sensitive information, security information, and event management-related information used to provide CMS services to the public and internal CMS users. For existing systems, compliance with CMS TRA updates is required within twenty-four (24) months of publication. When certain changes require immediate compliance, CMS will communicate these changes outside the TRA process via CIO directive. 

Related CMS ARS Security Controls include: CM-2 - Baseline Configuration and SA-8 - Security and Privacy Engineering Principles, Implementation Standard 1: 

The information system must follow system security and privacy engineering principles consistent with: 

1. The information security steps of the CMS Target Life Cycle (TLC) to incorporate information security and privacy control considerations; 
2. The information system architecture defined within the Technical Reference Architecture (TRA); and 
3. The Technical Review Board (TRB) processes defined by CMS. 

Rationale: 

Updates to the CMS TRA require corresponding changes to all CMS information systems. A 24-month compliance window provides sufficient time for data center operators and application maintainers to plan for and execute required CMS TRA changes to bring systems into compliance. 

BR-F-3: The CMS TRA Defines a Zoned Architecture 

At its most fundamental level, the CMS TRA defines a zoned architecture, a type of services framework architecture (see BR-F-22), where each service type provides different functions and has different responsibilities. There are three application zones and two infrastructure zones. The three business application zones are the Presentation/Edge, Application, and Data Zones. The two infrastructure zones are the Management Zone and the Security Zone. See additional information in the CMS Services Framework. 

In the multi-zone architecture, and specifically in the cloud environment, CMS does not specify the number of zones, but does require that access to CMS data resources be protected by at least three security challenges (e.g. multi-factor authentication, security certificates, etc. See Mediation Principles). This ensures that a user or other resource that requires access CMS sensitive data has been properly vetted prior to gaining access to the sensitive resources. This leads to a hierarchy, where zones have bi-directional adjacency. The Presentation/Edge Zone is adjacent to the Application Zone. (Please note, there are restrictions on the storage of data within the Presentation/Edge Zone. See BR-SA-3 for additional information.) The Application Zone is adjacent to both the Presentation/Edge Zone and the Data Zone. The Management and Security Zones are adjacent to all zones. The following rules govern the zoned architecture: 

1. No other adjacency relationships are permitted. 
2. Firewalls (virtual or physical) separate adjacent zones. 
3. The three business application zones (the Presentation, Application, and Data Zones) extend across all CMS Processing Environments. 
4. There are no other zones. 

Related CMS ARS Security Controls include: CM-2 - Baseline Configuration, PL-8 - Security and Privacy Architectures, RA-9 - Criticality Analysis, SA-8 - Security and Privacy Engineering Principles, SC-2 - Separation of System and User Functionality, and SC-32 - Information System Partitioning. 

Rationale: 

The CMS TRA follows a Defense-in-Depth strategy implemented in part by a multi-zone architecture. Access to the most valuable parts of the architecture (typically the data) requires crossing multiple zones, including multiple firewalls and servers (which may be physical, virtual, or configured via cloud-based services). The CMS Multi-Zone Architecture defines a consistent architecture used across the enterprise. In addition to Defense-in-Depth for each application, this architecture allows inter-application communication while maintaining a secure environment. 

Appendix I, section 4 of Office of Management and Budget (OMB) Circular No. A-130, Managing Information as a Strategic Resource, revised July 28,2016, directs, in pertinent part, under sub-paragraph i (4) that federal agencies shall: 

Isolate sensitive or critical information resources (e.g., information systems, system components, applications, databases, and information) into separate security domains with appropriate levels of protection based on the sensitivity or criticality of those resources; 

BR-F-4: Within a CMS Processing Environment, Communication Must Flow Only between Adjacent Zones or within a Single Zone 

Network communication must flow only between adjacent zones (as described in BR-F-3). Direct communication between non-adjacent zones is prohibited. 

Related CMS ARS Security Controls include: CM-2 - Baseline Configuration, SC-32 - Information System Partitioning, and SC-7 - Boundary Protections. 

Rationale: 

Communication limited to zone adjacency implements the CMS TRA Defense-in-Depth strategy. Network Services provides details. 

BR-F-5: Any System That Processes CMS Data Must Be Covered by a CMS ATO 

A CMS processing system is any environment dedicated to CMS FISMA applications or services (in whole or part) that process and/or store CMS data. A CMS processing system must be covered under a CMS Authorization to Operate (ATO). Additional guidance regarding CMS data is provided in CMS Data and Sensitive Information. 

All systems that process CMS enterprise data, whether called “production,” “test,” “pilot,” “proof-of-concept,” or “other,” must be covered under a CMS ATO in compliance with the Federal Information Security Modernization Act (FISMA)). This rule applies to any environment that stores or processes CMS data, to include disaster recovery (DR) sites and archival storage. Lower environments that contain only test data might not require an ATO. 

See the CMS ATO website for additional information regarding the CMS ATO process and the different types of compliance authorizations provided by CMS to manage agency-wide risk. For further information about test data and “synthetic data generation,” see NIST SP 800-188, “De-Identifying Government Datasets: Techniques and Governance.” 

Related CMS ARS Security Controls include: CA-6 - Authorization, CM-2 - Baseline Configuration, AC-21 - Information Sharing, SC-32 - Information System Partitioning, RA-2 - Security Categorization, andSA-3(2) - Use of Live Operational Data. 

Rationale: 

The “Types of authorizations” section of the CMS ATO website states: 

“Every system that is integrated at CMS — either built in-house or contracted — must get a compliance authorization to operate and access government data. This ensures that the agency is aware of all components interacting with its data, and that each system can be monitored for compliance and risk mitigation. This helps safeguard sensitive personal information, manage the risk to critical infrastructure, and address cybersecurity issues when they arise. 

“If you are introducing a new system at CMS, you must go through the security and compliance process.” 

The emphasis on CMS ATO is important to shared environments such as clouds, which may be covered under the Federal Risk and Authorization Management Program (FedRAMP) or another agency’s ATOs. While other agencies may have different ATO requirements, the compliance with such an ATO or FedRAMP does not ensure that all CMS-prescribed controls have been addressed. 

BR-F-6: Mainframes Must Be Dedicated to CMS 

CMS must be the sole user of the mainframe resources, when those resources are operated with an ATO and access CMS data, as detailed in the following paragraphs. 

• For Processing Resources: CMS’s IBM Mainframe Logical Partitions (LPAR) may be used on the same machine as other data center tenants (including the data center operator), provided the LPARs processors are dedicated to CMS use only when processing CMS data. 
• For Storage Resources: If storage is secured via the LPAR, dedicated storage is not required. Storage allocation on the hardware must be dedicated to the CMS LPAR. Thus, storage media may not be shared between CMS and other tenants. Note that this rule applies to online, nearline, and offline storage. 

For all resources, an appropriate Authorization, Auditing and Authentication tool (AAA) for access control must be used to protect both CMS data and processing capability. 

Rationale: 

CMS has two broad concerns with sharing mainframes. The first concern is protecting CMS data. CMS wants to ensure that CMS data is protected and separated from other user workloads. As a result, CMS considers it essential to isolate CMS processing resources from other tenants (including the hosting provider). For example, although storage hardware such as tape silos may be shared with other tenants, the storage medium such as tapes may not be. 

The second concern is sharing infrastructure among non-CMS tenants. Shared infrastructure, including the mainframe that hosts the LPARs and any related networking or other components shared by the LPARs, constitutes both performance and security risks. The performance risk is that shared infrastructure may be unable to meet CMS performance needs. The security risk of shared infrastructure includes, for example, potential for data leakage and lessened availability due to misconfiguration or lack of coordination or oversubscription. 

In addition, CMS needs assurance that it is not subsidizing other tenant workloads on CMS-funded environments. 

Mainframe LPAR processors need not be dedicated to CMS when used for development or test purposes, so long as no CMS data is processed. 

Note that this business rule also applies to CMS mainframe resources used for Disaster Recovery. 

BR-F-7: Cost-Effective Reuse of Data Centers with Established TIC, CMSNet, and CCIC Integration 

Projects must reuse data centers with established TIC, CMSNet, and CCIC integration. 

Related CMS ARS Security Controls include: SA-2 - Allocation of Resources. 

Rationale: 

This rule supports cost savings related to OMB-mandated physical data center consolidation (Update to Data Center Consolidation Initiative (DCOI), OMB/Federal CIO Kent, June 25, 2019) and more efficient use of security monitoring services. As stated in the OMB memorandum, data center consolidation will promote the use of Green IT by reducing the overall energy and real estate footprint of government data centers; reduce the cost of data center hardware, software, and operations; increase the overall IT security posture of the government; and shift IT investments to more efficient computing platforms and technologies. 

BR-F-8: Backup CMS Data 

All CMS data must be backed up regularly, on a documented schedule, regardless of hosting implementation (i.e., physical data center, Cloud, etc.). 

ARS Security Control CP-9 provides specific requirements for backup. Note that Cloud Service Providers have additional requirements under this control. All backups must be secured from unauthorized access and disclosure. 

Related CMS ARS Security Controls include: CP-6 - Alternate Storage Site, AU-2 - Event Logging, CP-9 - System Backup, and CP-9(8) - Cryptographic Protection. 

Rationale: 

Disaster Recovery and Fault Tolerance (FT) is sometimes confused with data backup. Data backup is an essential part of any CMS Processing Environment because it offers the ability to restore data to the most recent copy as well as one of several older copies. This backup capability facilitates comparative analysis and recovery from data corruption, neither of which can be handled by DR or FT. 

The OIT Backups Policy provides details about implementation. The basic requirement is to meet the “return to service” requirements per the system’s ATO. AWS Backups for AWS and Azure Backups for Microsoft Azure for Government (MAG) cloud are preferred, replacing the Cloud Protection Manager (CPM). 

Backups also differ from archives, which are performed for Records Management. 

PREFERRED - The CMS recommended backup tools are AWS Backups and Azure Backups in Microsoft Azure for Government (MAG). 

BR-F-9: Test CMS Backups on a Documented Schedule 

CMS backups and associated procedures must be tested for corruption and completeness on a regular basis to ensure that restoration can occur, if need be. 

Rationale: 

Improper testing of backups is a frequent cause of operational issues. Restoring backups and comparing against a master copy is one way to test backups. System maintainers are encouraged to explore alternatives to select the most appropriate method for their projects. 

Related CMS ARS Controls include: CP-9(1) - Testing for Reliability/Integrity and CM-4(1) - Separate Test Environments. 

BR-F-10: Annual Review and Exercise of Data Center Disaster Recovery Plans 

Disaster recovery plans and their supporting documents must be reviewed and re-evaluated annually or on a significant change to the operating environment. In addition, DR plans must be exercised to ensure that the plans are complete and accurate and to make certain that authorized personnel can execute their training. 

Rationale: 

The review and exercise of DR plans assures that the plans are accurate and up to date and that all parties understand their roles in the event of a disaster. 

Related CMS ARS Controls include: CP-8 - Telecommunications Services and CP-10 - System Recovery and Reconstitution. 

BR-F-11: Annual Review and Exercise of Contingency Plans 

Contingency Plans (CP) and any supporting documents must be reviewed and re-evaluated annually or on a significant change to the operating environment. In addition, the CPs must be exercised to ensure that the plans are complete and accurate and to ensure that personnel can execute their training (see CMS Information System Contingency Plan (ISCP) Handbook). 

Rationale: 

The review and exercise of CPs assures that the plans are accurate and up to date and that all parties understand their roles in the event of a disaster. 

Related CMS ARS Controls include: CP-10 - System Recovery and Reconstitution and CP-4 - Contingency Plan Testing. 

BR-F-12: Role-Based Security AAA Must Be Used for Management and User Roles 

Use Role-based Security Authentication, Authorization, and Accounting (AAA) functions provided by a shared AAA server within the data center to ensure that management and user roles are common throughout a zone. 

Related CMS ARS Controls include: AC-3 - Access Control, AC-5 - Separation of Duties, and AC-6 - Least Privilege. 

Rationale: 

This rule prevents accidental or unauthorized access. 

BR-F-13: Consistent Security Categorization within ARS Security Boundary 

All applications or systems within the same security control assessment boundary must implement security controls that meet the requirements for the highest Federal Information Processing Standards (FIPS)-199 security categorization level rating of any of the applications or systems. 

Related CMS ARS Security Controls include: RA-2 - Security Categorization, CA-6 - Authorization, and SC-32 - Information System Partitioning. 

Rationale: 

Security is only as good as the weakest link. All systems within the same Security Control Assessment (SCA) Boundary must be hardened adequate to prevent compromise of the most sensitive system or data. A compromised system may be used to attack other systems within the boundary. 

BR-F-14: Applications with Disparate FIPS-199 Security Categorization Levels Must Not Be Hosted on the Same Server 

BR-F-13 also establishes requirements related to this recommended practice. 

Related CMS ARS Security Controls include: RA-2 - Security Categorization, CA-6 - Authorization, and SC-32 - Information System Partitioning. 

Rationale: 

Co-locating systems with disparate ratings is not a normal practice because providing additional security controls to bring FIPS Low-rated applications to the FIPS Moderate or a higher grade, as required by BR-F-13, will increase the complexity and costs of the process. 

BR-F-15: Ensure Timely Version, Patch, and Configuration Management Practices 

All organizations responsible for operations and maintenance (O&M) of CMS Processing Environments must develop and employ timely version, patch, and configuration management practices to protect CMS component hardware, software, and data against threats to confidentiality, integrity, and availability while minimizing negative impacts to business operations. These practices must include coordination with other related CMS Processing Environment operators and affected application owners. 

Related CMS ARS Security Controls include: CM-1 - Policies and Procedures, CM-3 - Configuration Change Control, and PL-2 - System Security and Privacy Plan. 

Rationale: 

Delaying deployment of new security features and patches leaves CMS IT assets vulnerable. Untimely and uncoordinated deployment of new security features and patches can also interfere with business operations, disrupt the normal operation of IT systems, or introduce unexpected issues affecting the interoperability, performance, or access to CMS IT systems. Therefore, having effective and efficient version, patch, and configuration management practices are essential to the operations of CMS Processing Environments. 

BR-F-16: All Hosts Must Share a Common, Authenticated Time Server 

Rationale: 

This rule ensures that audit logs can be correlated between systems. Originally, this rule was non-production only, but it applies to all OS instances (such as VM, physical, cloud compute and containers that run their own Network Time Protocol Daemon) as well as networking equipment. 

BR-F-17: The CMS TRA Applies to Custom-Produced as well as COTS Products and Services 

Rationale: 

The CMS TRA is an integrated approach to system and security engineering. Commercial Off-the-Shelf (COTS) products as well as custom-developed software must comply with the CMS TRA to ensure interoperability within and integration into the CMS Processing Environments. This compliance must be validated prior to acquisition. The TRB may allow an exception for COTS products that cannot be made to comply; however, these deviations must be documented, reviewed, and approved by the TRB. 

BR-F-18: Use .Gov Domain Names for All CMS Internet Traffic 

All CMS Internet traffic for Agency business, including all web traffic and email, must use domain names ending in “.gov”. Requests for the use of second-level domain names not previously used for CMS Agency business must be approved by the CMS Office of Communications. 

Rationale: 

Both the OMB and HHS have policies prohibiting the use of most top-level domains for agency business. 

The OMB Memorandum M-23-22, Delivering a Digital-First Public Experience, September 22, 2023, stipulates each agency must use only an approved .gov or .mil domain for its official public-facing websites. The requirement to use only approved government domains does not apply in circumstances where the agency is a user or a customer of a third-party website or service that resides on a non-governmental domain. 

The HHS Internet Domain Names Policy regulates the usage, approval, acquisition, and registration of HHS Internet domain names. The CMS Office of Communications coordinates waiver requests for second-level .Gov domain names, such as healthcare.gov, medicare.gov, and CMS.gov. 

BR-F-19: Communication Initiated to Internet-Based Services from ATO’d Environments Must Be Allowlisted 

Communications initiated to Internet-based services must be allowlisted, either by IP address or by domain name, by a CMS-controlled security service. 

Exception: An application may be granted broader access capabilities if it uses an authenticated security service that keeps detailed usage logs. To obtain such an exception, consult with the TRB before adopting such an architecture. 

Related CMS ARS Security Controls include: AC-3(09) - Supplemental: Controlled Release, AC-4 - Information Flow Enforcement, AC-4(08) - Supplemental: Security and Privacy Policy Filters, and AC-6 - Least Privilege. 

Rationale: 

Environments covered under an ATO typically contain CMS data (not test data) and are targets for attack. To reduce the likelihood of unauthorized or unintended disclosure and exfiltration as well as limit the impact of malware, Internet endpoints for CMS applications must appear in a security service allowlist. 

An associated CMS TRA business rule, BR-SEC-FW-2, defines how interzone communications are restricted (by default). 

BR-F-20: Untrusted Services and Code from Third-Party Websites and Applications 

CMS applications should only use services from Third-Party Websites and Applications (TPWA) where the terms of service are acceptable with regard to CMS business needs, including security and privacy, data use, and service levels. 

Likewise, CMS applications should only reference or initiate the download and execution of code from TPWA providers where the terms of service are acceptable with regard to CMS business needs, including security, privacy, and data use. Examples of TPWA-provided code include, but are not limited to, scripts that run in a browser, apps that install on desktop or mobile devices, or executable software. 

Related CMS ARS Security Controls include: AC-20, Use of External Systems. 

Rationale: 

Using untrusted code or services from a TPWA may lead to potential data leakage and privacy violations. Referencing services or downloading or code from a TPWA is inviting an external source to operate in concert with applications from CMS. This is a dangerous practice because the TPWA provider may change their code at any time and without notice. This may result in malware execution because a TPWA domain name expired, the link was changed, or the code was changed without notice to CMS. 

Some TPWA providers may also embed in their code or content links to additional TPWA providers who may distribute unwanted content or malware. TPWA providers may also share collected data with additional unidentified providers who may not be bound by the TPWA’s terms of service. 

RP-F-21: Limit Data in the Application and Presentation Zones 

While application services (Application Zone) may temporarily store data for processing as described in BR-SA-5 , the data should be limited to only what is needed to complete the processing task. Avoid having full copies of data sets (i.e., files, query datasets, etc.) in the Application and Presentation Zones. 

BR-F-22: The CMS TRA Defines a Services Framework Architecture 

The Services Framework Architecture defines services based upon function, edge services, application services and data services. Mediation services are required to be applied to each service to provide compliance and security. 

The Services Framework is a service-fabric that integrates services as required with two key requirements - data should be at least three independent challenges away from the open Internet and a service should front access to the application data. 

To comply with the defense-in-depth principles, the architecture should implement a service as the authorized channel to access the application data. Users from external networks, CMSNet, or the CMS LAN must be authenticated to access the service fronting the data. Additionally, the file storage service must be configured to deny access to all unauthenticated users and all unauthorized users. 

Related CMS ARS Security Controls include: CM-2 - Baseline Configuration, PL-8 - Information Security Architecture, SA-8 - Security Engineering Principles, SC-2 - Application Partitioning, and SC-32 - Information System Partitioning. 

Rationale: 

The evolution of cloud and modern technologies has created more dynamic environments. As a result, the Service Framework Architecture, has been developed to align Defense-in-Depth principles with new cloud architectures. 

CMS Technical Review Board 

This topic is based on the TRB Research Spotlight CMS TRB Engagement Guidance, Updated June 7, 2024. 

The Technical Review Board (TRB) is the CMS governing body that oversees and provides guidance on CMS’s IT investments to ensure they are consistent with the Agency’s IT strategy and architecture. The TRB provides intellectual continuity of high-level architectural decisions and direction, and promotes IT reuse, information sharing, and systems integration across the Agency. 

The TRB engages with project teams by request at key decision points throughout the CMS IT project life cycle in accordance with the project’s demonstrated compliance with 

• The CMS Target Life Cycle (TLC) 
• Agency enterprise architecture principles 
• CMS policies, procedures, standards, and guidelines 

The TRB encourages developers, especially developers using the newer, iterative development methodologies (e.g., Agile and Lean), to review and plan their project implementation to minimize the impact of changes resulting from TRB guidance received during the development process. For more information about engaging with the TRB, please visit the CMS TRB SharePoint site. 

The Technical Review Board offers different engagement types reviews of any proposed system . Project teams can engage with the TRB for various purposes, facilitating project progress and adherence to CMS standards. The TRB provides technical consults on CMS projects related to Infrastructure, Software, Interface, Security, Performance, and Technology at various stages of the system lifecycle. These consultations may occur on an ad-hoc basis or follow a regular cadence, allowing for discussions with the TRB to benefit from their expertise without impeding project timelines. 

TRB Services 

The CMS Technical Review Board (TRB) is a technical assistance resource for project teams across the agency at all stages of their system’s life cycle. It offers consultations and reviews on an ongoing or one-off basis, allowing project teams to consult with a cross-functional team of technical advisors. It also guides project teams on adhering to CMS technical standards and leveraging existing technologies. 

Teams can consult regarding: 

• ask for help with a technical problem 
• review potential solutions or ideas with the TRB and other Subject Matter Experts (SMEs) 
• schedule an ongoing cadence of technical consultations 
• consult with SMEs from across the agency 
• consult with the TRB about CMS guidelines and standards 
• request research or information about a particular technical topic 

Requesting TRB Services 

The project team can request TRB services at any point in the life cycle of the project. The TRB CaaS and TRB Consults can all be requested by submitting a Technical Assistance request in EASi system at easi.cms.gov/trb or by reaching out via email to the TRB mailbox at CMS-TRB@cms.hhs.gov. Such requests must be initiated by a CMS Employee, preferably the business owner, project manager, or technical lead. 

Preparing for TRB Sessions and TRB CaaS Engagement 

To help facilitate the TRB Consults, TRB requires the project teams to fill in the EASi intake form with a clear business context, any relevant technical diagrams, and the areas where help is sought and upload any relevant artifacts before the scheduled meeting. 

The TRB Consults and TRB CaaS engagements are informal and do not have any prescribed templates for the presentation. The project teams are recommended to provide a document explaining the system and the changes/questions that the team is seeking guidance on, along with a background and brief description of the system and the system diagrams. Most of the technical discussion centers around the system architecture/design diagrams, and the project team should prepare system architecture/design diagrams that depict the current and proposed changes with all the system components. Clear and complete diagrams will lead to a more meaningful engagement. 

The TRB-published review templates are located on the CMS Enterprise website at: 
TRB Architectural Diagrams Sample and Diagram Requirements - Instructions 

What Project Materials are required for the TRB Engagements? 

To help facilitate the TRB Design and Operational Readiness Session engagements, TRB requires the project teams to fill in the TRB Templates noted above and send them to the TRB mailbox in advance of the scheduled meeting. 

TRB Consults and TRB CaaS engagements being informal, do not have any prescribed templates for the presentation. The project teams are recommended to provide a document that explains the system and the changes/questions that the team is seeking guidance on, along with a background and brief description of the system and the system diagrams. A majority of the technical discussion centers around the system architecture/design diagrams and the project team should prepare system architecture/design diagrams that depict the current and proposed changes with all the system components. Clear and complete diagrams will lead to a more meaningful engagement. 

Who Should Attend the TRB Engagements? 

The following members should attend: 

1. A CMS employee with oversight of the project, such as CMS’ Contracting Officer Representative (COR) and/or Government Task Lead (GTL)/ CMS Project Manager, must be present at the sessions. (Note: The TRB cannot meet without one of these individuals). 
2. CMS Business Owner Representative. 
3. Information Systems Security Officer (ISSO). 
4. Contractor Project Manager (PM) responsible for the overall effort 
5. Lead Business Analyst who can address the business purpose, context, and process. 
6. Lead Technical or Solution Architect who can address the architecture and design. 
7. Development lead who can address the development process, DevSecOps, and overall testing. 

What do I need to do on the day of my Scheduled TRB Session? 

TRB Session meetings are conducted at CMS’ Central Office, and zoom sessions are always available. In the case when the CMS Central Office is closed, TRB Session meetings will be held entirely virtually. To attend the meeting virtually, please click on the TRB Meeting link that is sent in the meeting invite. 

We recommend that you login a few minutes early to ensure that you can share your screen and display your presentation properly. 

Please make sure to input your full name when logging into Zoom for the TRB Meeting. Due to the sensitive nature of the presentations, we require that all participants identify themselves on Zoom. Unidentified participants will be removed from the call. 

What to expect after the TRB Session? 

The project teams will receive a TRB Advice Letter within five business days for any Design/Operational Readiness/Consults. TRB Consult as a Service engagement meetings run by the TRB will be provided with a response in the form of meeting notes within a couple of days of the engagement. For continuous ongoing TRB CaaS engagement, the TRB notes might be sent out based on a need-by-need basis as determined by the TRB. 

References 

• CMS TRB webpage 
• TRB Frequently Asked Questions 
• CMS Technical Reference Architecture 
• Target Life Cycle 

TRA Architecture Change Request (ACR) Process 

The ACR Process establishes the standard CMS process for request, review, approval, and publication of changes to the CMS TRA. The ACR Process consists of the major activities as shown in Architecture Change Request Process and below. The CMS TRA is accessible via the TRA websites. The complete version of the TRA is provided via an internal TRA website tra.cloud.cms.gov that is accessible to CMS employees and contractors with CMS network access. A public version is available to anyone at https://security.cms.gov/policy-guidance/cms-technical-reference-architecture. The public version has CMS sensitive information redacted. Information about the CMS Target Life Cycle (TLC), often referenced in conjunction with the CMS TRA, is accessible on the cms.gov public site.The OIT ISPG site CyberGeek is also available to the public. 

TRA Release Process (page 8) 

Request for Change 

Architecture Change Requests are now integrated with the overall TRA Release Process. Users may submit change requests through the TRA website, using the Topic Feedback feature, or optionally the Review site’s Annotator Feature. In either case, this request will create a Jira ticket to track it. The process below remains available. 

CMS employees submit requests for changes to the CMS TRA using an Architecture Change Request (ACR) Form that is delivered to the Division of IT Investment Management and Policy (DIIMP) via an email to the CMS IT_Governance@cms.hhs.gov mailbox. CMS Contractor partners and/or other employees who identify the need for an Architectural Change should request their Government Task Lead or other CMS employee submit a change request on the contractor’s behalf. 

Review and Prioritization 

The CEA and TRB reviews submitted ACRs to determine how they will be addressed and either closes the request or schedules the change request for processing. 

Reasons for closing a change request at this point include, but are not limited to: 

• Duplicate requests 
• Out-of-scope activities (e.g., production implementation steps) 
• Lack of information to support any actions taken on behalf of the request 

Proposed Updates to the TRA 

Based on input from the CEA, the TRA Release Coordinator works with subject matter experts (SME) to identify changes to the CMS TRA to incorporate into an upcoming release. The TRA Release Coordinator ensures that all selected ACRs are addressed with the stakeholders and SMEs and coordinates the appropriate changes across all impacted parts of the CMS TRA. 

TRA Release Review – Initial TRB Consult 

When the proposed updates are completed, the TRA Release Coordinator submits the revised TRA to the TRB for initial review and schedules a TRB consult to discuss the proposed changes. The TRA Release Coordinator then updates the release based on TRB Consult comments and feedback received during the review period. Some comments may be addressed by creating a new ACR to be assigned to a future release. 

TRA Release Review – Group Review 

The TRA Release Coordinator submits the release for review by CMS Group Directors, CMS Business Units, and CMS data center operators for review and comment. The TRA Release Coordinator then updates the release based on comments and feedback received during the review period. Some comments may be addressed by creating a new ACR to be assigned to a future release. 

CIO / CEA Review and Signature 

After the TRB and Group reviews are completed and all comments are addressed, the TRA Release Coordinator submits the release to the CIO and CEA for review, approval, and signature. If the CIO or CEA have any comments, the TRA Release Coordinator addresses the comments and resubmits the release for final review and approval. After all CIO / CEA comments have been addressed, the CIO and CEA sign the release. 

Release Publication 

After the CIO and CEA sign the release, the TRA Release Coordinator publishes the updated CMS TRA. As prescribed in BR-F-2, The CMS TRA Applies to All CMS Processing Environments, the latest published CMS TRA applies immediately for new systems; for existing systems, compliance with CMS TRA updates is required within twenty-four (24) months of publication. 

CYBERSECURITY

Security Services

Security Services Introduction

This Security Services Chapter was developed to be compliant with the CMS Information System Security and Privacy Policy; to complement the CMS TRA by providing detailed engineering guidance for security services (e.g., firewall, intrusion detection system/intrusion detection and prevention [IDS/IDP]) to CMS Processing Environments hosting CMS applications; and to communicate the engineering decisions determined by CMS/Contractor partnerships to date. The CCIC Integration topics provide additional security services requirements for CMS Processing Environments in the areas of security tools, system and device logs integration, incident response, continuous monitoring, and penetration testing.

For the purposes of this chapter, CMS defines a security service as a virtual or physical appliance (device or application) used for security management purposes such as firewalls, switches, routers, and network-based intrusion detection systems (NIDS). In some cases, the security services are supplemented by agents installed on CMS systems.

Relevant Documents

This chapter is not all-inclusive; it complements and incorporates CMS’s existing policies, standards, and procedures, thereby offering an architectural view of the standards. Should any conflict occur, the following standards and any successor documents shall take precedence:

• HHS Policy for Information Security and Privacy Protection (IS2P) (Internal Link)
• CMS Information Systems Security & Privacy Policy (IS2P2)
• CMS Acceptable Risk Safeguards (ARS)
• CMS Publication 100-17, Business Partners Systems Security Manual
• CMS Risk Management Handbook, Risk Assessment (RA)
• HHS Standard for Encryption of Computing Devices and Information, HHS-OCIO-OIS-2022-12-001, December 9, 2022

Except as noted, the foregoing documents may be downloaded from the CMS Information Security and Privacy Libraryand the Cybergeek CMS Policies and Guidance website.

General Security and Privacy Requirements

The CMS TRA uses the term “CMS Sensitive Information” as defined in the NIST Computer Security Resource Center (CSRC) Glossary, and subject to Executive Order 13556 -- Controlled Unclassified Information. See also in CyberGeek, What is considered “sensitive information”. This definition includes all data that require protection due to the risk and magnitude of loss or harm, such as Personally Identifiable Information (PII), Protected Health Information (PHI), and Federal Tax Information (FTI).

The cybersecurity and privacy requirements in this chapter support the engineering details necessary to implement, manage, and audit all infrastructure components that provide information security for the CMS Processing Environments. Deviations to this technical architecture require explicit approval from the CMS Technical Review Board (TRB) and must be documented as part of the System Security Plan (SSP) and Information Security Risk Assessment (ISRA).

Furthermore, if an application developer/maintainer cannot comply directly with this technical architecture, the project must implement compensating information security and privacy controls and clearly document reductions in risk due to the compensating controls in a proposed risk-based decision for acceptance/rejection by the Authorizing Official (AO) for the application. Information System Security Officers (ISSO) must also conduct a Privacy Impact Assessment (PIA) and a Security Impact Analysis (SIA) for any changes, as required by CMS ARS Security Control CM-4.

New systems and systems with significant changes must obtain an ATO before commencing production operations. Business owners must arrange for testing and submit a complete ATO package to the Information Security and Privacy Group (ISPG) in accordance with current procedures.

CMS TRA Multi-Zone Architecture Security Requirements

The multi-zone architecture supporting the CMS Processing Environments separates each zone by firewalls (virtual or physical) to promote application security. The Foundation section of the TRA (see CMS Services Framework) details how the Multi-Zone Architecture, built upon a services framework, supports CMS security requirements. The services framework defines edge, application, data, management and security services. These services are mapped to an analogous zone (for example application services are mapped to the application zone), except for edge services which are mapped to the presentation zone. The zones generally have clearly defined boundaries when implemented at a CMS data center. The zones may not be so clearly defined when implemented within the cloud. Note that in the topics that follow, the word “server” is used in its most generic context. Servers in this context can refer to physical servers, virtual servers, or even services provided by a cloud service provider. The outermost zone — the Presentation Zone — supports web servers. The middle zone — the Application Zone — supports business logic for the applications. The innermost zone — the Data Zone—contains the data storage, database servers, and data services used by the applications. The Management Zone supports typical systems management functions and network services that include management functions such as Public Key Infrastructure (PKI), Domain Name System (DNS), system backup, patch management, and security monitoring. To maintain separation of management and security activities from those activities inherent to an application, the Management and Security Zones are configured using separate network segments connected to secondary network interfaces of the zone devices and the corresponding devices in the Management and Security Zones. CMS Multi-Zone Architecture illustrates the CMS TRA Multi-Zone Architecture.

In CMS data centers, all inbound and outbound traffic to each zone routes through highly available switches and firewalls to reduce the possibility of compromising the entire network and is protected by highly available IDSs. These network-centric devices must be implemented as dedicated appliances or virtual instances implemented on non-general purpose operating systems. Physical network segmentation (for on premise) or virtual network segmentation (for cloud) must separate all TRA zones.

CMS TRA Multi-Zone Architecture

Presentation Zone

The Presentation Zone contains the servers supporting the static web page content for CMS applications. No application or database logic processing will be executed on servers in the Presentation Zone. The Presentation Zone will proxy communication requests to the Application Zone (i.e., no application-related connection will be allowed into the Application Zone that has not first originated in the Presentation Zone). The Presentation Zone is expected to perform application firewall (e.g., layer 7) analysis and content inspection processing. The purpose of this is to verify the integrity of content. Services in the Presentation Zone must not write to disk any data submitted by a client or any sensitive information passed to the client.

In CMS data centers, all inbound and outbound traffic to the Presentation Zone must be protected by highly available, CMS-dedicated firewalls, and network- and host-based IDS/IDPs. The firewalls and IDS/IDPs provide a concentration of security services for the Presentation Zone that include, at a minimum, packet and protocol filtering, packet inspection, information hiding, and audit logging consistent with CCIC requirements, and are required in all CMS processing environments. All host names and network IP addresses behind the Internet-facing border firewall must be masked to the external network.

Application Zone

Application servers (including web-based applications) are located in the Application Zone. As required, this zone can host services to support any non-web-based application need. For example, many applications need to exchange files with other CMS business partners. In those cases, the server providing file transfer functions must reside in the Application Zone and must be proxied by file transfer services in the Presentation Zone.

The Application Zone can also host proxy services to the Data Zone. This occurs when LDAP is used for authentication services. The LDAP store must reside in the Data Zone and an LDAP proxy will be hosted in the Application Zone, thus providing the authentication service to devices that reside in either the Presentation or Application Zones. When resources located in the Data Zone require LDAP services, an LDAP proxy will be required in the Data Zone (i.e., all access to the LDAP data store must be via an LDAP proxy). System requirements vary widely based on business and technology needs; therefore, the foregoing example shows how proxy services may supplement system design to maintain the zone architectures.

All application-related connections inbound to the Application Zone must originate from the Presentation Zone. Inbound connections from the Data Zone (to the Application Zone) will be allowed to support approved application messaging protocols. In CMS data centers, all inbound and outbound traffic to the Application Zone must be protected by highly available, CMS-dedicated firewalls and network- and host-based IDS/IDPs. The dedicated firewalls and IDS/IDPs provide a concentration of security services for the Application Zone that include, at a minimum, packet and protocol filtering, packet inspection, information hiding, and audit logging consistent with CCIC requirements, and are required in all CMS processing environments.

When implementing virtual firewalls, stateful inspection firewalls must be on a dedicated Virtual Machine (VM) to ensure (a) restriction of access controls to the security administrators and (b) proper segregation and maintenance of duties. A single, firewall-dedicated VM may be used to host more than one firewall instance.

Data Zone

The Data Zone contains all data sources, including data stores supporting directory services / authentication functions, data warehouses, and data marts as well as the applications’ operational databases. All interactions to and from the Application Zone and the Data Zone must pass via a commonly-used access method. Examples can be found in Data Services Access Methods. CMS permits the use of database-stored procedures that may reside on database servers in the Data Zone.

In CMS data centers, all inbound and outbound traffic to the Data Zone must be protected by highly available, CMS-dedicated firewalls and network- and host-based IDS/IDPs. The dedicated firewalls and IDS/IDPs provide a concentration of security services for the Data Zone that include, at a minimum, packet and protocol filtering, packet inspection, information hiding, and audit logging consistent with CCIC requirements, and are required in all CMS processing environments. All non-Management Zone connections inbound to the Data Zone must originate from the Application Zone and use a TRB approved protocol.

Programs in the Data Zone may not originate any communications to endpoints outside the Data Zone. Data Zone-to-Data Zone communications are permitted.

WAN Connections

WAN connections between like zones in different data centers must maintain the same level of Defense-in-Depth protections. Various types of zone-to-zone connections are documented in the Wide Area Network Services chapter.

WAN connections must:

• Utilize mutual authentication and encrypted tunnels to secure zone-to-zone connections
• Include centrally managed, stateful inspection firewall, IDS, and IDP at both ends of all tunnels

Please refer to Wide Area Network Services for more information and requirements concerning Wide Area Networking.

Management and Security Zones

The CMS TRA requires isolation of Management and Security Services on dedicated network zones. Remote access into Management and Security Zones is restricted to Internet Protocol Security (IPSec) VPNs utilizing multi-factor authentication.

Each host in a zone must have separate network interfaces for the Security and Management Zones. Network traffic in the Management and Security Zones must use separate Virtual LANs (VLAN) on the respective Management or Security network interfaces. The CCIC Integration chapter identifies mandatory security tools and security functions applicable to CMS data centers.

Workstations in the Management and Security Zones must be configured to assure the integrity and protection of the various zones. To ensure rigorous anti-virus protection mechanisms, CMS requires sandboxing technologies and/or proxy services between the Management and Security Zones and the Presentation, Application, and Data Zones.

Workstations in the Management and Security Zones must be isolated from all networks other than the zone(s) that they manage.

In CMS data centers, all inbound and outbound traffic to the Management and Security Zones must be protected by highly available, CMS-dedicated firewalls and network- and host-based IDS/IDPs. The dedicated firewalls and IDS/IDPs provide a concentration of security services that include, at a minimum, packet and protocol filtering, packet inspection, information hiding, and audit logging consistent with CCIC requirements, and must be implemented in all CMS processing environments.

Audit Log Generation and Collection Requirements

The CMS ARS requires the use of security technologies to monitor potential system intrusions. Security documentation must define all events that require investigation and the associated response times. Associated security tools must identify how each security event has been investigated and what associated response actions have been taken. Therefore, all devices must be configured to create and retain log information to support security monitoring functions and/or forensic investigations. The CCIC Integration chapter contains a complete list of system and device logs that must be collected.

The CMS ARS Security Controls AU-8, SC-45 and SC-45(1) define the requirements for time synchronization.

To prevent unauthorized changes to logged information and limit interactive access to CMS Processing Environments as well as allow cross-component log correlation, CMS requires support for centralized log analysis. All devices capable of generating log information — including, but not limited to, host-based IDSs (HIDS), network-based IDS/IDPs, firewalls, operating systems, middleware, databases, and applications — must be centrally managed and engineered to either send log information to the Security Zone directly or to allow the logs to be pulled into the Security Zone. Both real-time and batch delivery are acceptable. (The CMS ARS provides detailed requirements for logging data and collection frequency.) Logs from all components in all zones must be aggregated in the Security Zone and analyzed by the local system developer and maintainer (SDM) Security Operations Center (SOC), and in turn integrated with the CCIC (as described below in Security Architecture and Engineering).

Trusted Internet Connections

Office of Management and Budget (OMB) Memorandum M-08-05, Implementation of Trusted Internet Connections, November 20, 2007, states that all federal agencies must optimize and standardize the security of individual external connections. In addition, security controls must be implemented within all federal network operating environments.

Use of a TIC is also required by CMS ARS Security Control SC-07(3) - Access Points (High, Moderate) (CSP: Mod) P1, which provides, “Limit the number of external network connections to the HVA;” and further provides as Implementation Standards for High & Moderate: Std.1 – “Implementation must route external connections via a Trusted Internet Connection[JD7]  (TIC) portal.”

The mission of the Trusted Internet Connections program is to provide a means for monitoring, isolating, and securing federal external network connections in the event of cyberattacks. The program requires the Agency to route all traffic to and from external networks through TIC Zones managed by TICAPs operated by the Agency or third parties, such as a Managed Trusted Internet Provider Service (MTIPS). The TIC Zone has the following features:

• External connection termination point
• Monitored by EINSTEIN
• Intrusion Detection System for protection of federal information technology (IT)
• Capable of alerting the US-CERT (United States Computer Emergency Readiness Team) to the presence of malicious or potentially harmful computer network activity
• Network connections and data filtering
• Full packet capture and storage

CMS follows a TIC deployment strategy aligned with the Department. HHS provides TIC services for all HHS Operating Divisions, including CMS data centers and applications. The National Institutes of Health (NIH) operates the HHS TIC services.

CMS application owners and data center operators are responsible for extranet connections to external networks, and for working with the HHS Office of Information Security (OIS) and NIH TIC teams to ensure the extranet connections are properly implemented and extranet traffic is monitored through HHS TIC services. This includes extranet connections to cloud providers and to other government networks.

Malicious Code Protection

Malicious code can be introduced into a system by many different means, including:

• Web accesses, electronic mail and attachments, and portable storage devices
• Exploitation of information system vulnerabilities
• Installation or execution of custom-built software or Commercial Off-the-Shelf (COTS) software

Malicious code protection mechanisms must be employed at information system entry and exit points to detect and eradicate malicious code. Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers, proxy servers, remote access servers, workstations, notebook computers, and mobile devices.

Malicious code protection mechanisms may employ a variety of technologies and methods to limit or eliminate the effects of malicious code, including for example, anti-virus signature definitions and reputation-based technologies. Pervasive configuration management and comprehensive software integrity controls may be effective in preventing execution of unauthorized code. Other safeguards include secure coding practices, configuration management and control, procurement from trusted sources using secure delivery methods, and monitoring practices to help ensure that software does not perform functions other than the functions intended.

Malicious code protection mechanisms must be updated whenever new releases are available in accordance with CMS Risk Management Handbook: Configuration Management (CM)procedures. The minimum frequencies for updating are defined by these CMS ARS controls:

• Malware, e.g., Anti-Virus (AV): SI-3 - Malicious Code Protection
• Vulnerability scan: RA-5 - Vulnerability Monitoring and Scanning
• Software Integrity check: SI-7(1) - Integrity Checks
• Boundary/IDS: SI-4(2) - Automated Tools and Mechanisms for Real-Time Analysis
• Vulnerability scanning: RA-5(2) - Update Vulnerabilities to be Scanned

Please refer to CMS ARS Security Control SI-03 for additional guidance on malicious code protection. Please also refer to BR-CCIC-23, Network Security Endpoint Protection Capability,in the CCIC Integration chapter.

Scanning

Malicious code protection mechanisms that perform scanning of files, systems, or networks must be configured to:

1. Perform periodic scans of the information system in accordance with the specific type and frequency prescribed in the CMS ARS.
2. Perform real-time scans of files or content from external sources at endpoint, and/or network entry/exit points, as the files are downloaded, opened, or executed.
3. Block and quarantine malicious code and send alerts to the administrator in response to malicious code detection.

Scanning Submitted Files

Before applying any operational function to the contents of a submitted file, it must be scanned for malware. Contents of newly submitted files must be scanned in the Presentation or Application Zone before transfer to the Data Zone.

Scanning Information Systems

On servers, malicious code scanning services must be configured to perform periodic scans of critical system files and periodic full system scans as specified in the CMS ARS or by FedRAMP (Federal Risk and Authorization Management Program) requirements.

For cloud service providers, the organization must configure malicious code protection mechanisms to:

• Perform periodic scans of the information system and real-time scans of files from external sources as the files are downloaded, opened, or executed in accordance with organizational security policy; and
• Block or quarantine malicious code, send alerts to the administrator, and send alerts to FedRAMP in response to malicious code detection.

Malicious code scanning results are reported to the CMS Cybersecurity Integration Center Security Information and Event Management system[JD8]  in compliance with CMS ARS Security Control AU-06.

Detection / Incident Response

Organizations may determine that, in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, actions in response to detection of malicious downloads, and/or actions in response to detection of maliciousness when attempting to open or execute files.

Malicious code must be reported to the local SOC and to the CCIC. As part of an incident management plan, organizations must be prepared to take immediate or automated action to mitigate damage from malicious code when it is detected, as well as comply with requirements and incident management procedures described in the CCIC Integration chapter.

The organization must also address the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the information system.

CMS Continuous Monitoring Requirements

CMS Continuous Monitoring Requirements are detailed in the CCIC Integration chapter.

Business Rules

The following business rule defines general security policies within the CMS environments.

BR-SEC-Gen-1: Traffic between and within Zones Must Be Available in Unencrypted Form for Security Analysis Purposes

When an application’s communications between and within zones is encrypted as required by the CMS ARS, the environment must use mechanisms capable of either decrypting content for security analysis or analyzing security of the content before transmission or after receipt.

There are specific instances where encrypted traffic must remain encrypted and not be made available in an unencrypted form for security analysis purposes. Examples include, but are not limited to, LDAP authentication and administrative sessions, such as Secure Shell (SSH) or Remote Desktop.

If a system developer and maintainer cannot comply directly with this business rule, the SDM must implement compensating information security and privacy controls and clearly document reductions in risk due to the compensating controls in a proposed risk-based decision for acceptance/rejection by the Authorizing Official for the environment.

Also note FedRAMP Guidance for M-21-31 and M-22-09, on Alternatives to network inspection. These bullets are extracted from OMB M-22-09

• Current OMB policies neither require nor prohibit inline decryption of enterprise network traffic. Agencies are expected to balance the depth of visibility they need with the risks presented by broadly trusted network inspection devices.
• Network traffic that is not decrypted can and should still be analyzed using visible or logged metadata, machine learning techniques, and other heuristics for detecting anomalous activity. This is consistent with the Trusted Internet Connection (TIC) initiative, as updated in OMB Memorandum M-19-26, which gives agencies the flexibility to maintain appropriate visibility without needing to perform inline traffic decryption.
• OMB Memorandum M-21-31, “Improving the Federal Government’s Investigative and Remediation Capabilities Related to Cybersecurity Incidents”, describes required fields that agencies must log consistently throughout their enterprise, including packet capture logs. M-21-31 does not require full traffic inspection, but specifies fields that should be captured when such inspection is in place. M-21-31 describes this conditional

Related: CMS ARS Security Controls include: SI-4 - Security Monitoring and SC-8 - Transmission Confidentiality and Integrity.

Rationale:

All application traffic between and within zones must be available in an unencrypted form to permit security services and authorized security personnel to perform auditing and monitoring of communications.

Secure Baseline Configuration

BR-SEC-Gen-2: Software and Hardware Components Must Adhere to a Secure Baseline Configuration

All configurable software and hardware components must adhere to a secure baseline configuration authorized to operate by the CMS Chief Information Officer (CIO). All operating systems, network devices, databases, middleware, or other equipment and software must be configured in accordance with CMS Configuration Management (CM) and the CMS ARS, CM-6 - Configuration Settings and CM-7 - Least Functionality. These configurations must be defined in the applicable host environment System Security Plan and must be authorized to operate by the CMS CIO. Note: CMS ARS requirement CM-6 addresses both standard configuration definition and deviations from a standard configuration.

The business owner and SDM must actively manage configurations. Configurations must be validated periodically using the tools hosted in the Security Zone , such as Security Content Automation Protocol (SCAP)-based testing tools and Defense Information Systems Agency (DISA) scripts (STIGs).

Related: Configuration Management; CMS ARS Security Controls include: CM-6 - Configuration Settings and CM-7 - Least Functionality.

Rationale:

All applications and devices must adhere to a secure baseline configuration to provide protection against unauthorized access and malicious attacks, and to permit security services and authorized security personnel to perform auditing and monitoring of communications.

BR-SEC-Gen-3: Disable All Unnecessary Features and Capabilities

All configurable software and hardware components must disable all unnecessary features and capabilities. In addition to implementing the CMS Secure Baselines, any configurable component in the CMS Processing Environments, such as web servers, application servers, other servers, firewalls, or routers, must disable all unnecessary features and capabilities, Internet services, protocols, and applications not expressly required by a CMS application. All compilers, editors, database templates, development tools, unnecessary interpreters, etc. must be removed from the CMS Processing Environments.

Related: Configuration Management; CMS ARS Security Controls include: CM-6 - Configuration Settings and CM-7 - Least Functionality. CMS ARS Security Controls include: CM-6 - Configuration Settings and CM-7 - Least Functionality.

Rationale:

Eliminating unnecessary features, access points, protocols, and developer tools reduces the number of potential attack vectors, as well as possible points of failure.

Internet Connectivity

BR-SEC-Int-3: HTTPS on CMS Public-Facing Websites and Services on the Internet

OMB Memorandum M-15-13, Policy to Require Secure Connections across Federal Websites and Web Services, June 8, 2015, requires that all publicly accessible federal websites and web services only provide service through a secure connection. OMB Memorandum M-23-22, Delivering a Digital-First Public Experience, September 23, 2023, expands on this.

Publicly accessible websites and services are defined in M-15-13 as online resources and services available over HTTP or HTTPS over the public internet that are maintained in whole or in part by the federal government and operated by an agency, contractor, or other organization on behalf of the agency. They present government information or provide services to the public or a specific user group and support the performance of an agency’s mission. This definition includes all web interactions, whether a visitor is logged in or anonymous.

HTTPS is a combination of HTTP and Transport Layer Security (TLS). TLS is a network protocol that establishes an encrypted connection to an authenticated peer over an untrusted network. Only current versions of TLS are to be allowed for connections to CMS public facing websites. See NIST SP 800-52 Rev 2 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations for additional information on TLS versions and requirements.

For websites:

To meet the M-15-13 requirement of enforcing HTTPS, the affected CMS websites:

• Employ server-side redirects. Using only client-side redirects, such as a <meta refresh> tag or JavaScript, is not considered adequate.
• Employ HTTP Strict Transport Security (HSTS) and HSTS preloading.
• Allowing HTTP connections for the sole purpose of redirecting clients to HTTPS connections is acceptable and encouraged.
• HSTS headers must specify a max-age of at least 1 year.
• The parent domain and each of the publicly reachable subdomains must set a HSTS policy with a max-age of at least 1 year.

Preloading marks entire domains as HTTPS-only and allows browsers to enforce this rigorously and automatically for every subdomain. HSTS preloading a parent domain allows agencies to avoid inventorying and configuring an HSTS policy for every individual subdomain; however, this approach also automatically includes all subdomains present on this domain, including intranet subdomains. All subdomains must support HTTPS to remain reachable for use in browsers supporting HSTS. All .gov domains registered after September 1, 2020 are preloaded (Source: An intent to preload).

For API-based services:

CMS public Internet-facing application programming interface (API)-based services must support only HTTPS. Exceptions must be documented in the system design documents (SDD), CMS FISMA Controls Tracking System (CFACTS), and risk assessment for both the system and the environment. If HTTP is in use for such an existing service, a migration plan should be developed. Helpful information on migration planning can be found at www.councils.gov/cioc.

References: OMB M-15-13 and M-23-22. Please refer also to The HTTPS-Only Standard

Related CMS ARS Security Controls include: SC-8 - Transmission Confidentiality and Integrity, AC-14 - Permitted Actions Without Identification or Authentication, AC-22 - Publicly Accessible Content, and PL-4 - Rules of Behavior.

Rationale:

M-15-13 states that all browsing activity should be considered private and sensitive. The HTTPS‑Only standard will eliminate inconsistent, subjective determinations across agencies regarding which content or browsing activity is sensitive in nature and will create a stronger privacy standard government wide. Federal websites that do not convert to HTTPS will not keep pace with privacy and security practices used by commercial organizations and with current and upcoming Internet standards. This failure leaves Americans vulnerable to known threats and may reduce their confidence in their government.

Administrative Access

BR-SEC-Gen-4: Administrative Access to CMS Services and Devices

CMS applications and devices must be configured to prevent the operation of all system administrative functions except those that originate from the Management and Security Zones. When necessary, application administrative functions can be accessed via the Application Zone by defining application administrative roles and documenting the associated risks and compensating controls in the SSP and ISRA.

Where possible, sessions from the Management Zone must not be interactive except where production emergencies dictate such activities or where there are technology limitations. For example, system changes must be tested in a validation environment and required changes pushed into production via automated tools. Where interactive sessions are required, all activity must be securely logged and security management must review the activity to ensure proper separation of duties. For additional information on application administrative access, please refer to the Access Control and Identity Management, Privilege Administration topic.

RelatedConfiguration Management (CM); CMS ARS Security Controls include:
SC-2 - Separation of System and User Functionality, SC-08 - Security Function Isolation, and PE-02 - Physical Access Authorizations by Role.

Rationale:

Restricting network to administrative functions by network port and source reduces the number of potential attack vectors and helps ensure only authorized users and administrative systems have access to sensitive functions.

Malicious Code Protection

BR-SEC-Gen-17: Software Assurance Measures

Software assurance measures, including scanning for malware (malicious software), must be applied to all information systems in the CMS Processing Environment for new or changing code prior to gaining production status, prior to change management activities, and/or as part of routine workflows that support an application.

Related CMS ARS Security Controls include: SI-3 - Malicious Code Protection and SI-10 - Information Input Validation.

Rationale:

Malware may be introduced through user input, file transfers, eXtensible Markup Language (XML) and other transactions, deployments of new or modified software, or direct access to a system. Passive and active malware scanning of files or commands introduced through all these vectors is a critical part of Defense-in-Depth.

BR-SEC-Gen-18: Malicious Code Protection in CMS Processing Environments

Malicious code protection mechanisms must be employed at information system entry and exit points to detect and eradicate malicious code. Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers, proxy servers, remote access servers, workstations, notebook computers, and mobile devices. CMS TRA – Cybersecurity, Security Services, Malicious Code Protection, discusses this in more detail. CMS Hybrid Cloud describes scanning services in CMS approved enterprise security tools and services.

The CMS ARS dictates the required specific type and frequency of virus and malware scanning services by system classification (High, Moderate, and Low).

Related BR-SEC-Gen-18a; CMS ARS Security Controls include: SI-3 - Malicious Code Protection and SI-10 - Information Input Validation.

Rationale:

Malware may be introduced through user input, file transfers, XML and other transactions, deployments of new or modified software, or direct access to a system. Passive and active malware scanning of files or commands introduced through all these vectors is a critical part of Defense-in-Depth.

BR-SEC-Gen-18a: Submitted Files Must Be Scanned in the Presentation or Application Zone

Before applying any operational function to the contents of a submitted file, it must be scanned for malware. Contents of newly submitted files must be scanned in the Presentation or Application Zone before transfer to the Data Zone. Files with detected malware must be quarantined.

Related CMS ARS Security Controls include: SI-3 - Malicious Code Protection and SI-10 - Information Input Validation.

Rationale:

Malware may be introduced through user input, file transfers, XML and other transactions, deployments of new or modified software, or direct access to a system. Passive and active malware scanning of files or commands introduced through all these vectors is a critical part of Defense-in-Depth. CMS Hybrid Cloud describes scanning services in CMS approved enterprise security tools and services.

BR-SEC-Gen-19: User or External Inputs Must Be Validated

All user or external inputs submitted into the CMS Processing Environments must be validated.

CMS information systems must check the validity of defined information inputs (defined in the applicable System Security Plan) for accuracy, completeness, validity, and authenticity as close to the point of origin as possible.

Checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, and acceptable values) verifies that inputs match specified definitions for format and content.

Related CMS ARS Security Controls include: SI-10 - Information Input Validation.

Rationale:

Software applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information.

If software applications use attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. Consequently, the module or component that receives the tainted output will perform the wrong operations or otherwise interpret the data incorrectly.

Prescreening inputs prior to passing to interpreters prevents the content from being unintentionally interpreted as commands. Input validation helps to ensure accurate and correct inputs and prevent attacks such as cross-site scripting and a variety of injection attacks.

BR-SEC-Gen-21: Malware and Malicious Code Scanning Results Must Be Sent to the Security Zone

Malware and malicious code scanning results must be sent to the Security Zone for further analysis/investigation. Note that cloud implementations may utilize shared storage (e.g., AWS S3) as the security zone for result storage and security scanning. Files with detected malware must be quarantined.

Related CMS ARS Security Controls include: SI-3 - Malicious Code Protection, SC-03 - Security Function Isolation, and enhancements under SC-7 (i.e., SC-7(13) - Supplemental: Isolation of Security Tools, Mechanisms, and Support Components) for CSP.

Rationale:

Monitoring and analyzing malicious code scanning results and malware is a function of the Security Zone .

BR-SEC-Gen-20: XML Firewalls Must Be Used to Authenticate XML Exchanges

When a system supports XML exchanges, corresponding protections against malicious attacks must be implemented such as XML firewalls to authenticate the XML and validate the security of the content. XML security devices are typically deployed in the Presentation Zone; validated code is passed back to an application residing in the Application Zone.

With the convergence of network-based security devices, it would be unrealistic to propose a single solution for the prevention of XML-based malicious attacks; XML protections can be found and leveraged in existing firewalls and XML gateways or through XML firewalls.

Related CMS ARS Security Controls include: SI-3 - Malicious Code Protection and SI-10 - Information Input Validation.

Rationale:

System-to-system data exchanges using XML can also be the subject of malicious attacks. Employing separate physical or virtual protection devices reduces the possibility that the protection mechanism becomes a target of malicious attacks.

BR-SEC-Gen-22: All Information Systems Must Have a System Risk Assessment in CFACTS

The system risk assessment must document any malware and malicious code vulnerabilities and suitable plans of action and milestones established in CFACTS. When these vulnerabilities extend to any CMS Processing Environments or other systems, the related ISSOs and system maintainers must also be notified to include the risk in their risk assessments.

Related: Configuration Management (CM); CMS ARS Security Controls include: SI-3 - Malicious Code Protection and PM-4 - Plan of Action and Milestones Process. CMS ARS Security Controls include: SI-3 - Malicious Code Protection and PM-4 - Plan of Action and Milestones Process.

Rationale:

CFACTS is CMS’s primary tool for managing system risk assessments for all CMS information systems.

Vulnerability Management

BR-SEC-Gen-7: Vulnerability Management for CMS Networks, Services, and Devices

Security processes and tools must be defined within the CMS Enterprise Vulnerability Program. Vulnerability identification tools must reside in the Security Zone, or as close to the scanned assets as possible, to reduce security risks and reduce scanning through firewalls. An inventory of all system components must be documented and all associated processes for monitoring vulnerability alerts must be followed. Each vulnerability alert must be documented and the associated action taken and recorded.

To achieve a CMS enterprise-wide vulnerability management and monitoring capability, the infrastructure will allow continuous collection of all vulnerability data at a single location within CMS for centralized analysis and reporting.

The goal of the CMS Enterprise Vulnerability Program is to maintain the capability to collect such data on all CMS IT assets.

Related: Configuration Management (CM); CMS ARS Security Controls include: RA-5 - Vulnerability Monitoring and Scanning and CM-8 - Information System Component Inventory.

Other assessments that fall under other CMS ARS controls can look for vulnerability as well, including for example, pen testing (CA-8); special assessments, such as Risk and Vulnerability Assessments (RVA) under CA-2 (Control Assessments) and RA-3 (Risk Assessment); privacy (RA-8 - Privacy Impact Assessments); and continuous monitoring (CM-7).

Rationale:

Having a vulnerability monitoring plan with inventory and prepared alert actions is prerequisite for CMS’s ability to continuously monitor vulnerabilities and respond quickly to alerts. Documenting alerts and actions taken when an incident occurs is also necessary for determining impacts, determining if additional steps are needed, and supporting further analysis.

Vulnerability Scanning

BR-SEC-Gen-10: Periodic and Continuous Network Vulnerability Scanning Is Required

Periodic and continuous network scanning for security-related vulnerabilities must be performed on all CMS networks.

In addition to periodic network scanning to identify security-related vulnerabilities at every CMS site, CMS requires a continuous CMS enterprise-wide vulnerability scanning capability that must include:

• Establishing a baseline for CMS assets of known and accepted vulnerabilities at each site as well as Agency-wide
• Scanning and producing periodic reports as defined within the CCIC Integration chapter and in accordance with CMS ARS requirements
• Defining a remediation approach, including a prioritization based on score improvement impact at the site and across CMS

Related: Configuration Management (CM); CMS ARS Security Controls include:
RA-5 - Vulnerability Monitoring and Scanning.

Rationale:

Network scanning can uncover configuration vulnerabilities and unauthorized hosts or services. This may include vulnerabilities that may not have been known earlier when configurations were first developed. Analysis and remediation of vulnerabilities identified through network scanning aids in continuous improvement of CMS’s security standing.

Configuration Compliance Management

BR-SEC-Gen-11: Periodic and Continuous Configuration Compliance Scanning Is Required

Periodic and continuous scanning for configuration compliance must be performed on all CMS networks. Security processes and tools must be defined within a configuration compliance management program. The supporting tools must reside in the Security Zone to reduce errors in device configurations. CMS requires a documented inventory of all system components and adherence to all associated processes for monitoring configuration compliance. Each instance of non-compliance must be documented and the corrective action taken and recorded.

CMS requires a CMS enterprise-wide configuration scanning capability (requirements available through the Department of Homeland Security (DHS) Continuous Diagnostics and Mitigation (CDM) Program) that must include:

• Establishing a baseline for CMS assets and configuration baselines for these assets at each site as well as Agency-wide. Baseline configurations must be compliant with CMS ARS CM-6 and documented in the SSP.
• Scanning and producing periodic reports as defined within the CCIC Integration chapter
• Defining a remediation approach, including a prioritization based on score improvement impact at the site and across CMS
• Establishing and periodically testing baselines of approved protocols/services to guard against the introduction of unauthorized configurations within the environment
• Using inventory management tools (requirements available through the DHS CDM Program) to periodically scan the environment to ensure it contains only approved assets

Related: Configuration Management (CM); CMS ARS Security Controls include: CM-06 - Configuration Settings and CM-08 - Information System Component Inventory.

Rationale:

Configuration scanning can uncover configuration vulnerabilities and unauthorized hosts or services. Analysis and remediation of vulnerabilities identified through network scanning aids in continuous improvement of CMS’s security standing.

OMB M-19-03 brings enhanced configuration (compliance) management and monitoring controls to HVA (High Value Assets). The change affects “Planning, Budgeting, Contracting, Procurement, Lifecycle, Strategies,” including:

• Formalized configuration management (CM-2, CM-3, CM-5, CM-6)
• Enhance assessment, monitoring, and remediation (AU-6, CA-2, CA-7, CA-7(4), PM-14, SI-2, SI-4)
• Continuous monitoring (CA-7)
• Additional risk and vulnerability assessments (e.g., CA-8, RA-3, RA-5, SA-3, and SA-17)
• Plan of Action and Milestones creation and tracking (e.g., CA-5 and PM-14)
• Expedited remediation (SI-2)

Host Intrusion Detection

BR-SEC-Gen-12: Host Intrusion Detection Capabilities on All IT Components

A centrally managed IDS / IPS capability is required to monitor network communications on all networks and subnets of any environment requiring a CMS Authority to Operate. In addition, centrally managed IDS / IPS sensor agents are required in all systems, appliances, devices, services, and applications for which such agents are available. It is understood that agents may not be available in all cloud implementations, and implementors should work with their ISSO to address this requirement.

As defined in the CMS ARS, Host Intrusion Detection and monitoring capabilities must include capabilities to detect changes on the hosts (sometimes referred to as file integrity monitoring). System configuration file changes on those hosts monitored by a HIDS must be validated against the corresponding change management requests; files without appropriate change tickets must be investigated as potential security concerns. HIDS agents must be centrally managed and configured to send results to a server installed in the Security Zone for further analysis / investigation. Shareable storage (e.g., AWS S3) may serve as the security zone for the storage and sharing of logs. Events monitored must be documented in CFACTS under the appropriate information security and privacy control. CMS may install additional IDSs to enhance network security monitoring.

Related CMS ARS Security Controls include: SI-4 - System Monitoring.

Rationale:

Intrusion detection can uncover unauthorized changes or activities on CMS hosts.

Log Aggregation and Correlation

BR-SEC-Gen-15: Logs Must Be Securely Collected, Aggregated, and Analyzed

Logs must be securely collected, aggregated, and analyzed in the Security Zone and local SDM SOC and integrated with CCIC. Security documentation must define the events, categorization, and required responses. Each security event must be documented, including all corresponding response actions taken. The CCIC Integration chapter contains a complete list of system and device logs that must be collected.

Related CMS ARS Security Controls include: AU-2 - Event Logging, AU-4 - Audit Log Storage Capacity, AU-6 - Audit Record Review, Analysis, and Reporting, AU-7 - Audit Record Reduction and Report Generation, AU-9 - Protection of Audit Information, and AU-12 - Audit Record Generation.

Rationale:

Monitoring and analyzing logs can detect unauthorized activities, system or resource issues, or malicious attacks on CMS hosts. This ability is further enhanced when logged events from multiple related systems may be aggregated and correlated through a central log monitoring service.

Network Time Protocols

BR-SEC-Gen-23: CMS Network Time Protocol Services

The appropriate CMS Network Time Protocol services must be used across all CMS environments as outlined below.

• The primary domain controllers for awscloud.cms.local domain synchronize time with external NTP sources (NIST time servers).
  • All Windows instances that are joined to this domain synchronize their time with the AD Domain Controller.
• RHEL instances are configured to reach out directly to the NIST time servers.
• AL2 instances use Amazon Time Sync Service for time synchronization.

NTP services must be used to synchronize system clocks across the CMS environment to Coordinated Universal Time (UTC). NTP services must reside in the Management Zone and be configured to peer with CMS-approved NTP time servers (see RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification, June 2010).

Related CMS ARS Security controls include: SC-45 - Supplemental: System Time Synchronization, SC-45(1) - Supplemental: Synchronization with Authoritative Time Source

Rationale:

Synchronization of system clocks across the environment is necessary to ensure proper analysis of audit / logging information, and to promote application data consistency and interoperability. Event correlation depends on the assumption that the timestamps of multiple events, logged in separate places, reflect the same relative timeframes.

Because the CMS enterprise environment spans multiple cloud service providers, regions, and data centers, it is essential that all systems and services synchronize to the same CMS-provided time services hierarchy.

Firewalls

The CMS TRA defines two classes of firewalls:

• Host-based firewalls – firewalls that run locally on and protect only the hosting computer or device
• Network firewalls – hardware or software firewall devices dedicated to providing firewall protection at the borders of one or more networks

All references in the CMS TRA to firewalls apply to both classes unless explicitly stated otherwise.

The CMS TRA also discusses “border” or “boundary” firewalls protecting CMS security boundaries or networks. Such firewalls are network firewalls, unless explicitly stated otherwise.

Although network firewalls are required at security boundaries, host-based firewalls providing endpoint protection improve the standing of CMS’s Defense-in-Depth and may be deployed as a mechanism to address certain CMS ARS controls.

Firewall Configuration

The following CMS TRA Security Firewall (SEC-FW) configuration business rules support the information security and privacy controls required by the CMS ARS (e.g., information flow, least privilege, and audit).

BR-SEC-FW-1: Separate Network Interfaces for Each Network Segment and Zone

Each network firewall in the CMS Processing Environments must be provisioned with separate interfaces dedicated to each network segment and zone with which it connects. This separate interface may be physical or logical and achieved through the implementation of routing and network rules. Some clouds (e.g. AWS) have other mechanisms, such as security groups, to separate interfaces as well. Include separate interfaces for:

• Each zone the firewall connects
• Each gateway or network (e.g., WAN, Internet, and other) the firewall connects
• Automatic failover and load balancing
• Connectivity to the Management and Security Zones

Rationale:

Network segmentation using firewalls helps preclude attacks traversing between segments.

BR-SEC-FW-2: Adhere to CMS Security Hardening Guidance

Network firewalls must be configured in accordance with the CMS policy defined under CMS ARS Security Control CM-6, Configuration Settings, which defines a prioritized list of the required standards. With the CM-6 guidance taking precedence, both network and host-based firewalls must be configured to:

• Deny all requests, protocols, services, destination ports, and destination Internet Protocol addresses, except as expressly permitted in support of a CMS application or service. This includes disabling or preventing Proxy Address Resolution Protocol (Proxy ARP), IP Spoofing, Source Routing, Internet Control Message Protocol redirect (IPv4 and IPv6), and ICMP echoes if not needed.
• Reject all traffic on its network interfaces that appears to come from a broadcast network, reserved network, or loop-back network, unless there is a business justification and is explicitly approved by CMS. Host-based firewalls may permit loop-back network traffic.
• Reject all traffic that enters a given network interface of a firewall that appears to come from a network address not within the valid address range for that interface.
• For border firewalls that connect to an external non-CMS network (i.e., Internet), the firewall must also be configured to reject all traffic at its external interface that appears to come from an internal network address.
• Respond to denied requests by dropping the packet and sending resets.
• Filter and allow packet inspection of all traffic through the (host-based or network) firewall.
• Log all activities in accordance with current CMS ARS requirements.
• Upon startup, prevent routing within the environment and prevent exposure of vulnerabilities while booting.
• During an outage of any sort, network firewalls must revert to a configuration that denies all traffic pending the re-enablement of services by the firewall administrator.
• Network firewalls must ensure that residual information from a previous information flow or internal firewall data is not revealed or transmitted in any way. Resources must be overwritten or cleared before they may be available for reuse.

Related: Configuration Management (CM); CMS ARS Security Controls include: CM-6 - Configuration Settings, AC-6 - Least Privilege, and CM-7 - Least Functionality.

Rationale:

These are network firewall configuration practices in alignment with the CMS ARS and the DISA Security Technical Implementation Guide (STIG) and follow industry best practices.

BR-SEC-FW-3: External Connections to CMS Zones

No connections, services, or requests of any kind may be allowed from external hosts (i.e., external to specific Certification and Accreditation [C&A] boundaries established by CMS) into the Presentation Zone or any other CMS zone , unless the appropriate business justification is made along with documentation of the corresponding risk analysis for the system and environment in CFACTS and complete implementation of compensating information security and privacy controls from the current CMS ARS.

Related CMS ARS Security Controls include: CA-3 - Information Exchange, RA-3 - Risk Assessment, and PL-2 - System Security and Privacy Plans.

Rationale:

CMS does not permit unauthorized access to its systems or data. Interconnection must be formally approved and documented.

BR-SEC-FW-4: Access to Services of the Firewall

No connections, services, or requests of any kind may be allowed to the firewall itself except from the Management Zone unless the appropriate business justification is made along with documentation of the corresponding risk analysis for the system and environment in CFACTS and complete implementation of compensating information security and privacy controls from the current CMS ARS.

CMS permits connections from the firewall itself to other relevant CMS services, such as logging to the Security Zone , when there is appropriate business justification along with documentation of the corresponding risk analysis for the system and environment in CFACTS and complete implementation of compensating information security and privacy controls from the current CMS ARS.

Related: Configuration Management (CM); CMS ARS Security Controls include: CM-6 - Configuration Settings, AC-6 - Least Privilege, and CM-7 - Least Functionality.

Rationale:

In the framework of firewall rules, the firewall itself may be a destination host if it supports features such as remote management or VPN gateway services. This BR is intended to block all traffic to the firewall except from the Management Zone. Therefore, unneeded firewall features—which should also be disabled—such as VPN gateways, are effectively blocked unless there is a justified business need and permitted by CMS.

BR-SEC-FW-5: Filtering Traffic between Zones

All network traffic to or from a zone (Presentation, Application, or Data) must pass through a firewall to enter or leave the zone. These firewalls may be physical or virtual, or implemented by other means (e.g., Security Groups in AWS, Network Security Groups in Microsoft Azure, etc.). Firewalls protecting a given zone must:

• Prevent all traffic between the Presentation, Application, and Data Zones except as explicitly permitted by CMS
• Filter and allow packet inspection of traffic between zones, and entering or exiting from external networks

No connections, services, or requests of any kind may be allowed to enter a CMS zone unless there is appropriate business justification along with documentation of the corresponding risk analysis for the system and environment in CFACTS and complete implementation of compensating information security and privacy controls from the current CMS ARS.

Rationale:

Filtering traffic entering each zone provides protection against unauthorized traffic.

BR-SEC-FW-6: Firewalls Transmit Logs and Notifications to the Security Zone

Firewalls will transmit audit logs, event logs, administrator notifications, and security alarms to the Security Zone. At a minimum, all firewalls and perimeter network devices must produce audit records required by the current CMS ARS; Security Controls AU-2 and AU-3 describe the minimum events to be logged.

Rationale:

Monitoring and analyzing logs and notifications is a function of the Security Zone .

BR-SEC-FW-9: Network Traffic Entering a Zone Must Terminate in That Zone

All network traffic entering a zone through a network firewall must terminate in that zone. The destination within the zone must be a service that receives and processes or transforms the application data carried within the network traffic. The firewall must block any traffic entering the zone that does not terminate at a service within the zone.

Examples of acceptable destinations within a zone include an application server, message bus, or proxy server, as follows:

• An application server that validates and processes transaction requests
• A file transfer server that receives files
• A proxy server that examines, and potentially rewrites, the HTML headers
• A communication server that receives an X.12 request, validates the format and sender, and forwards the request to the next service
• An XML gateway that validates the object
• A management interface used to configure or manage a switch, router, HIDS agent, or other networking device or agent

Examples of unacceptable destinations for network traffic entering a zone include:

• A switch or router that forwards the traffic
• A load balancer that merely inspects HTML headers and cookies, or rewrites the source / destination address or port
• A firewall that permits the network traffic to exit the zone
• A destination outside of the zone
• A destination in any zone , such as a backup server, HIDS agent, or IDS server, unless the source is in the same zone

Please note that compliance with this BR supports the following best practice for network firewall configuration:

A network firewall need only be aware of the address ranges, subnets, and components of the networks directly connected to the firewall’s network interfaces. The firewall would have no firewall rules or routing tables permitting traffic to destinations in address ranges of other networks such as those beyond other adjacent network firewalls.

Although not required, CMS strongly encourages adoption of this best practice for firewall configuration.

Any exceptions to this BR or the recommended best practice require there be an appropriate business justification along with documentation of the corresponding risk analysis for the system and environment in CFACTS and complete implementation of compensating information security and privacy controls from the current CMS ARS.

Please refer to BR-SEC-FW-5: Filtering Traffic between Zones.

Rationale:

This BR supplements the business rule guidance in CMS TRA – Foundation, Business Rules with criteria for network traffic between components of an application in the CMS TRA Multi-Zone Architecture. The CMS TRA Multi-Zone Architecture is designed to separate the components of an application, thus creating multiple points in which network-based transactions may be inspected, challenged, and monitored. Among these points are some components of the CMS application and the CMS network infrastructure, the network zones in which CMS components and data reside, and the network firewalls protecting those zones. By having multiple points between the requester and CMS systems and data, CMS multiplies the complexity of its defenses and deters attackers.

Besides contributing to CMS defenses, compliance with this BR is an important contribution to the architecture’s overall value to CMS, namely, promoting consistency and efficiency through an enterprise view of service sharing, application development and reuse, operations and maintenance, and security services, while encouraging application design to emphasize performance, scalability, high availability, and security in depth.

BR-SEC-FW-10: Impede Attempts to Traverse Network Zones

The network infrastructure of CMS Processing Environments must impede or challenge any network traffic attempting to traverse (i.e., pass through) a zone. Unless explicitly approved by CMS, no authorized network traffic ever enters and or immediately exits a zone without being challenged or transformed by something within the zone as described by BR-SEC-FW-9. Therefore, any network traffic attempting to traverse a zone may be unauthorized. Although all network traffic must be monitored, unauthorized traffic may be discouraged or impeded using one or more of the following mitigation techniques:

• Monitor the network for unusual or unexpected traffic between sources and destinations
• Limit the paths and destinations in the routing tables of network infrastructure devices such as firewalls and routers. Monitor the routing tables for unauthorized changes.
• Avoid using the same Transport Protocol Port Numbers on network firewalls to enter a given zone as used to exit the zone. For example, if a given port number is used to enter the Application Zone from the Presentation Zone, that same port number may not be used to exit the Application Zone and enter the Data Zone. This practice discourages unauthorized traffic from traversing a zone and would force a determined attacker to scan for a path to other zones. Such scanning increases the probability of detecting the attack.
• Avoid configuring a given application to use the same Transport Protocol Port Numbers for traversing between consecutive zones. For example, an application may use one port number between the Presentation and Application Zones but should use a different port number between the Application Zone and Data Zone.
• Use non-standard Transport Protocol Port Numbers whenever possible.

Any mitigation techniques used should be documented in the SSP. Any exceptions to this BR require the appropriate business justification along with documentation of the corresponding risk analysis for the system and environment in CFACTS and complete implementation of compensating information security and privacy controls from the current CMS ARS.

Rationale:

Impeding attempts to traverse network zones helps to discourage or defeat simple network attacks, and to detect misconfigured network devices or unauthorized network scanning. It also helps to defeat or detect malicious code outbound exfiltration attempts.

BR-SEC-FW-11: Utilize Firewalls from Two or More Different Vendors

In CMS data centers, CMS requires using network firewalls from two (2) or more different vendors at the various levels within the network to reduce the possibility of compromising the entire network.

The CMS TRA Multi-Zone Architecture has a natural flow of transactions from external networks to Presentation Zone to Application Zone to Data Zone (and in that sequence). Network firewalls are the gateways at the junctures between each zone. A network firewall at one juncture must be from a different vendor than the firewall at the next juncture in the sequence. This includes the juncture with external networks.

Please refer to BR-SEC-FW-10 - Impede Attempts to Traverse Network Zones .

Related CMS ARS Security Controls include: ARS SC-7 - Boundary Protection.

Rationale:

Employing firewalls from two (2) or more different vendors at the various levels within the network reduces the possibility of compromising the entire network. It reduces the likelihood that both firewalls share the same vulnerability or misconfiguration.

Firewall Administration

The following CMS TRA Security Firewall Administration (SEC-FWA) business rules support the information security and privacy controls cited in the CMS ARS. 

BR-SEC-FWA-1: Administrative Access to Firewalls

All system administration for firewalls must take place either from a local console directly connected to or part of the firewall hardware, or via secure connections from the Security Zone. In addition, CMS ARS Security Control IA-2 requires MFA for privileged user accounts.

Rationale:

It is essential to the security of CMS Processing Environments that only authorized individuals can administer firewalls, and that firewall administration only takes place over protected interfaces intended for firewall administration. Firewall administration is a function of the Security Zone .

BR-SEC-FWA-2: Firewall Implementation

Traffic-filtering network firewalls must not reside on a general-purpose computer or server or make use of a general-purpose operating system. Network firewalls must not use any general-purpose storage capabilities (write-once storage capabilities for recording audit logs are permissible) and must not be capable of executing arbitrary code or applications.

Related: Configuration Management (CM); CMS ARS Security Controls include: CM-7 - Least Functionality.

Rationale:

Firewalls are critical to network operation and security. Implementing firewalls using dedicated and purpose-built hardware, software, and operating systems helps ensure reliable and correct operation of the firewall through the principle of least functionality.

BR-SEC-FWA-3: Disable Non-Firewall Functions

Network firewalls must not implement any services or capabilities other than firewall functions, e.g., DNS services, email services, File Transfer Protocol (FTP) services.

Related: Configuration Management (CM); CMS ARS Security Controls include: CM-6 - Configuration Settings, AC-6 - Least Privilege, and CM-7 - Least Functionality. CMS ARS Security Controls include: CM-6 - Configuration Settings, AC-6 - Least Privilege, and CM-7 - Least Functionality.

Rationale:

Firewalls are critical to network operation and security. Disabling functions unrelated to required firewall functions helps ensure reliable and correct operation of the firewall through the principle of least functionality.

BR-SEC-FWA-4: Firewall Functional Requirements

All firewalls must provide the following functions at a minimum and must restrict the ability to perform these functions to an authorized administrator:

• Performing startup and shutdown
• Creating, deleting, modifying, and viewing information-flow security policy rules that permit or deny information flows
• Creating, deleting, modifying, and viewing administrator profiles
• Modifying and setting threshold for the number of permitted authentication attempt failures
• Modifying and configuring logging parameters, including the definition of auditable events, audit log size limitations, and audit log retention policy
• Restoring authentication capabilities for users who have met or exceeded the threshold for permitted authentication attempt failures
• Enabling and disabling external hosts from communicating with the firewall
• Modifying and setting the time and date
• Archiving, creating, deleting, and emptying the audit trail
• Backing up administrator profiles, information-flow security policy rules, and audit log data where the backup capability is supported by automated tools
• Installing, modifying, or removing software
• Starting and stopping services
• Recovering to the state following the last backup

Related: Configuration Management (CM); CMS ARS Security Controls include: CM-6 - Configuration Settings, AC-6 - Least Privilege, and CM-7 - Least Functionality.

Rationale:

The listed functions are necessary to the proper operation, monitoring, and maintenance of a firewall.

Application Layer Filtering Firewalls and Gateways

Application layer gateway firewalls, also known as proxy-based firewalls, can monitor and filter on the application layer (i.e., layer 7 of the Open Systems Interconnection [OSI] model). They can look deep within the network packets’ content for inconsistencies, invalid or malicious commands, and executable programs. For example, a proxy for the SMTP protocol can be used to detect invalid commands and parameters used for potential attacks. HTTPS application proxies can check for tampering of cookies and invalid character encoding and more.

The guidance in this topic is intended to address all types of Application Layer Filtering (ALF) services. There are many services and products available that perform ALF and support many different protocols (e.g., SMTP, HTTP, and SOAP) and message/document formats and description languages (e.g., XML and JSON). Common examples of ALF services include, but are not limited to, proxy-based firewalls, XML firewalls, and Web Application Firewalls (WAF).

These configuration requirements fall into three categories: General (ALFG), Authentication and Authorization (ALFA), and XML-based Protocol Protection (XMLP), described in the subsequent subtopics of this chapter.

Configuration requirements listed in these subtopics are derived from NIST SP 800-95, Guide to Secure Web Services, and National Security Agency (NSA) Net-Centric Enterprise Services (NCES) Profile of Web Service Security: Simple Object Access Protocol (SOAP) Message Security (WSSE), NSA Profile 20080522.

ALF General Configuration Requirements

Configuration requirements in this subtopic apply to all ALF services processing digitally signed data elements such as, but not limited to, web service messages and XML or JSON documents. They are derived from NSA NCES WSSE, section 4.5 and NIST SP 800-95, section 3.6.

BR-SEC-ALFG-1: Accept Only Enveloped or Detached Signatures

ALF services must accept only digitally signed data elements (e.g., web service messages and XML or JSON documents). ALF services must accept only enveloped or detached signatures.

Rationale:

Digital signatures provide provenance—such as authenticity or origin—and can be used as a measure of integrity (trust).

BR-SEC-ALFG-2: Apply Exclusive Canonicalization

ALF services must be configured to apply only Exclusive Canonicalization with or without comments (Exclusive C14N Canonicalization transform).

BR-SEC-ALFG-3: Expand All Non-Character Entries

ALF services must be configured to expand all non-character entries when parsing a message or document.

BR-SEC-ALFG-4: Protect Against Web Service Attacks

All ALF services must be configured to protect against attacks, including but not limited to, the following types:

• Recursive/oversized payload attacks – Attempts to perform a denial of service against the application service by sending messages designed to overload the parser
• External reference attacks – Attempts to bypass protections by including external references that will be downloaded after the request message / document has been validated but before it is processed by the application
• Routing Detours – Attempts to misdirect a message, causing it to be routed to an unauthorized location or to a non-existent location, creating a denial of service
• Schema poisoning – Supplying a schema with the message / packet / document such that the message validator will use the supplied schema and allow a malicious message / document to be validated without error

All denied requests, protocols, services, destination Internet Protocol addresses, and ports must be logged in a manner compliant with the implementation standards within CMS ARS Security Control SC-7 (e.g., logged information must be available to the CCIC for analysis and alerting).

BR-SEC-ALFG-5: Reject Certain Types of Digital Signatures

All ALF services must be configured to reject digital signatures containing the following:

• Uniform Resource Identifier attributes containing fragment identifiers (these follow a hash mark, as opposed to a query part)
• For XML digital signatures, the MgmtData child element of the KeyInfo element (instead, they should use <xenc:EncryptedKey> and <xenc:DerivedKey> elements)

BR-SEC-XMLG-1: (Retired after TRA 2019R1): Accept Only Enveloped or Detached XML Signatures

BR-SEC-XMLG-2: (Retired after TRA 2019R1): Apply Exclusive Canonicalization

BR-SEC-XMLG-3: (Retired after TRA 2019R1): Expand All Non-Character Entries

BR-SEC-XMLG-4: (Retired after TRA 2019R1): Protect Against Web Service Attacks

BR-SEC-XMLG-5: (Retired after TRA 2019R1): Reject Certain Types of Digital Signatures

ALF Authentication and Authorization Configuration Requirements

Configuration requirements in this subtopic apply to all ALF services using digital signatures to identify servers, applications, or users for the purposes of authentication and/or authorization, or message integrity checking. Logging of authentication results (pass and fail) must comply with the CMS ARS requirements.

BR-SEC-ALFA-1: Authenticate Request Originators

The originators of requests to an ALF service acting as a web proxy must be authenticated using the x.509 standard certificate authority-based authentication. Derived from NSA NCES WSSE, section 4.1.

BR-SEC-ALFA-2: Chain of Identity, Authentication, and Authorization

When serving as intermediary web servers, ALF services must be configured to forward the identity in an X509SubjectName element containing the request originator’s distinguished name and those of all intermediate web servers in the request chain, including their own. This provides a chain of identity, authentication, and authorization from the request originator to the destination web server. Derived from NSA NCES WSSE, section 4.1.

BR-SEC-ALFA-3: Prevent Transformations on Signed Data Elements

ALF services must be configured to prevent the application of XML eXtensible Stylesheet Language Transformation (XSLT) or application-specific transforms on signed data elements. Derived from NSA NCES WSSE, section 4.5.

BR-SEC-XMLAA-1: (Retired after TRA 2019R1): Authenticate Request Originators

BR-SEC-XMLAA-2: (Retired after TRA 2019R1): Chain of Identity, Authentication, and Authorization

BR-SEC-XMLAA-3: (Retired after TRA 2019R1): Prevent Transformations on Signed Data Elements

ALF Protocol Protection Requirements

Configuration requirements in this subtopic apply to all ALF services providing protection mechanisms to servers, applications, or users accessing information using XML-based protocols.

BR-SEC-ALFP-1: Protect Against Attacks on Protocols

All ALF services must be configured to protect against attacks, including but not limit to, the following types against XML-based protocols such as Simple Object Access Protocol (SOAP) intrusion detection, or eXtensible HyperText Markup Language (XHTML) schema validation: Derived from NIST SP 800-95, section 3.6.

• Web Services Description Language (WSDL) scanning – Attempts to retrieve the WSDL of Web services to gain information that may be useful for an attack
• Parameter tampering – Modification of the parameters a Web service expects to receive in an attempt to bypass input validation and gain unauthorized access to some functionality
• Replay attacks – Attempts to resend requests to repeat sensitive transactions
• Structured Query Language injection – Providing specially crafted parameters that will be combined within the Web service to generate a SQL query defined by the attacker
• Buffer overflows – Providing specially crafted protocol parameters that will overload the input buffers of the application and will crash the application service—or potentially allow execution of arbitrary code

All denied requests, protocols, services, destination IP addresses, and ports must be logged.

BR-SEC-ALFP-2: Protocol Headers

All ALF services must be configured to ignore the value of the lower-layer protocol header. Lower-layer protocols used to transport XML-based protocols must be configured to indicate the XML-based protocol type in their header (e.g., SOAPAction in an HTTP request’s header field). Derived from NSA NCES WSSE, section 4.2.

BR-SEC-XMLP-1: (Retired after TRA 2019R1): Protect Against Attacks on XML Protocols

BR-SEC-XMLP-2: (Retired after TRA 2019R1): XML Headers

ALF Service / Management Administration Requirements

The CMS TRA Security ALF Administration / Management (ALFM) configuration requirements in this subtopic apply to all ALF services and support the controls outlined in the CMS ARS.

BR-SEC-ALFM-1: Limit Administrative Access to ALF Services

All system administration for ALF services must take place from a local console either directly connected to or part of the ALF service hardware or via secure connections from the Management Zone.

BR-SEC-ALFM-2: ALF Services Must Not Support General-Purpose Computing

ALF services may be physical or virtual, non-reprogrammable devices. In addition, these services must not contain any general-purpose storage capabilities (write-once storage capabilities for recording audit logs are permissible) and must not have the ability to execute arbitrary code or applications.

BR-SEC-ALFM-3: ALF Service Functions

All ALF services providing inter-zone firewall or IDS/IDP services must provide the following functions at a minimum and must restrict the ability to perform these functions to an authorized administrator:

1. Performing startup and shutdown
2. Creating, deleting, modifying, and viewing information-flow security policy rules that permit, deny, constrain, and manage information flows
3. Creating, deleting, modifying, and viewing administrator profiles and roles
4. Modifying and setting threshold for the number of permitted authentication attempt failures
5. Modifying and configuring logging parameters, including the definition of auditable events, audit log size limitations, and audit log rotation and retention policy
6. Restoring authentication capabilities for users who have been disabled because they met or exceeded the limit for permitted authentication attempt failures
7. Enabling and disabling hosts from communicating with the firewall
8. Archiving, creating, deleting, and emptying the audit trail
9. Backing up administrator profiles, information-flow security policy rules, and audit log data in a secure manner (e.g., encrypted, via management network) where the backup capability is supported by automated tools
10. Installing, patching, modifying, or removing software
11. Starting, stopping, and managing services
12. Recovering to the state following the last backup

BR-SEC-ALFM-4: ALF Service Configuration Must Be Restricted

Changing the ALF service configuration is a privileged activity that must be restricted to authorized administrators.

BR-SEC-ALFM-5: ALF Service Configuration Changes Must Be Logged and Audited

Configuration changes must be logged and audited in a manner compliant with the CMS ARS requirements.

Related CMS ARS controls include: AC-3, AC-4, and SC-7.

BR-SEC-XMLA-1: (Retired after TRA 2019R1): Limit Administrative Access to XML Gateways

BR-SEC-XMLA-2: (Retired after TRA 2019R1): XML Gateways Must Not Support General-Purpose Computing

BR-SEC-XMLA-3: (Retired after TRA 2019R1): XML Gateway Functions

BR-SEC-XMLA-4: (Retired after TRA 2019R1): XML Gateway Configuration Must Be Restricted to Authorized Administrators

BR-SEC-XMLA-5: (Retired after TRA 2019R1): XML Gateway Configuration Changes Must Be Logged and Audited

CMS Cybersecurity Integration Center (CCIC) Integration

Introduction

Background

The Federal Information Security Management Act of 2002 (Public Law [P.L.] 107-347), as amended by the Federal Information Security Modernization Act of 2014 (P.L. 113-283) (FISMA), requires each agency to develop, document, and implement an agency-wide information security program to safeguard information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor (including subcontractor), or other source on behalf of an agency. Agency information security programs apply to all organizations (sources) that have physical or electronic access to a federal agency’s computer systems, networks, or IT infrastructure or use information systems to generate, store, process, or exchange data with a federal agency or on behalf of a federal agency, regardless of whether the data resides on a federal agency or contractor information system. CMS, the Federal Risk and Authorization Management Program (FedRAMP), and NIST have published guidance establishing the minimum security controls for safeguards needed to protect the confidentiality, integrity, and availability of a CMS system and its information.

CMS requires each system developer and maintainer to (1) process, (2) store, (3) facilitate transport of, and (4) host / maintain federal information pursuant to federal, HHS, and CMS Information Security Program policies by following the requirements outlined in this chapter. The term “CCIC” encompasses all CMS Information Security and Privacy Group’s operational programs, including traditional and emerging Security Operations Center roles, tools, and processes associated with these capabilities.

Purpose and Scope

This chapter provides requirements for integrating a FISMA system’s security operations and services capabilities with the CCIC security operations and services capabilities. The requirements include both the high-level requirements and information on locating additional details on relevant requirements.

This chapter supersedes all previous versions of the former CMS Enterprise Security Operations Center (ESOC) Integration Requirements but does not replace or supersede federal information security and privacy requirements, policies, regulations, or standards, including those from FISMA, Department of Homeland Security, HHS, and CMS. This chapter provides additional requirements to strengthen information security and privacy for CMS systems and the Agency. It also includes requirements for implementing the CMS-required security capabilities, including security architecture samples and specific tool requirements.

Most of the business rules in this chapter apply to all systems, regardless of FIPS 199 categorization. This chapter includes additional rules for CMS FISMA systems and data centers supporting CMS when any of the following apply:

1. The FISMA system is categorized as HIGH or MODERATE under FIPS 199. Please refer to NIST SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, and CMS Risk Management Handbook, Risk Assessment (RA), see NIST SP 800-53A, Assessing Security and Privacy Controls in Information Systems and Organizations, RA-2 Security Categorization.or (PDF).
2. Any FISMA system asset is designated by CMS as a High Value Asset (HVA).

A high value asset is an asset used as a mission-critical information resource supporting infrastructure providers / suppliers or partnering organizations. The unauthorized disclosure of, modification / destruction of, or disruption of access to information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

3. The SDM data center houses a FISMA system that is categorized as HIGH or MODERATE under FIPS 199 or is designated by CMS as HVA.

Assumptions and Constraints

In addition to FISMA, requirements set forth in this chapter support the following federal legislation, requirements, policies, regulations, or standards:

• Executive Order 14028, “Improving the Nation’s Cybersecurity”,
• Federal Information Technology Acquisition Reform (Subtitle D of the Carl Levin And Howard P. “Buck” McKeon National Defense Authorization Act For Fiscal Year 2015, Public Law (P.L.) 113-291, Title VII, Subtitle D.
• Cybersecurity Enhancement Act of 2014, P.L. 113-274
• National Cybersecurity Protection Act of 2014, P.L. 113-282
• The Privacy Act of 1974, P.L. 93-579
• E-Government Act of 2002, P.L. 107-347
• Office of Management and Budget Memorandum Circular No. A-130 (Revised). and Memoranda: M-02-01, M-08-05, M-16-04, M-17-09, M-17-12, M-19-03, M-19-17, M-19-26, M-20-32, M-21-31, and M-25-04.

As required by federal law, each SDM must:

• Follow FISMA, NIST, and other federal guidance in the CMS Policies and Guidance and Federal Policies and Guidance pages (including the CMS Acceptable Risk Safeguards and Risk Management Handbook), the CMS TRA guidance, and the CMS Target Life Cycle (TLC) processes and procedures. Any technologies described within this chapter or the associated onboarding documents must be implemented in accordance with the CMS ARS, the CMS TRA, and the TLC.
• Obtain approval by the CMS TRB, which includes representation from ISPG, for any variance from this guidance. Failure to follow the requirements outlined in this chapter may result in a Plan of Action and Milestones finding and/or impact ATO eligibility.
• Procure at least one CMSNet connection from the SDM to the CCIC and deploy the necessary hardware and software for the required information security and privacy capabilities. This includes infrastructure such as space, power, and cooling. CMS recommends the CMSNet connection capacity be 10Mbps or larger.
• Accept responsibility for internal security monitoring, response, and reporting for information security and privacy incidents (and breaches) within SDM data center(s), including operational changes necessary to support the introduction and operation of the required information security capabilities and services. Alternatively, accept that CCIC performs security monitoring for the system after onboarding.
• Provide technically qualified staff for operations and maintenance of the required information security capabilities and services compliant with roles and responsibilities defined in the CMS Information System Security and Privacy Policy.
• Follow appropriate CCIC standard operating procedures, capability Onboarding Guides and other CMS documentation to support alignment with CCIC requirements. This includes supporting federal Information Security Continuous Monitoring (ISCM) required capabilities, such as hardware asset management (HWAM), software asset management (SWAM), vulnerability management (VUL), and configuration settings management (CSM).
• For information security capabilities and services not addressed within this chapter, SDMs must provide the associated (real-time) continuous monitoring feeds as specified in NIST SP 800-137, Information Security Continuous Monitoring [ISCM] for Federal Information Systems and Organizations, by the DHS Continuous Diagnostics and Mitigation Program or other emerging federal requirements. CMS ISPG will assist and provide guidance to the SDM in deploying CCIC tools, collecting feeds, and integrating data sources.

Within CMS, compliance with FedRAMP alone for cloud deployments is the first step (i.e., an initial baseline) in meeting CMS’s confidentiality, integrity, and availability requirements. Cloud service providers are required to meet the technical and functional requirements stated in this chapter, either through log and event information provided by cloud components (e.g., infrastructure, platforms) in a manner that meets these requirements explicitly or though compensating capabilities (e.g., applications capable of providing the information needed) deployed on the hosted platform(s) or within the hosted application(s). In situations where requirements cannot be met, the FISMA system business owner is responsible for documenting the limitations and defining the resulting residual risk in the Information System Risk Assessment. All CMS FISMA systems and applications deployed on a CSP service must have a CMS-issued ATO. For more on CMS’s security requirements for cloud implementations, please refer to Risk Management Handbook Volume III Standard 3.2, CMS Cloud Computing Standard and IS2P2 policies on cloud computing.

Intended Audience

The intended audience of this chapter consists of the CMS SDMs, including all functional teams, FISMA system staff, or other working groups, that operate and/or maintain the information security and privacy data gathering capabilities. This includes technical staff responsible for maintaining the CMS networks and systems that reside within the networks. Information System Security Officers, Cyber Risk Advisors (CRA), and organizational Data Guardians understand the security and privacy drivers for the business rules in this chapter and can help as a liaison between the CCIC and the CMS SDMs. For the purpose of CDM, the SDM role may include the System Administrators, Application Administrators and Developers, and/or Database Administrators.

Integration with CCIC is a shared responsibility for everyone involved with the design, operation, or maintenance of CMS IT systems and data. Although this section is primarily intended for the audience associated with this chapter, it is relevant to audiences of other parts of the CMS TRA. All readers of any other CMS TRA chapter should refer to this section for additional responsibilities associated with CCIC integration.

Key Roles Supporting CCIC Integration Table defines key responsibilities for major IT roles to support integration with CCIC.

The table Primary and Supporting Roles for the Cyber Security Operations/ Risk Management Section of the CCIC, lists the primary and supporting roles for each topic of this CCIC Integration chapter.

Overview

CMS ISPG established the CCIC to deliver a number of important Agency-wide security services designed to protect CMS systems and provide adequate, risk-based, cost-effective cybersecurity. These services help ensure the confidentiality, integrity, and availability of information processed, stored, or transmitted by CMS systems.

The services offered include vulnerability assessment and management as provided by the Vulnerability Assessment Team (VAT), security engineering, incident management, forensics and malware analysis, cyber threat intelligence, and penetration testing.

Historically, the VAT has focused primarily on vulnerability scanning and detection, vulnerability assessment, vulnerability management, and vulnerability reporting. In addition to those services, the VAT also supports both the Division of Implementation and Reporting (DIR) and continuous diagnostics and mitigation (CDM) operations for ISPG. VAT supports DIR by providing:

• Project management support for deployment of tools and capabilities that support VAT services
• Consulting and architectural guidance
• Reporting and monitoring
• Process and procedure optimization
• Deployment and administration of tools that support VAT services

For CDM operations, the VAT:

• Provides vulnerability data
• Reduces CMS’s exploitable attack surface
• Assists CMS with responding quickly to new and emerging vulnerabilities

For more information please contact the VAT team at VAT@cms.hhs.gov

The CCIC supports and provides a variety of enterprise-level information security capabilities and services for CMS by:

• Maintaining an independent and enterprise-wide information security operations perspective
• Centrally coordinating CMS enterprise information security operations
• Centrally coordinating and disseminating CMS-applicable information security and privacy threat intelligence
• Managing aggregation, correlation, and reporting to meet enterprise information security and privacy controls and offer common controls
• Providing integration requirements for implementing CCIC technical requirements to ensure a more fully integrated information security environment for the entire enterprise

The CCIC is not a replacement for, nor intended to remove the requirement for, the SDM’s own security policy, operations personnel, procedures, and responsibilities. The CCIC extends the Defense-in-Depth strategy by providing an additional layer that provides monitoring, response, and notification across the entirety of CMS. This additional layer augments and enhances the security controls and capabilities for the FISMA system and SDM.

The SDM maintains responsibility for appropriately staffing and implementing its information security and privacy program to meet CMS requirements.

Base CCIC Capabilities

The base CCIC capabilities support the following strategic areas:

• Cybersecurity Operations / Risk Management – Capabilities associated with the management of risk, incidents, and operations. This includes advanced analytics and security engineering.
• ISCM / PCM – Capabilities associated with ISCM / PCM as defined by NIST and OMB under the DHS Continuous Diagnostics and Mitigation (CDM) Program. This includes ongoing assessment and authorization.
• Perimeter Protections – Capabilities associated with information security and privacy protections at the external boundary and enclave perimeter.
• Lateral and Endpoint Protections – Capabilities associated with information security and privacy protections internal to an enclave (e.g., at the endpoint or a device within the enclave) and insider threats. This includes penetration of the endpoint (e.g., phishing).

Reference CCIC Integration Architecture

CMS does require similar implementations if sensitive data, such as Personally Identifiable Information, Protected Health Information, or Federal Tax Information, are used within non-production environments such as test and development.

The following recommended implementation details should be noted:

• One or more service architectures exist within each FISMA system enclave. (A “secure enclave” is defined as one or more segments of an internal and/or isolated network consisting of a common set of security policies.)
• One or more FISMA systems exist within each data center enclave.
• One or more user enclaves may exist within the FISMA system, across multiple FISMA systems, within the data center, or external to the data center.
• Monitored perimeters exist between enclaves and boundaries. (Boundary is defined as the separation point between one or more network segments/enclaves.)
• The Trusted Internet Connection 3.0 reference architecture is now required for deployments.
• Secured enclaves host the SDM’s Supporting SOC and the SOC tool suite.
• CMSNet is the secure connection for sharing information security and privacy information with CCIC. (CMS recommends that the CMSNet connection capacity be 10Mbps or larger.)
• A CMS TRA- and TLC-compliant, tiered architecture is used.
• Strategically placed sensor components for scanning of all assets via network-based sensors, capability relays, information collectors, or local servers include:
  • Vulnerability scanning tool
  • Configuration setting scanning tool
  • Software asset scanning tool
  • Hardware asset scanning tool
• Log collection and correlation permits the CCIC-based deployment of the enterprise logging tool to inter-operate with the FISMA system’s (or SDM’s) Security Information and Event Management capability.
• Network taps provide full packet capture, malware detection and capture, for Intrusion Detection Systems / Intrusion Prevention Systems (IDS / IPS).
• Layer-3 configuration files are analyzed for vulnerabilities and misconfigurations via a contextual risk management and threat identification application. (Layer 3 (Network Layer) handles packet forwarding and routing.)
• Other ISCM / PCM information is collected and shared as needed with CCIC for CyberScope and other program requirements.
• Endpoint protection is deployed on all applicable assets for malware / virus detection to support forensic acquisition and to share indicators of compromise (IOC).

Advanced CCIC Capabilities and Services

The CCIC provides a variety of security capabilities and services to fulfill its mission of monitoring for and responding to information security and privacy incidents and breaches. This subtopic describes the advanced CCIC capabilities and services available to the FISMA system and SDM. These capabilities and services help to facilitate the successful deployment of the required capabilities. Security capabilities and services also referenced in HHS OCIO Rules of Engagement for Security Monitoring and Collaborative Systems.

The following CCIC services are available to the SDM:

• Incident Management Team (IMT). Incident management, through an IMT, serves as the focus for all incident handling, across all information response teams (IRT) within CMS. See Incident Management below for additional information on the IRT.
• Forensic & Malware Analysis Team (FMAT). The Advanced Investigation service oversees the handling of any incidents that require digital forensics and malware analysis on affected system(s). See Advanced Investigation for additional information on FMAT.
• Information Sharing and Cyber Threat Intel (IS&CTI). The IS&CTI service improves the effectiveness of CMS information security and privacy. See Information Sharing and Cyber Threat Intelligence for additional information on IS&CTI.
• Penetration Testing. CMS established a penetration testing capability within ISPG to proactively assess the susceptibility of CMS systems, personnel, and facilities to attack. See Penetration Testing below for additional information on penetration testing.
• Security Architecture and Engineering (SAE). The SAE service provides architecture and design of information security and privacy solutions across the CMS enterprise, including government and contractor facilities. See Security Architecture and Engineering below for additional information on.

Cyber Security Operations / Risk Management

Risk Management

This subtopic provides the risk management requirements associated with cyber security operations. These requirements specify the following capabilities:

• Obtaining an ATO for the FISMA system
• Assessment of information security and privacy risks

The business rules within this topic apply to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-01: Security Authorization of Systems

The business owner / information system owner / SDM must:

• Categorize the FISMA system in accordance with FIPS 199, and document the system attributes used to identify PII, PHI, and HVAs
• Develop, periodically review, and maintain information security, privacy, and continuous monitoring plans (NIST, SP 800-18 Rev. 2, Developing Security , Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems) in accordance with CMS ARS-defined transitional conditions (including major system changes and data calls following an increased threat level).
• Implement and maintain information security and privacy controls as required by the CMS ARS and the FISMA system information security and privacy plans
• Ensure all personnel meet information security and privacy requirements within the HHS Information System Security and Privacy Policy and CMS IS2P2 policies for:
  • Role (See Roles and Responsibilities, CMS IS2P2.)
  • Role-based training (RBT) (See CMS Training and Awareness)
• Support the authorization of the FISMA system by implementing the controls, completing required activities, supplying information, and documenting the details in cybersecurity and privacy artifacts required under the CMS Security Assessment and Authorization Process
• Manage system interconnections in compliance with CMS-ISA policies governing information sharing and exchange as defined by HHS, CMS, and other applicable information-sharing agreements

For transaction-based FISMA systems, the business owner / information system owner / SDM must:

• Implement and maintain a transaction recovery system(s) appropriate for the CMS mission or business function

For FISMA systems categorized under FIPS 199 as MODERATE or HIGH, the business owner / information system owner / SDM must:

• Establish and maintain alternate processing and storage site agreements appropriate for the CMS mission or business function

For FISMA systems categorized under FIPS 199 as HIGH, the business owner / information system owner / SDM must:

• Develop and maintain IT contingency plans appropriate for the CMS mission or business function:
  • Ensure coordination with organizational elements responsible for related plans
  • Ensure processes and procedures prevent the unauthorized removal of maintenance equipment / media

For FISMA systems categorized under High Value Assets, the business owner / information system owner / SDM must:

• Verify system attributes
• Participate in RVAs
• Complete additional monitoring and reporting requirements as defined by HHS and within OMB M-19-03

Rationale:

Proper understanding of a system’s value to CMS as an asset helps CMS, the SDM, and the CCIC properly prioritize response and remediation activities.

Related CMS ARS Security Controls include: CA-1 - Policy and Procedures, CA-2 - Control Assessments, CA-3 - Information Exchange, CA-3(6) - Supplemental: Transfer Authorizations, RA-3 - Risk Assessment, RA-8 - Privacy Impact Assessments, SA-1 - Policy and Procedures, SA-4 - Acquisition Process, SA-9 - External System Services, PT-3 - Personally Identifiable Information Processing Purposes, RA-2 - Security Categorization, AT-3 - Role-Based Training, AC-3(9) - Supplemental: Controlled Release, AC-21 - Information Sharing, CP-2 - Contingency Plan, MA-2 - Controlled Maintenance, and MA-3 - Maintenance Tools.

BR-CCIC-02: Assessment of Information Security and Privacy Risks

The business owner / information system owner / SDM must:

• Ensure security impact is identified:
  • Conduct a Security Impact Analysis (SIA) at every change to an existing system and on introduction of a new system
• Ensure protection of PII:
  • Conduct a Privacy Threshold Analysis (PTA)
  • Conduct an initial Privacy Impact Assessment (PIA) and recurring PIA reviews
  • Address and mitigate the risks identified
  • Update the PIA throughout the TLC process
  • Identify PHI and FTI and apply applicable controls
• Integrate with CCIC information security capabilities and services:
  • Ensure coordination with the CMS Chief Information Security Officer (CISO), Senior Official on Privacy (SOP), business owner(s), ISSO(s), and other stakeholders
  • Provide support for automated control assessment as defined by CMS and the FISMA system’s security and privacy plan(s
  • Configuration setting management
  • Vulnerability management
  • Asset inventory management
• Conduct independent risk assessments on the FISMA system documenting the results (Assessment processes and procedures are defined under NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments, and NIST SP 800-53A, Assessing Security and Privacy Controls in Information Systems and Organizations.)
• Evaluate level of risk periodically and in accordance with CMS ARS-defined transitional conditions: (including major system changes and data calls following an increased threat level)
  • Notify CMS stakeholders when the risk is found to exceed organizationally defined thresholds
  • Update information security and privacy plans to address changes in risk, mitigations, and compensating controls

For FISMA systems categorized under FIPS 199 as MODERATE or HIGH, the business owner / information system owner / SDM must:

Perform coordinated contingency testing and/or exercises with organizational elements responsible for related plans

For FISMA systems categorized under FIPS 199 as HIGH, the business owner / information system owner / SDM must:

Employ automated mechanisms to schedule, conduct, and document required maintenance and repairs

Maintain up-to-date, accurate, and complete records of all maintenance and repair actions needed, in progress, and/or completed (including both repair / preventive maintenance on hardware and patching/reconfiguring on software)

Rationale:

Proper assessment of a system’s risk helps the CMS CISO, SOP, AO, SDM, and CCIC properly prioritize response and remediation activities. Automated mechanisms can be leveraged to improve overall FISMA system operational efficiency.

Related CMS ARS Security Controls include: CA-1 - Policy and Procedures, CA-2 - Control Assessments, CA-3 - Information Exchange, CA-3(6) - Supplemental: Transfer Authorizations, CA-7 - Continuous Monitoring, CA-7(4) - Risk Monitoring, RA-3 - Risk Assessment, RA-8 - Privacy Impact Assessments, SA-1 - Policy and Procedures, SA-4 - Acquisition Process, SA-9 - External System Services, SI-2 - Flaw Remediation, SI-4 - System Monitoring, MA-2(2) - Automated Maintenance Activities, , CM-6 - Configuration Settings, CM-7 - Least Functionality, CM-8 - Information System Component Inventory, PT-3 - Personally Identifiable Information Processing Purposes, PT-6(1) - Routine Uses, RA-8 - Privacy Impact Assessments, and RA-5 - Vulnerability Monitoring and Scanning.

Incident Management

The CMS Incident Management Team coordinates all functions of incident handling and response across CMS’s incident response (IR) teams. In accordance with the CMS IS2P2 Roles and Responsibilities requirements, the FISMA system’s IRT supports CMS’s Security Operations team, which is integrated into the CCIC. The CMS IS2P2 defines the security operations and incident response organizational structure for the CMS enterprise. The FISMA system SOC/IRT operates under the direction and authority of the ISSO and Business Owner /ISO.

A primary responsibility of the CCIC’s Security Operations team is coordinating incident management across the CMS enterprise. The CCIC IMT provides an effective incident handling and response capability by working with the Marketplace SOC, the FISMA System SOC(s), and other IR external organizations. The CCIC provides CMS leadership with up-to-date information (i.e., situational awareness) regarding the status of all security and privacy incidents (and breaches).

The business rule within this subtopic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-03: Onsite Incident Response Team

The Onsite Incident Response Team must consist of technically qualified staff, including trained information security and privacy personnel, to fulfill the roles and responsibilities of the IRT. Small SDMs may choose to defer part or all required capabilities to the CCIC via an appropriate Memorandum of Understanding (MOU) / Memorandum of Agreement (MOA), and by leveraging the CCIC Incident Response Plan. Please consult the RMH for guidance and templates in the Information Security Library on CMS.gov. Otherwise, please request assistance by sending an email to cisso@cms.hhs.gov.

The SDM must:

• Provide an IRT to respond when a security or privacy incident affects its IT system:
  • Ensure responses are coordinated with the CCIC IMT
• Be responsible for internal security monitoring, response, and reporting for information security and privacy incidents within the SDM data center, including all operational changes
• Develop, maintain, and test organizational-level IR plans, processes, and procedures as required by the CMS ARS:
  • Ensure processes and procedures are in line with CCIC-provided workflows for properly escalating incidents with predefined criteria, thresholds, and contacts
  • Include relevant point of contact (POC) and Office of Information & Regulatory Affairs membership information
  • Ensure incident response plan(s) are provided electronically to the CMS CISO, SOP, and the CCIC
• Provide incident response training for the IRT

The SDM IRT must:

• Serve as the on-site incident response authority for information security and privacy incident reporting and tracking
• Coordinate IR activities with the CCIC and the SDM’s ISSO:
  • Assist in information gathering, forensics, response, and reporting activities
  • Respond to advisories, requests, or directives issued by the CCIC
  • Participate in CMS-led incident response and Playbook tabletop / training exercises
• Provide timely responses to informational requests for SDM security status and posture information

(A timely response is a response within a defined response window associated with the threat level of the security violation. While a response window is typically 24 to 72 hours, the duration is at the discretion of the CMS CISO.)

• Provide technical support and advice for incident handling, impact assessment, and technical system management, including actions taken should standard operating procedures not cover the circumstances
• Serve as the focal point for reporting, monitoring, and tracking to closure of reported information security and privacy incidents:
  • Report IT information security and privacy incidents and breaches within required timeframes per the Risk Management Handbook Chapter 8: Incident Response (IR)
  • Update the incident ticketing system, as required
• Small SDMs may choose to leverage one or more of the CCIC-provided IR-related services:
  • Network Security Monitoring service
  • FMAT service
  • IS&CIT service

Rationale:

The SDM onsite IRT, which acts as a subcomponent of the CCIC IMT, serves as the focal point for reporting, monitoring, and tracking to closure of reported information security and privacy incidents.

Related CMS ARS Security Controls include: IR-05 - (Security) Incident Response, IR-8 - Incident Response Plan, IR-8(1) - Breaches, CA-2 - Control Assessments, AT-2 - Literacy Training and Awareness, AT-3 - Role Based Training, PL-4 - Rules of Behavior, CA-7 - Continuous Monitoring, CA-7(4) - Risk Monitoring, and SI-4 - System Monitoring.

SOC Management

The CCIC uses a variety of security capabilities to monitor, detect, and respond to cybersecurity and privacy incidents and breaches. This subtopic provides the business rules associated with capability implementation within each Supporting SOC operational environment to ensure interoperability with the CCIC (a Supporting SOC is the unit that provides SOC capabilities for the FISMA system / SDM in coordination with the CCIC).

The FISMA system and SDM will work with the CCIC to integrate all required security tools and functional requirements identified in this chapter as part of a unified architecture.

SOC management ensures:

• Interoperability among information security and privacy applications, utilities, and tools implemented within the FISMA system / SDM Supporting SOC and the CCIC
• Timely response to CMS requests related to IOCs, data calls, incident or breach investigations, and reporting
• Relevant privacy controls are addressed to account for sensitive data that may leak into the analysis process

The business rules within this subtopic apply to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-04: Local Secure Enclave to Support CCIC Capabilities

The SDM must:

• Provide oversight, monitoring, and incident response capabilities within the local data center:
  • Audit and report physical and/or logical access to the equipment
• Provide and maintain a secured, separate enclave (i.e., create and maintain the Security Zone) of networks, systems, and devices to implement the CMS information security and privacy functionality, including access control mechanisms, tools, tool sensors (collectors), data aggregators, and data (exceptions must be documented and authorized as a deviation) that assures:
• Physical / logical separation from other SDM networks (including production) and all non-CMS data center operations and security subnets
  • Required boundary protection mechanisms (e.g., IDS / IPS, packet inspection firewalls, dynamic execution environments (also known as detonation chambers), including technical capability requirements specified in CCIC Perimeter Protections.
  • Secure (i.e., encrypted) connectivity to the CCIC via the CMSNet connection
  • Secure connectivity into the enclave for agents (including devices) used to collect required logs and data feeds operating outside the enclave
• Provide a physical / logical environment supporting CCIC-required and managed information security and privacy capabilities:
  • Rack space, cabling, connectivity, and appropriate environmental support for systems, appliances, and devices or host space and connectivity for virtualized systems, appliances, and devices
  • Physical separation secured against unauthorized access, either by a dedicated cage or by use of a separate, dedicated room / rack (for service providers)
  • Physical and/or logical access limited to authorized individuals (e.g., SDM security, SDM operations personnel) with authorization for access managed by the ISSO and CMS
  • Availability on a 24/7/365 basis per CMS and federal requirements
• Provide a capability environment supporting CCIC-required and managed information security and privacy capabilities:
  • Event management (e.g., SIEM)
  • Incident management and response
  • Forensics and malware analysis
  • IS&CTI

Rationale:

The SDM’s secure enclave provides a protected subnet that houses applications and tools for protecting applications and systems deployed within the SDM’s data center(s). The secure enclave is the focal point for providing information security and privacy capabilities across the CMS portion of the SDM’s enterprise.

Each SDM is also responsible for maintaining appropriate security and access control for all secure enclaves/boundaries and for implementing the appropriate tools and technologies to meet CMS and federal requirements. Information sharing between the CCIC and the SDM secure enclave / boundary must use the CMSNet network and be encrypted via an IPSec VPN tunnel to maintain confidentiality and integrity of the data in transit. The CMS ARS directs that encryption algorithms in support of IPSec tunnels must meet or exceed CMS requirements (i.e., be a FIPS 140-2 or FIPS 140-3 validated module).

Related CMS ARS Security Controls include: PL-8 - Security and Privacy Architectures, SA-8 - Security and Privacy Engineering Principles, SA-17 - Developer Security and Privacy Architecture and Design, SC-3 - Security Function Isolation (with enhancements), SC-39 - Process Isolation, AC-2 - Account Management, AC-6 - Least Privilege (with enhancements), AU-2 - Event Logging, AU-9 - Protection of Audit Information, PE-3 - Physical Access Control, PE-6 - Monitoring Physical Access, and SC-13 - Cryptographic Protection.

BR-CCIC-05: Interoperability with CCIC

The SDM must:

• Provide bandwidth necessary to ensure security- and privacy-relevant data are not:
  • Truncated or lost during transit
  • Degraded before aggregation and use by the CCIC’s SIEM
• Ensure information security and operations staff are adequately and appropriately trained in: (See HHS Memorandum, Requirements for Role-Based Training of Personnel with Significant Security Responsibilities[MT15] )[JD16] 
  • Incident management and response
  • Security operations (detection and analysis)
  • Malware analysis (both static and dynamic) and digital forensics
• Implement security capabilities identified by vendor name / functional requirement within the timeframes defined by CMS or other federal mandate:
  • Procure, implement, and perform O&M on the required information security and privacy tools and platforms supporting the required information security and privacy tools
  • Implement the required information security and privacy tools in a manner and using an architecture as required by information security and privacy policy
• Provide authorized personnel within ISPG with administrative access to information security and privacy tools on an as-needed basis for tuning and policy changes:
  • SDM tool administrators and analysts retain responsibility for the routine O&M of the system.
• Provide the CCIC with a service account with appropriate administrative privileges (i.e., membership in the enterprise logging tools’ administration group) on each of the SDM’s Indexers to facilitate the CCIC Search Head’s identifying the SDM Indexer(s) as a search peer. (Creating the search peer relationship between the SDM Indexers and the CCIC Search Heads is a one-way share. Although the analysts at the CCIC can access peered data stored at the SDMs, the analysts at the SDMs cannot access any data stored at the CCIC.)

Rationale:

The SDM’s secure enclave must be interconnected with the CCIC to support its oversight and enterprise-wide responsibilities. This includes providing the CCIC with the ability to perform ad hoc risk evaluations in an evolving threat environment. Although CMS subject matter experts (SME) could access the Supporting SOC configuration files when needed, the FISMA system / SDM tool administrators and analysts retain responsibility for the routine O&M of the system and data sources protecting CMS IT assets.

The SDM is providing CCIC staff with appropriate privileged / administrative access to support interoperability with the CCIC capabilities. This includes the ability to modify rule sets and tool-based policies when needed. (To remain effective, information security and privacy capabilities must be constantly tuned to meet threats and priorities at the CMS Enterprise level. Privileged / administrative access is required to facilitate such tuning. Examples include updating / adding detection rules based on changing IOCs, adjusting defined configuration baselines, and implementing appropriate threat protections.)

In addition to the specific product-based security- and privacy-related capabilities defined under the CMS security architecture and implemented by the CCIC, FISMA system and SDM security analysts may implement other proprietary and open source tools to provide additional capabilities that support both detection and incident investigation. Any findings produced by these tools during an investigation must be made available to and fully usable by the CCIC.

Related CMS ARS Security Controls include: PL-8 - Security and Privacy Architecture, SA-8 - Security and Privacy Engineering Principles, SA-17 - Developer Security and Privacy Architecture and Design, AT-3 - Role-Based Training, PS-3(3) - Supplemental: Information Requiring Special Protective Measures, AT-2 - Literacy Training and Awareness, AT-3 - Role-Based Training, PL-4 - Rules of Behavior, IR-8 - Incident Response Plan, and IR-8(1) - Breaches.

BR-CCIC-06: Timely Response to CCIC Requests

The FISMA system business owner must:

• Appoint an ISSO as the official POC for CMS security data calls
• Notify the CCIC within thirty (30) days of a change of ISSO (CA-2)

The ISSO must:

• Update POC, network architecture (including topology maps), IP address ranges, infrastructure updates, and security documentation for the systems the ISSO and/or CRA operate on behalf of CMS. The ISSO and/or CRA must:
  • Use CFACTS to record the changes
  • Complete updates within the timeframes defined within the CMS ARS
  • Update volatile information, such as network architecture (e.g., topology maps), no less often than once every thirty (30) days
  • Provide a full list of subnets no less often than once every ninety (90) days to support vulnerability scanning

The SDM must:

• Notify the CCIC of significant changes to architecture, security posture, or other items that could cause degradation or unexpected results in security monitoring, detection, response, and mitigation activities prior to making a change
• Notify the CCIC of subnet changes (additions or deletions) within 24 hours of making the change
• Maintain and provide changes to the system accounts required for credentialed scanning by tools used by the CCIC at least two (2) weeks before the passwords expire or when other changes to the accounts are needed:
  • Changes to the accounts must be communicated to the CCIC using out-of-band channels and techniques meeting and exceeding CMS encryption requirements (a FIPS 140-2 or FIPS 140-3 validated module)
• Provide timely responses to information requests for SDM security status and posture information. A timely response is a response within a defined response window associated with the threat level of the security violation. Although a response window is typically 24 to 72 hours, the duration is at the discretion of the CMS CISO.
• Adhere to response times associated with information security and privacy incidents and breaches, and must follow CMS-defined timeframes that are dependent on:
  • Assigned severity of the incident or breach
  • Nature and scope of the incident or breach
• Report FISMA system information security and privacy incidents and breaches to CCIC and HHS CSIRC as required by federal law, regulations, mandates, and directives, following the RMH. For more specifics on incident reporting and response, please refer to:
  • IS2P2, Section 3.4
  • NIST SP 800-61, Computer Security Incident Handling Guide
  • HHS-OCIO, Policy for Information Technology (IT) Security and Privacy Incident Reporting and Response
  • RMH Chapter 8: Incident Response
• Respond to information requests, which may include, but are not limited to:
  • Hardware / software patch implementation levels
  • Implementation status for specific IT security- and privacy-related updates
  • System / infrastructure inventories and configurations (including components and software)
  • Specific network traffic levels
  • Security and privacy specific metrics

Rationale:

The SDM’s response to CCIC data calls must support a dynamically changing environment. This requires the ability to respond to ad hoc risk evaluations within the evolving threat environment.

A frequent issue reported by the CCIC is out-of-date contact information. This has resulted in delays when initiating further investigation of a potential incident or responding to a confirmed incident. A second issue is alerts generated as the result of a planned / authorized change. By properly maintaining POCs in CFACTS, many of these false positives can be avoided.

Information sharing between the CCIC and the SDM secure enclave / boundary must use the CMSNet network.

Related CMS ARS Security Controls include: IR-05 - (Security) Incident Response, AC - Access Control family, AT-2 - Literacy Training and Awareness, AT-3 - Role-Based Training, PL-4 - Rules of Behavior, CA-2 - Control Assessments, CA-7 - Continuous Monitoring, CA-7(4) - Risk Monitoring, CM - Configuration Management family, MA - System Maintenance family, PE - Physical and Environmental Protection, RA-5 - Vulnerability Monitoring and Scanning, RA-5(11) - Public Disclosure Program, RA-7 - Risk response, IR-8 - Incident Response Plan, IR-8(1) - Breaches, SC-7 - Boundary Protection, SC-13 - Cryptographic Protection, SI-2 - Flaw Remediation, SI-3 - Malicious Code Protection, SI-4 - System Monitoring, and SI-5 - Security Alerts, Advisories, and Directives.

Data Feed and Log Integration

CMS’s ISPG maintains an enterprise SIEM capability to meet HHS and federal security information logging and analysis requirements, support incident detection and response capabilities, and assist in meeting reporting requirements.

While network-based activity has long been a primary source of monitoring information associated with malicious activity, changes to both advanced threats and industry best practices require a more comprehensive monitoring approach. To address these changing threats, continuous monitoring will supplement CMS’s ability to quickly and efficiently detect security and privacy breaches and insider threats. Please refer to NIST SP 800-137, Information Security Continuous Monitoring for Federal Information Systems and Organizations.

CMS has implemented an enterprise-level security information and event management (SIEM) platform as the data backbone for security operations within both CMS and the CISA Continuous Diagnostics and Mitigation (CDM) Program. This platform collects, aggregates, correlates, and analyzes logs and event information within each SDM from sensors used to monitor network and host activity into a unified, operational intelligence platform.

The business rule within this subtopic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-07: Local Security Information and Event Management Capability

All SDMs must deploy a SIEM toolset compatible with the CMS enterprise SIEM platform which allows the SDM to capture file, process, registry, service, and thread activities on a per host, server, and network basis anywhere within the SDM network used to support CMS. This approach allows the CCIC or CDM team to submit queries to the SDM’s SIEM for analysis and reduces the information returned to the query response. The CCIC can search through the data at all SDMs without having to copy this same data to the CCIC. For information on the requirements for integrating the SDM SIEM with the CMS enterprise SIEM platform and CDM toolset, send email to ISPG_Logs_Onboarding@cms.hhs.gov.

The SDM must:

• Deploy an enterprise logging tool, such as Splunk or equivalent to provide a local SIEM capability:
• The product may be used (a) if the product provides native capabilities for correlation and contextualization of detected suspect activities from the set of logs and data sources being consumed by the tool, and (b) is fully compatible with the CCIC enterprise SIEM platform deployment:
  • Full data integration – Data generated by this product can be aggregated into the CCIC enterprise SIEM platform for analysis.
  • No loss of data integrity – Data forwarded to the CCIC enterprise SIEM platform is not modified or truncated.
  • Raw format is available when needed.
• Collaborate with the CCIC to ensure the SDM’s current and planned infrastructure:
  • Integrates with the CMS federated enterprise logging tool deployment
  • Conforms to the CMS enterprise information security architecture
• Provide CCIC with a notification within 30 days when a new data source becomes active to ensure the CCIC enterprise SIEM platform instance is receiving the most up-to-date events

SIEMs deployed within the SDM must:

• Support encryption using FIPS 140-2 or FIPS 140-3 validated modules of all communications, when supported, between the implemented SDM SIEM and any applications, systems, servers, and other monitoring and analysis tools, to protect against the spillage of sensitive information / data
• Run automated, customizable reports in accordance with ISPG and federal reporting requirements
• Generate alerts based on triggers and/or signatures that are:
  • Customized / modified
  • Generated / implemented automatically from authoritative external sources (e.g., vendors and other federal agencies)
  • Integrated automatically with ticketing or workflow solutions deployed within the SDM data center(s) to facilitate remediation activities
• Serve as a data source ingestible by the locally deployed enterprise SIEM platform, such as:
  • Processed data
  • Generated alerts, including the captured data artifacts (raw data) from which the alert was generated without alterations of the data and within the retention limits established by federal, departmental, and agency logging requirements and policies.

Current CMS policy (AU-11) requires retention of online records (event data) for 90 days and archiving of older records for no less than one year. Retention periods may be customized by the SDM and defined within the SSP.

• Support sharing of processed data through a standardized event format or an application programming interface in a manner that facilitates sharing with:
  • External collection and analysis application(s), such as another SIEM
  • External organizations, another federal agency, or even another SDM
• Be configured to send unparsed data directly from hosts and sensors via if applicable, the enterprise logging tool’s universal forwarders or syslog:
  • Data should not be forwarded from any other analysis or logging tool, except in the case of syslog aggregators.
  • Communications between enterprise logging system endpoints (forwarders, indexers) must be encrypted using the encryption feature built into the enterprise logging system tool.
  • The anonymization of field data capability must be enabled for any sources containing PII.
  • Communications must be implemented using FIPS 140-2 or FIPS 140-3 validated modules to protect against the spillage of sensitive information/data:
    • Between local enterprise logging system components
    • Between SDM enterprise logging system instances and the enterprise logging system instance at the CCIC
    • Between data sources outside of the SDM enterprise logging tools supporting encrypted communications and the local enterprise logging tools
  • Signed certificates used within the enterprise logging system must come from the CMS Certificate Authority (CA). Self-signed certificates, such as those created by the enterprise logging tools, are readily available to the public and easy to decrypt
• Be configured to ingest, aggregate, monitor, and analyze web application logs
• Implement the necessary enterprise logging system indexers, forwarders, and search heads

Rationale:

A SIEM capability supports the automated interpretation of disparate data sources and log files that contain security- and privacy-relevant information collected within a security operations architecture. SIEMs use signatures and behavioral, heuristic, and other content analysis techniques to identify indicators of suspicious or known malicious behavior and activity within monitored systems.

Related CMS ARS Security Controls include: SI-4 - System Monitoring, IR-5 - Incident Monitoring, AU - Audit and Accountability family, CA-2 - Control Assessments, CA-7 - Continuous Monitoring, CA-7(4) - Risk Monitoring, CM - Configuration Management family, RA-5 - Vulnerability Monitoring and Scanning, RA-7 - Risk Response, SC-8 - Transmission Confidentiality and Integrity, SC-13 - Cryptographic Protection, and SC-17 - Public Key Infrastructure Certificates.

Advanced Investigation

The CCIC Advanced Investigation service oversees the handling of any incidents requiring digital forensics or malware analysis on affected system(s). The Forensic & Malware Analysis Team provides recommendations, technical expertise, and analysis of the collection of digital evidence to the CCIC, Marketplace SOC, and Supporting SOCs.

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-08: Local Forensic and Malware Analysis Support

The SDM must:

• Coordinate incident response activities locally and collaborate with the CCIC, including assisting with:
  • Forensics and malware analysis
  • Incident response and threat analysis
  • Information security and privacy engineering and architecture
  • Obtaining ISPG approval for all SDM digital forensics processes and procedures
• Coordinate between administrators handling malware detection and FMAT services
• Comply with the CMS Digital Forensics Services (DFS) standard operating procedures to ensure the secure collection, transport, and analysis of digital forensic data, including:
  • Complete the required CMS Chain of Custody and CMS Evidence Collection forms
  • Provide a capability that collects volatile and non-volatile digital evidence and/or malware artifacts from identified targets in a forensically sound manner
• Cooperate fully throughout any digital forensics investigation by providing access to/information on relevant IT resources as requested by CMS, HHS, and/or the Office of Inspector General (OIG)

The SDM must ensure malware detection and forensic acquisition solutions are:

• Deployed on all applicable assets, including Network Security Endpoint Protection (NSEP), to support malware detection and forensic acquisition
• Capable of:
  • Installation within the SDM data center secure enclave
  • Proactively monitoring (e.g., focused sweeps) its IT assets for IOCs and providing alerts
  • Actively participating in the CCIC IOC sharing program to share SDM locally developed IOCs with CCIC
  • Quickly identifying and isolating compromised systems
  • Deploying software agents on remote machines to perform data collections and acquisitions
  • User-level modifications and customizations, including:
    • Ingesting IOCs using the OpenIOC Extensible Markup Language format
  • Supporting modification of IOCs for variations, differences, or other aspects of the data center environment
  • Export digital evidence in CMS-approved standard file formats (i.e., raw, Expert Witness [E01], or Advanced Forensics Format [AFF])
  • Calculate checksums of the acquired image using CMS-approved standard approaches (i.e., Message Digest number 5 [MD5] or Secure Hash Algorithm 1 [SHA1]) for validation against original evidence

The SDM forensic acquisition solution(s) must:

The SDM malware analysis solution(s) must:

• Perform analysis of malware threats in an isolated location (e.g., Malware Analysis Lab) using specialized software to:
  • Detect (identify suspected malware)
  • Detonate (extract and execute in a secured sandbox environment)
  • Analyze (identify anomalous behavior)
  • Report (provide an industry best practice-style finding report)

Rationale:

The SDM onsite forensic and malware analysis support, which acts as a sub-component of the CCIC FMAT, serves as the first responder for handling suspected incidents that require digital forensics or malware analysis on affected system(s) for confirmation. To this end, the SDM must work with ISPG to determine what tools are appropriate—and how the tools should be deployed. For example, ISPG will help the SDM determine when malware detection capabilities should be placed in-line to allow for active blocking of malicious activity or implemented using a tap / span methodology.

The FMAT requirements apply to NSEP deployments as well. NSEP functionality, which provides host-based security suite protection on endpoints (e.g., servers in the data center), protects endpoints from compromise by:

• Detecting / blocking malicious behavior (e.g., host-based IDS, host-based firewalls, and application firewalls)
• Managing system configurations and vulnerabilities
• Providing malicious code detection, such as antivirus
• Providing hardware and software asset management (including allowlisting / denylisting)
• Encryption (i.e., via a FIPS 140-2 or FIPS 140-3 validated module)
• Supporting advanced investigation

Related CMS ARS Security Controls include: AU-6 - Audit Record Review, Analysis, and Reporting, AU-7 - Audit Record Reduction and Report Generation, CA-2 - Control Assessments, CM-6 - Configuration Settings, IR-4 - Incident Handling, IR-7 - Incident Response Assistance, IR-8 - Incident Response Plan, IR-4(11) - Integrated Incident Response Team, RA-5 - Vulnerability Monitoring and Scanning, SC-5 - Denial of Service Protection, SC-7 - Boundary Protection, SC-13 - Cryptographic Protection, SI-3 - Malicious Code Protection, SI-4 - System Monitoring, SI-5 - Security Alerts, Advisories, and Directives, SI-7 - Software, Firmware, and Information Integrity.

Information Sharing and Cyber Threat Intelligence

The CCIC IS&CTI service improves the effectiveness of CMS information security and privacy by identifying CMS-specific threat indicators, actors, attack vectors, and breach scenarios to enhance situational awareness, incident detection, response, and coordination operations throughout the enterprise.

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-09: Local Information Sharing and Cyber Threat Intelligence Support

The SDM must:

• Coordinate and collaborate IS&CTI activities locally and with the CCIC, including:
  • Incident response, response plans, and threat analysis
  • Threat feed and vulnerability / baseline configuration data
  • Prioritization of mitigations
  • Regular notification on response plan and mitigation status
  • Required submission of CyberScope data feeds
• When applicable, coordinate and collaborate incident response activities locally and with the CCIC as part of the IMT
• Provide required periodic monitoring and review of (frequency of review, including FISMA systems categorized under FIPS 199 as HIGH or MODERATE and FISMA systems identified by CMS as High Value Assets, is defined within the CMS ARS):
  • Vulnerability and configuration scan reports performed on ALL assets
  • Threat feed and vulnerability / baseline configuration information
  • Boundary protection devices (e.g., Firewall, IDS / IPS) logs and reports
  • Endpoint Protection (often listed as EPP) solution (e.g., AV / anti-malware, vulnerability and configuration scanners) logs, reports, and scan results
• Ensure deployed IS&CTI capabilities provide:
  • Correlation between IS&CTI feeds and collected information (e.g., logs, reports, and scan results)
  • Analysis supporting prioritization of mitigation / remediation
• Ensure corrective actions are managed through change management or a POA&M, as appropriate

The SDM IS&CTI solution(s) must:

• Support assessment of business impact, development of mitigation plans, and implementation of the mitigation
• Ingest and export threat feed data that conforms to CMS-approved standard formats (i.e., Structured Threat Information eXpression [STIX], Trusted Automated eXchange of Indicator Information [TAXII])
• Conform to NIST SP 800-137, Information Security Continuous Monitoring, standards and procedures
• Integrate IS&CTI activities with CMS’s Governance, Risk, and Compliance Management (GRC) tools

Rationale:

The SDM onsite information sharing and cyber threat intelligence support, which acts as a sub-component of the CCIC IS&CTI team, helps the CCIC improve the effectiveness of CMS information security and privacy capabilities by identifying CMS-specific threat indicators, actors, attack vectors, and breach scenarios to enhance situational awareness, incident detection, response, and coordination operations throughout the enterprise.

IS&CTI must coordinate and correlate with the SDM’s NSEP solutions, through functionality such as the host-based security suite providing protection to endpoints (e.g., servers in the data center), to reduce the risk of compromise by:

• Detecting malicious behavior
• Managing system configurations and vulnerabilities
• Providing malicious code detection (e.g., AV)
• Providing hardware and software asset management (including allowlisting / denylisting)
• Supporting advanced investigation

Related CMS ARS Security Controls include: AU-6 - Audit Record Review, Analysis, and Reporting, AU-7 - Audit Record Reduction and Report Generation, CA-2 Control Assessments, CM-6 - Configuration Settings, IR-4 - Incident Handling, IR-7 - Incident Response Assistance, IR-8 - Incident Response Plan, IR-4(11) - Integrated Incident Response Team, PM-16(1) - Automated Means for Sharing Threat Intelligence, RA-5 - Vulnerability Monitoring and Scanning, SC-5 - Denial of Service Protection, SC-7 - Boundary Protection, SC-13 - Cryptographic Protection, SI-3 - Malicious Code Protection, SI-4 - System Monitoring, SI-5 - Security Alerts, Advisories, and Directives, SI-7 - Software, Firmware, and Information Integrity.

Penetration Testing

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-10: Penetration Testing Support

For FISMA systems categorized under FIPS 199 as HIGH or MODERATE (including FISMA systems identified by CMS as High Value Assets), the SDM must:

• Participate in the CCIC Penetration Testing Program

For SDMs participating in the CCIC Penetration Testing Program, the SDM must:

• Coordinate penetration test activities locally and collaborate with the CCIC to:
  • Provide access and security allowlisting for required CMS testing activities
  • Define the degree and nature of testing to be performed
• Implement the following capability:
  • Web application inventory mechanism that incorporates applications into the CCIC Penetration Testing Program and identifies exclusions (including both the justification and approval for exclusion from testing)

Rationale:

CMS established a penetration testing capability within ISPG to proactively assess the susceptibility of CMS systems, personnel, and facilities to attack. This capability provides a robust, repeatable penetration testing capability with meaningful and usable results that complement (while avoiding duplication of) other forms of CMS information security testing.

Related CMS ARS Security Controls include: CA-8 - Penetration Testing, RA-5 - Vulnerability Monitoring and Scanning, SC-5 - Denial of Service Protection, SC-7 - Boundary Protection, and SI-3 - Malicious Code Protection.

Security Architecture and Engineering

The CCIC Security Architecture and Engineering service provides architecture and design of security and privacy solutions across the CMS enterprise, including government and contractor facilities. The SAE capability applies a broad knowledge of CMS practices, security architectures, requirements, and solutions to strengthen the overall enterprise security posture. The CCIC SAE service provides an end-to-end view of security across the CMS enterprise to integrate all capabilities and functions effectively by designing solutions (cybersecurity capabilities) to solve evolving cybersecurity and privacy needs within the CMS TLC processes and procedures.

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-11: Local Security Architecture and Engineering Support

The SDM must ensure the availability of technically qualified staff, including trained information security and privacy personnel, to fulfill the roles and responsibilities of the SDM SAE. Small SDMs may choose to defer part or all required capabilities to the CCIC SAE via an appropriate Memorandum of Understanding / Memorandum of Agreement.

The SDM must:

• Provide local security architecture and engineering support, consisting of:
  • Full understanding of the local architecture, network, and hardware / software inventory
  • Work with CCIC SAE to design local SDM capabilities to be integrated with CCIC
  • Oversee deployment of local SDM capabilities to integrate with CCIC
  • Troubleshoot integration problems after deployment
• Deploy the following capabilities:
  • Network mapping and risk context analyzer including layer-3 device configuration analysis

Rationale:

The SDM onsite security architecture and engineering support, which acts as a sub-component of the CCIC SAE, serves as the key resource for helping CCIC SAE provide an end-to-end view of security across the CMS enterprise.

Related CMS ARS Security Controls include: CA-2 - Control Assessments, AT-2 - Literacy Training and Awareness, AT-3 - Role-Based Training, PL-4 - Rules of Behavior, RA-5 - Vulnerability Monitoring and Scanning, IR-4(11) - Integrated Incident Response Team, SI-4 - System Monitoring, AU - Audit and Accountability family

High Value Assets

A high-value asset is an asset used as a mission-critical information resource supporting infrastructure providers / suppliers or partnering organizations. The unauthorized disclosure of modification / destruction of, or disruption of access to information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Among other requirements, BR-CCIC-01, Security Authorization of Systems, says the business owner / information system owner / SDM must categorize the FISMA system in accordance with FIPS 199, and document the system attributes used to identify PII, PHI, and HVAs. The CIO determines whether a system is an HVA. If the CMS CIO identifies a CMS system as a High Value Asset, an HVA Designation Letter must be on file. Please refer to BR-CCIC-01 for more information.

CMS is required to comply with OMB Memorandum M-19-03, Strengthening the Cybersecurity of Federal Agencies by enhancing the High Value Asset Program, December 2018; CISA’s Binding Operational Directive (BOD) 18-02, Securing High Value Assets, May 2018; CISA High Value Asset Control Overlay, February 2018.

The CISA High Value Asset Control Overlay provides additional protections required for all HVA systems to increase the level of assurance that the HVA will meet the protection needs of the organization and help the federal government manage and reduce known risks to its most valuable assets. The enhanced controls assist in reducing the following risks:

• Reducing available attack surface
  • Limit lateral movement (e.g., from adjacent components) by requiring segmentation and strict flow control
  • Limit internal connections
  • Coordinate auditing across organizations
• Protecting against unauthorized access
  • Strict identity and account management practices
  • Reduce and limit access to elevated privileges
  • Enhance access controls on privileged accounts
• Enhancing protection, control, and monitoring of data to be shared outside the HVA authorization boundary
  • Reduce risk of loss of confidentiality
  • Minimize data shared with known recipients (i.e., specific users, specific roles, and/or specific remote hosts)
  • Link monitoring and reporting to OMB Circular A-130 requirements
• Consolidating and centralizing device audit and logging to improve monitoring, detection, and response
  • Coordinate across organizations
  • Streamline organizational response to incidents
  • Improve capabilities to detect threats
• Holding contractors accountable and liable for implementation and effectiveness of implemented security and privacy controls
• Protecting the acquisition supply chain for HVAs

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS that have been identified by the CMS CIO as an HVA. All systems identified as HVAs must not only meet or exceed the CMS minimal security and privacy control baselines for the FIPS 199-based security impact level (HIGH or MODERATE), but also implement the HVA security and privacy controls defined within DHS’s High Value Asset Control Overlay. When the implementation under the CMS ARS and the DHS HVA overlay differ, the most rigorous implementation is required.

BR-CCIC-26: High Value Assets

If a CMS system will be identified by the CMS CIO as a High Value Asset (i.e., HVA Designation Letter will be on file), the SDM must:

• Meet security and privacy requirements defined by the CMS HVA Program
  • Meet or exceed applicable security and privacy control baselines for the system’s FIPS 199-based security impact level (i.e., HIGH or MODERATE)
  • Meet or exceed applicable security and privacy control requirements defined within DHS’s High Value Asset Control Overlay
• Ensure all privacy documentation (e.g., PIA, SORN, and sharing agreements) is completed and approved by the CMS SOP

Rationale:

The SDM developing or maintaining a CMS HVA is required to meet emerging HVA requirements. To this end, the SDM must work with ISPG to determine what security and privacy controls and control enhancements are appropriate—and how the controls and control enhancements will be implemented. For example, ISPG will help the SDM determine when multiple authorizations are required and who is authorized to provide those authorizations before a user account will be created.

Related CMS ARS Security Controls include: CA-3 - Information Exchange, CA-3(6) - Supplemental: Transfer Authorizations, AC-2 - Account Management, AC-3 - Access Enforcement, AC-4 - Information Flow Enforcement, AC-6 -Least Privilege, AC-17 - Remote Access, AC-20 - Use of External Systems, CA-5 - Plan of Action and Milestones, CA-6 - Authorization, CA-7 - Continuous Monitoring, CA-7(4) Risk Monitoring, CA-9 - Internal System Connections, AU-2 - Event Logging, AU-6 - Audit Record Review, Analysis, and Reporting, AU-9 - Protection of Audit Information, AU-10 - Non-Repudiation, AU-16 - Cross-Organizational Audit Logging, CM-5 - Access Restrictions for Change, CM-6 - Configuration Settings, CM-8 - System Component Inventory, PL-2 - System Security and Privacy Plans, PL-8 - Security and Privacy Architectures, PL-10 - Baseline Selection, SC-3 - Security Function Isolation, SC-5 - Denial-of-Service Protection, SC-7 - Boundary Protection, SC-8 - Transmission Confidentiality and Integrity, SC-18 - Mobile Code, SC-28 - Protection of Information At Rest, RA-1 - Policy and Procedures, IA-2 - Identification and Authentication (Organizational Users), IA-3 - Device Identification and Authentication, IA-5 - Authenticator Management, CP-8 - Telecommunications Services, CP-9 - System Backup, CP-9(8) Cryptographic Protection, CP-10 - System Recovery and Reconstitution, PM-7 - Enterprise Architecture, PM-9 - Risk Management Strategy, PM-10 - Authorization Process, PM-12 - Insider Threat Program, IR-4(10) - Supply Chain Coordination, IR-5 - Incident Monitoring, RA-5 - Vulnerability Monitoring and Scanning, RA-8 - Privacy Impact Assessments, RA-9 - Criticality Analysis, SA-4 - Acquisition Process, SA-9 - External System Services, SA-11 - Developer Testing and Evaluation, SI-2 - Flaw Remediation, SI-3 - Malicious Code Protection, SI-4 - System Monitoring, and PE-3 - Physical Access Control.

Information Security Continuous Monitoring / Privacy Continuous Monitoring

In compliance with federal and HHS requirements, CMS will perform periodic manual or automated audits, scans, reviews, or other inspections of the contractor’s IT environment that is used to provide or facilitate services for CMS.

CyberScope

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-12: CyberScope Data Feeds

Each SDM must:

• Provision, secure, monitor, and maintain the hardware, network(s), and software supporting the ISCM capability infrastructure:
  • ISCM capability may be provided by CMS.
• Provide required security and privacy continuous monitoring feeds that:
  • Comply with the CISA CyberScope reporting requirements
  • Automate CyberScope data feeds to the CCIC, as required

Where ISPG security tools do not cover automated security domains, SDMs must:

• On a real-time basis, locally maintain tools to provide the necessary continuous monitoring feeds specified in NIST SP 800-137 and other emerging federal requirements

Rationale:

Recent updates to FISMA reporting guidance focus Agency resources on building the infrastructure and capabilities required to fulfill ISCM / PCM requirements. CISA and HHS have defined specific, automated feed requirements for both CyberScope reporting and improved situational awareness. In compliance with these requirements, CMS will perform periodic manual or automated audits, scans, reviews, or other inspections of the contractor’s IT environment that provides or facilitates services for CMS.

CyberScope currently requires automated scanning and feeds that report the status of asset management, vulnerability management, and configuration management across all assets. To facilitate the aggregation of this data across the numerous existing tools used by contractors, NIST defined Security Content Automation Protocol standards. SCAP includes formats for asset management (Common Platform Enumeration [CPE]), vulnerability management (Common Vulnerabilities and Exposures [CVE]), and configuration management (Common Configuration Enumeration [CCE]). These feeds must be collected in the Lightweight Asset Summary Results (LASR) schema and Extensible Configuration Checklist Description Format (XCCDF).

In addition to meeting all CMS information security and privacy requirements that are documented in the Information Security and Privacy Library, contractors must work closely with the CCIC and the CDM Program Team to implement the federally required CDM capabilities. CISA oversees the definition and implementation of the CISA Continuous Diagnostics and Mitigation (CDM) Program, including the program requirements and participation in the acquisition of tools, as outlined on the General Services Administration (GSA) in the GSA Continuous Diagnostics and Mitigation Tools information website. This topic emphasizes and repeats many of the CISA CDM requirements.

The CMS ARS requires an independent, third-party assessment of the SDM’s security controls to determine the extent to which security controls are implemented correctly, operating as intended, and producing the desired outcomes in meeting security requirements. CMS’s security assessment staff are available for consultation during the assessment process and will review the results before issuing an assessment and subsequent authorization recommendation. CMS ISPG reserves the right to verify the infrastructure and security test results before issuing an authorization recommendation. This recommendation will support the CIO in making the final authorization decision.

Related CMS ARS Security Controls include: CA-7 Continuous Monitoring, CA-7(4) - Risk Monitoring, RA-5 - Vulnerability Monitoring and Scanning, SI-4 - System Monitoring, AU - Audit and Accountability family, CM-8 - Information System Component Inventory, CA-2 - Control Assessments, PM-27 - Privacy Reporting, and PM-21 - Accounting of Disclosures.

CDM Asset Management

CDM’s Asset Management (formerly Phase 1) addresses endpoint integrity through management of hardware and software assets, configuration management, and vulnerability management. These capabilities are viewed as foundational capabilities in the protection of systems and data.

The business rules within this topic apply to all FISMA system and System Developer and Maintainer (SDM) data centers supporting CMS.

BR-CCIC-13: Local ISCM / CDM Management Capability

The SDM must:

• Provide centralized management and configuration of the content captured from individual components of the information system under ISCM / CDM
• Provide centralized content repositories, made available to the CCIC, whereby:
  • Information, including system and network monitoring data, is available to the CCIC in a format compliant with CMS and federal (e.g., CDM) requirements
  • Centralized content repository record sources include systems, appliances, devices, services, and applications (including databases)
  • As required by the CMS ARS, raw content must be available in an unaltered format to the CCIC
  • Records are maintained for ninety (90) days and archives of old records for one (1) year to provide support for analysis, incident response, management, disposition, and after-the-fact investigations of security incidents and to meet regulatory (e.g., Federal Rules of Evidence) and CMS information retention requirements
• Assess or support the assessment by third parties of all security controls to verify the security controls are adequately designed, effectively implemented, and appropriately documented.

The term ‘tailorable’ as used in this document references CMS ARS Supplemental controls and control enhancements that CMS encourages Business Owners to consider. The CMS ARS states that many of the mandatory and supplemental controls are customizable (i.e., tailorable) by the Business Owner.

Rationale:

Effective ISCM is the implementation of a strategy that addresses ISCM requirements and activities at each organizational tier (organization, mission / business processes, and information systems). Each organizational tier centrally monitors security metrics and assesses security control effectiveness with established monitoring and assessment frequencies and status reports customized to support tier-specific decision making. Policies, procedures, tools, and templates are implemented at each organizational tier and are managed in accordance with guidance from higher-level organizations in a manner that supports shared use of data within and across tiers.

ISCM / CDM Capability Management is the centralized management, including O&M, of security functions that support the federal government’s ISCM program.

Related CMS ARS Security Controls include: CA-7 - Continuous Monitoring, CA-7(4) - Risk Monitoring, RA-5 - Vulnerability Monitoring and Scanning, SI-4 - System Monitoring, SI-2 - Flaw Remediation, AU - Audit and Accountability family, CM-8 - Information System Component Inventory, and CA-2 - Control Assessments.

BR-CCIC-14: Hardware Asset Management Capability

The SDM must:

• Provide a managed and tailorable hardware asset management (HWAM) capability to protect endpoint configurations
• Manage hardware assets (such as authorized assets connected to CMS networks and unauthorized devices disconnected from the network) automatically, according to CMS- and HHS-defined guidance and requirements

The SDM HWAM capability must:

• Prevent / reduce damage from unauthorized hardware gaining access to the network, as defined by the SDM and CMS
• Detect and relay hardware inventory and provide a means to prevent access to the network by unauthorized hardware
• Provide management and reporting of changes
• Provide status feeds to the CCIC in a format compliant with CMS and Federal (e.g., Continuous Diagnostics and Mitigation) requirements
• Assign risk to each difference between the authorized hardware inventory baseline and the actual hardware inventory, based on relevant factors
  1. Scores for all authorized and unauthorized hardware.
  2. When applicable, standard federal score for deviations from authorized hardware inventory baseline.
  3. CMS, HHS, or SDM scores for deviations from authorized hardware inventory baseline, provided CMS has adopted a policy that permits the difference from applicable corresponding federal policy.
• Maintain records for ninety (90) days and archives old records for one (1) year to provide support for analysis, incident response, management, disposition, and after-the-fact investigations of security incidents and to meet regulatory (e.g., Federal Rules of Evidence) and CMS information retention requirements by:

The HWAM tool must score (assign a numerical value to) deviations for purposes of computing risk. Scoring includes:

1. Determining[JD20]  deviation between the authorized hardware inventory and the actual hardware inventory
2. Ensuring deviations are identified and include both missing and newly identified (i.e. previously unknown / unidentified) hardware assets

• Report anomalies when deviations between the authorized hardware inventory baseline and the actual hardware inventory are detected and:

1. Remove[JD21]  (disallow access) or authorize the unauthorized hardware device
2. Bring the unauthorized asset back into operation, record its non-operational status (with rationale), or de-authorize the hardware when the difference indicates authorized hardware that is missing in operation

To support the HWAM capability, the SDM must:

• Identify, review, update, and address the status of all devices within the SDM’s enterprise / boundary (i.e., maintain the actual hardware [HW] inventory) :
  • Create, operate, and maintain an inventory of authorized hardware, including perimeter and endpoint devices, in near real time, along with applicable information required to accurately assess risks to the asset
  • Update the inventory regularly with automated hardware discovery processes and tool(s) no less than once every 72 hours.
• Enable and revoke access, manually and automatically, for perimeter and endpoint devices that connect to the SDM network based on knowledge of the asset and authorization (e.g., grant the asset access to the network when authorized or block access to the SDM network when not authorized)

Rationale:

Once unauthorized or unmanaged hardware is discovered, the SDM will either remove or authorize and manage this hardware. Since unauthorized hardware is unmanaged, it must be assumed to be vulnerable and can be exploited as a pivot to other assets if not removed or managed.

The HWAM capability is achieved through the creation, operation, and maintenance of an authorized hardware inventory baseline that assigns unique identifiers for hardware and tracks key contact properties such as the manager or custodian of the hardware. General requirements for HWAM from CISA include:

• The process for generating the authorized hardware inventory baseline must be established, operated, and maintained in environments already in operation, following CMS and HHS-defined guidance and requirements.
• To provide this functionality, SDMs should not assume existing CMS or SDM property management capabilities can assist in generating the authorized hardware inventory baseline. Where available, property management systems should be considered as sources of input for the authorized hardware inventory baseline.
• The authorized hardware inventory baseline generated by this process must be complete, accurate, and timely. For this purpose, “timely” is at least once every 72 hours.

Related CMS ARS Security Controls include: CM-8 - Information System Component Inventory.

BR-CCIC-15: Software Asset Management Capability

The Software Asset Management (SWAM) capability inventories all software configuration items (SWCI) in IT assets on a network and provides oversight.

The following requirements apply to all CMS FISMA system and SDM data centers supporting CMS.

The SDM must:

• Provide a managed and tailorable SWAM capability to provide a full inventory of software assets on any FISMA system
• Manage and dispose of software (i.e., authorize software to operate on or be removed from the network) manually or automatically, according to CMS- and HHS-defined guidance and requirements

The SDM SWAM capability must:

• Prevent / reduce damage from and/or execution of malware and/or unpatched software assets, as defined by the SDM and CMS
• Detect and report malware (including, as configured, non-patched but necessary software assets) at a rate comparable to existing AV products and provide a means for removing malware in time to prevent it from executing
• Provide management and reporting of current changes and software installation actions
• Provide status feeds to the CCIC in a format compliant with CMS and Federal (e.g., Continuous Diagnostics and Mitigation) requirements
• Assign risk to each difference between the authorized software inventory baseline and the actual software inventory, based on relevant factors
  1. Scores for all authorized and unauthorized software based on patch level, maintenance / support, configuration, and known vulnerabilities.
  2. When applicable, standard federal score for deviations from authorized software inventory baseline.
  3. CMS, HHS, or SDM scores for deviations from authorized software inventory baseline, provided CMS has authorized the deviation from applicable CMS or federal policy.
• Maintain records for ninety (90) days and archives old records for one (1) year to provide support for analysis, incident response, management, disposition and after-the-fact investigations of security incidents and to meet regulatory (e.g., Federal Rules of Evidence) and CMS information retention requirements by:

The SWAM tool must score (assign a numerical value to) deviations for purposes of computing risk. Scoring includes:

1. Determining[JD22]  differences between authorized software inventory and actual software inventory
2. Ensuring differences identified include expected (i.e., known, authorized), unexpected (i.e., unknown, unidentified), and missing software assets

• Report anomalies when installed software assets are not showing on the provided inventory

To support the SWAM capability, the SDM must:

Identify, review, update, and address the status of all software within its enterprise / boundary (i.e., maintain the actual software inventory) as authorized / unauthorized, managed / unmanaged, or reporting / non-reporting:

• Create, operate, and maintain its inventory of authorized and unmanaged software in near real time, along with applicable information required to accurately assess risks to the asset and physically locate the asset.
• Generate/update inventory data that is complete, accurate, and timely. For this purpose, “timely” means no less often than once every 72 hours.
• Assess all software assets on all perimeter and endpoint devices within its network no less often than once every 72 hours / three (3) calendar days using an automated mechanism.
• Enable and revoke access to any software asset, manually and automatically, for perimeter and endpoint devices that connect to the SDM network, based on knowledge of the asset and authorization (e.g., grant execution when authorized or block execution when not authorized).

CMS does not specify which SWAM tool a SDM may choose. If a SDM chooses a different tool, the SDM is responsible for ensuring compatibility and interoperability with the CCIC.

Rationale:

Once unauthorized or unmanaged SWCIs are discovered by the contractor’s provided tool(s), the contractor will act to remove these SWCI. Because unauthorized software is unmanaged, it is vulnerable to exploitation as a pivot to other IT assets if not removed or managed. In addition, a complete, accurate, and timely software inventory is essential to support awareness and effective control of software vulnerabilities, security configuration settings, and licensing efficiencies.

The SWAM capability is achieved through the creation, operation, and maintenance of an authorized software inventory baseline that assigns unique identifiers for software and tracks key contact properties such as the manager or custodian of the software. General requirements for SWAM from CISA include:

• The process for generating the authorized software inventory baseline must be established, operated, and maintained in environments that are already in operation, following CMS- and HHS-defined guidance (e.g., business rules) and requirements.
• It should not be assumed that CMS and SDM property management functions will assist the process for generating the authorized software inventory baseline; however, where property management systems are available, the property management systems should be considered as sources of input for the authorized software inventory baseline.
• The authorized software inventory baseline generated by this process must be complete, accurate, and timely. For this purpose, “timely” is at least once every 72 hours.

Related CMS ARS Security Controls include: CM-7 - Least Functionality, CM-7(4) - Unauthorized Software - Deny, and CM-7(5) - Authorized Software - Allow.

BR-CCIC-16: Configuration Settings Management Capability

The CSM capability reduces misconfiguration of IT assets, including misconfigurations of hardware devices (i.e., physical, virtual, and operating system) and misconfigurations of software. Deviations and changes in configuration may make the device or software either more secure or less secure. The CSM tool is not responsible for distinguishing the difference.

The following requirements apply to all CMS FISMA system and SDM data centers supporting CMS.

The SDM must:

• Provide a managed and tailorable CSM capability to protect endpoint configurations
• Manage a change control process to document CMS and SDM extensions or exceptions to the authorized core federal benchmarks
• Implement a CMS-authorized security configuration benchmark as defined within the ARS: The baseline consists of the acceptable value(s) for each relevant configurable setting for each IT asset type.
  • Establish a core benchmark, based on CMS / HHS / federal guidance (e.g., the CMS ARS) and requirements, for hardware devices and software with pre-programmed tests for actual status and an authoritative system, based on federally approved scoring methodologies and standards, to provide core scores for risk assessment
  • Adopt the federal benchmark and/or:
    • Add, modify, or delete non-core configuration settings with review and approval from ISPG
    • Assign an alternate method to score risk for common and CMS / SDM-specific settings for internal SDM use
  • Develop an internal benchmark tool using pre-programmed tests to evaluate actual status and an authoritative system, using federally approved scoring methodologies and standards, to provide core scores for risk assessment

Each configuration baseline setting can be traced to an authoritative reference, such as US Government Configuration Baseline (USGCB), DISA STIG, etc.

The SDM CSM capability must:

• Prevent / reduce risk of damage from misconfiguration
• Detect and report changes in configuration (i.e., from the defined baseline) at a rate comparable to existing AV products and provide a means for remediation of unauthorized changes
• Provide management and reporting of configuration settings and changes
• Provide status feeds to the CCIC in a format compliant with CMS and Federal (e.g., Continuous Diagnostics and Mitigation) requirements
• Maintain records for ninety (90) days and archives old records for one (1) year to provide support for analysis, incident response, management, disposition, and after-the-fact investigations of security incidents and to meet regulatory (e.g., Federal Rules of Evidence) and CMS information retention requirements
• Assign risk to each difference between the authorized configuration setting (i.e., the baseline) and the actual configuration setting, based on relevant factors: The CMS tool must score (assign a numerical value to) deviations for purposes of computing risk. Scoring includes:
  1. Scores for settings based on patch level, maintenance / support, configuration, and known vulnerabilities.
     1. When applicable, standard federal score for deviations (e.g., Common Configuration Scoring System [CCSS]) from the authorized software inventory baseline.
     2. CMS, HHS, or SDM scores for deviations from authorized baseline values, provided CMS has authorized the difference from applicable CMS or federal policy.
  2. Maintain and ensure collected data is used for purposes of analysis, incident response, investigation, management, and disposition by determining differences between authorized configuration and actual configuration
• Report anomalies when differences between the authorized configuration baseline and the actual configuration are detected

To support the CSM capability, the SDM must:

• Identify, review, and update the status of configuration settings for all monitored devices within its enterprise:
  • Create, operate, and maintain the SDM’s information on deviations from baseline configurations in a timely manner [at least once every 72 hours / three (3) calendar days] along with information needed to assess the risk associated with the deviations
  • Update the baseline deviations regularly with automated software discovery processes and tool(s)
  • Generate inventory data that is complete, accurate, and timely. For this purpose, “timely” means no less often than once every 72 hours.
• Assess all configuration settings on all perimeter and endpoint devices within its network no less often than once every 72 hours / three (3) calendar days, using an automated mechanism
• Address configuration setting deviations from a defined baseline, manually and automatically, for perimeter and endpoint devices that connect to the SDM network, based on knowledge of the asset and authorization (e.g., deviation is granted)

Although CMS does not specify which CSM tool a SDM may choose, the solution should meet the technical, operational, and reporting requirements set forth in this document. The SDM is responsible for ensuring compatibility and interoperability with the CCIC.

Validation of CSM Compliance

To support CMS’s tool-agnostic approach to CSM for SDMs, CMS has chosen to follow an approach which decouples the process of an SDM implementing and operating an automated CSM tool versus CMS’s process of validating an SDM’s CSM compliance to an identified standard using a common tool.

• The SDM will conduct timely CSM compliance scans using CMS’s supplied solution
• The SDM scans will use a CMS identified DISA STIG baseline and CMS supplied audit files which support FISMA tagging
• The SDM will create a CSM repository that can be peered by CMS’s instance

Rationale:

Once a misconfiguration of hardware or software is discovered by the provided tools, the SDM is responsible for taking any needed action to resolve the problem or request that CMS accept the risk upon appropriate risk analysis and documentation in conjunction with the ISSO.

CISA estimates that over 80 percent of known vulnerabilities are attributed to misconfiguration and missing patches. Cyber adversaries often use automated computer attack programs to search for and exploit IT assets with misconfigurations, especially for assets supporting federal agencies, and then pivot to attack other assets.

Related CMS ARS Security Controls include: CM-6 - Configuration Settings and CM-7 - Least Functionality.

BR-CCIC-17: Vulnerability Management Capability

The vulnerability management (VUL) capability, including exposure-based vulnerability management, discovers and supports remediation of vulnerabilities in IT assets on a network. This includes, but is not limited to, AV, host, and application scanning (credentialed and non-credentialed); host-based IDS / IPS; network vulnerability and risk analysis; and web application scanning.

CMS primarily uses a standard vulnerability assessment tool to perform vulnerability management and continuous risk monitoring at CMS. The tool leverages a distributed architecture that allows CMS to conduct efficient and nonintrusive vulnerability assessments with very low impact to network or host resources (an executable exists on the target of the scan for the duration of the scan). In addition, by continuously updating its host / vulnerability information, the CDM Program team can provide system administrators, ISSOs, and system owners with current, actionable information without the need for ad hoc scanning.

The following requirements apply to all CMS FISMA system and SDM data centers supporting CMS.

The SDM must:

• Provide managed and tailorable vulnerability management capabilities to protect endpoints, including:
  • AV
  • HIDS / Host-based Intrusion Prevention System (HIPS)
• Manage a change control process to document CMS and SDM extensions or exceptions to the authorized core federal benchmarks

The SDM VUL capability must:

• Deploy a vulnerability assessment tool to assess the presence of known vulnerabilities and prevent / reduce risk of damage from known vulnerabilities
• Detect and report the status of known vulnerabilities at a rate comparable to existing AV products and provide a means to prioritize required remediation in compliance with the CMS ARS
• Provide management and reporting the existence of known vulnerabilities
• Where the CMS standard vulnerability assessment tool is deployed: create and maintain a repository for VUL data that can be peered by CMS’s instance ; or when an alternate tool is used, provide status feeds to the CCIC in a format compliant with CMS and Federal (e.g., Continuous Diagnostics and Mitigation) requirements
• Assign risk to each vulnerability based on relevant factors
  1. Scores for vulnerabilities based on patch existence, maintenance / support, and known threats exploiting the vulnerabilities.
  2. When applicable, standard federal score for vulnerabilities (i.e., Common Vulnerability Scoring System).
  3. CMS, HHS, or SDM scores for vulnerabilities, provided CMS has authorized the deviation from applicable federal values.
• Maintain records for ninety (90) days and archives old records for one (1) year to provide support for analysis, incident response, management, disposition, and after-the-fact investigations of security incidents and to meet regulatory (e.g., Federal Rules of Evidence) and CMS information retention requirements, by:

The VUL tool must score (assign a numerical value to) vulnerabilities detected for purposes of computing risk. Scoring includes:

1. Determining[JD23]  the presence of known vulnerabilities within a system or application
2. Updating vulnerability definitions within one (1) week of the update release

• Report anomalies when vulnerabilities are detected

To support the VUL capability, the SDM must:

• Identify, review, and update the status of the presence of vulnerabilities for all monitored devices within its enterprise and do the following:
  • Create, and maintain the SDM’s information on the presence of vulnerabilities in a timely manner (at least once every 72 hours / three [3] calendar days), along with information needed to assess the risk associated with the vulnerabilities
  • Update the presence of vulnerabilities regularly with automated software discovery processes and tool(s)
  • Generate inventory data that is complete, accurate, and timely. For this purpose, “timely” means no less often than once every 72 hours.
• Assess the presence of known vulnerabilities on perimeter devices within its network no less often than once every 72 hours / three (3) calendar days, using an automated mechanism
• Address identified vulnerabilities, manually and automatically, for perimeter devices that connect to the SDM network, based on knowledge of the asset and authorization (e.g., deviation granted)

To support CCIC-based vulnerability scanning, the SDM must:

• Facilitate the deployment and maintenance of the CMS standard suite of tools and meet the following requirements:
  • Follow the procedures and documentation provided by CMS in onboarding the CMS standard solution
  • If required, create a repository for VUL data that can be peered by the CMS instance of the tool
  • Provide the necessary infrastructure to host virtual device profilers (DP) provided by ISPG or work with ISPG to determine if a physical DP is required for scanning
  • Make all necessary firewall and routing changes to all machines that contain or transfer CMS data to allow for authenticated scanning
• Manage a change control process to document CMS and SDM extensions or exceptions to the authorized core federal benchmarks

SDMs with public-facing websites must:

• Reduce the risks associated with web-based applications used within CMS through ongoing security testing that facilitates the actionable identification, remediation, and elimination of vulnerabilities and defects
• Control costs associated with web-based applications used within CMS through the identification, remediation, and elimination of vulnerabilities and defects in development and quality assurance environments
• Provide a cost-effective monitoring and compliance capability for the security programs associated with web-based applications used within CMS
• Manage regulatory demands associated with web-based applications used within CMS for protecting sensitive data processed by web-based applications

Although CMS itself uses a specific module to provide AV capabilities, CMS does not specify use of an AV application within the SDM. The SDM may choose any AV so long as the application receives updates regularly (i.e., in compliance with CMS ARS update requirements) and can provide CMS with standards-based status feeds.

CMS does not specify HIDS / HIPS tools for use by SDMs so long as the application can provide CMS with standards-based status feeds.

Rationale:

Vulnerability management is the management of risks presented by known software weaknesses that are subject to exploitation. The VUL function ensures that configuration errors and deficiencies are identified and remediated quickly. (Information security vulnerabilities are deficiencies in software that a hacker can use directly to gain access to a system or network.) Once the VUL tool(s) identifies these configuration errors and deficiencies, CMS and its SDMs act to remove or remediate these from operational systems to ensure the vulnerabilities can no longer be exploited.

The VUL capability scans CMS assets and SDM assets used to support CMS for known vulnerabilities, such as missing patches and improper access controls, and software weaknesses by:

• Discovering and locating known security vulnerabilities
• Discovering and locating software weaknesses in network configuration, software applications, and source code
• Supporting awareness and understanding of exposure risks associated with software weaknesses

Related CMS ARS Security Controls include: RA-5 - Vulnerability Monitoring and Scanning, RA-7 - Risk Response, CA-7 - Continuous Monitoring, and CA-7(4) - Risk Monitoring.

SOC as a Service

CMS data center operators may use remote SOC as a Service (SOCaaS) services as part of a comprehensive plan that meets all the requirements discussed in this CCIC Integration chapter. The CMS CCIC may also offer to provide SOC services for CMS data centers that do not operate their own in-house SOC.

Perimeter Protections

A Perimeter Protections capability examines all cybersecurity and privacy events to identify any impact to CMS assets or information. To achieve this goal, this service provides standardized tools and techniques to monitor network perimeters and internal traffic flows for lateral communication.

Perimeter Monitoring

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-18: Perimeter Monitoring Prerequisites

The SDM must:

• Comply with CMS ARS Security Control SI-4 - Information Security Monitoring requirements:
  • Perform real-time monitoring of traffic that traverses the CMS secure enclave/boundary, including any ingress or egress traffic that crosses an SDM’s internal FISMA system security boundary
  • Identify the most effective monitoring points on the network to monitor perimeter traffic traversing the CMS secure enclave/boundary
• Ensure that the monitoring points (e.g., network taps):
  • Provide visibility to traffic going from the internal network to the public Internet and from the public Internet into an internal network
  • Implement a capability to decrypt encrypted traffic to ensure proper inspection of all traffic traversing the SDM boundary
  • Allow for source attribution to the originating host prior to any network address translation (NAT) or port address translation (PAT)
  • Support the core competencies of full packet capture, IDS / IPS, and web- and email-based malware detection
• Adjust monitoring boundaries as new points of ingress/egress are created and/or identified:
  • For new points of ingress / egress, adjustment for monitoring boundaries before transitioning the system into production
  • For previously unknown points of ingress / egress, the adjustment window for revising monitoring boundaries is defined by the CMS POA&M process.

To support the perimeter monitoring capability, the SDM must:

• Identify, review, update, or remove monitoring techniques based on analysis of network traffic traversing the environment and do the following:
  • Create, test, and verify newly developed techniques for deployment on network sensors and other perimeter monitoring tools
  • Maintain and support existing techniques for deployment on network sensors and other perimeter monitoring tools
  • Address intrusion attempts, suspicious incidents, and other daily cyber operations activities

Rationale:

The FISMA system (or SDM) must implement and support a technical capability to perform full packet capture and analysis of network traffic traversing the perimeter of the data center as it applies to the CMS secure enclave/boundary. The capture and analysis are in support of incident detection and investigations.

Related CMS ARS Security Controls include: SI-4 - System Monitoring; SI-3 - Malicious Code Protection; SC-7 - Boundary Protection; AC-18 - Wireless Access; AT-2 - AT-2(3) - Social Engineering and Mining, Literacy Training and Awareness, AT-3 - Role-Based Training, PL-4 - Rules of Behavior; CM-7 - Continuous Monitoring; PM-13 - Security and Privacy Workforce; PM-14 - Testing, Training, and Monitoring;

Full Packet Capture / Inspection

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-19: Full Packet Capture Capability

The SDM-deployed full packet capture (PCAP) capability must:

• Capture and export large amounts of raw network packets in a PCAP-compatible format that must:
  • Be implemented via a network tap or a span port on the infrastructure router (A network tap is the preferred method because it provides the most reliable visibility into network traffic. Span ports are only used in cases where a tap cannot be deployed for technical reasons.)
  • Capture network packets at line speed
  • Ensure the point of monitoring connection provides access to unencrypted network traffic either prior to any Transport Layer Security (highest available level) encryption or as part of a solution to decrypt TLS traffic.
  • Ensure packet data storage meets or exceeds CMS data retention requirements
  • Organize captured packets in a logical manner to facilitate the ability to quickly store, search, and retrieve data
• Process the packets at the protocol level and must:
  • Reconstruct sessions for common protocols such as web, email, File Transfer Protocol, etc.
  • Navigate packet / session information via graphical user interface (GUI)
  • Support deep analytics of raw packets and automated reporting
• Provide the CCIC with access to both the packet capture and network analysis tool(s) as required

Rationale:

The FISMA system (or SDM) must implement and support a technical capability to perform full packet capture and analysis of network traffic traversing the perimeter of the data center as it applies to the CMS secure enclave/boundary. The capture and analysis are in support of incident detection and investigations.

Related CMS ARS Security Controls include: SI-4 - System Monitoring, SC-5 - Denial of Service Protection, SC-7 - Boundary Protection, AC-4 - Information Flow Enforcement, AC-18 - Wireless Access, and AU-2 - Event Logging.

Network Intrusion Detection / Prevention

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-20: Network Intrusion Detection / Prevention Capability

The SDM-deployed network intrusion detection / prevention capability must:

• Support the loading of customized signatures generated by either the SDM security personnel or CCIC, based on CCIC-supplied IOCs
• Generate alerts that can be consumed as data feeds into the CMS enterprise logging tool
• Implement a solution that provides the key prerequisites defined under Perimeter Monitoring:
  • Provide visibility into traffic traversing the perimeter
  • Provide source attribution to the originating host prior to any NAT or PAT
  • Decrypt encrypted traffic to ensure proper inspection of all traffic traversing the SDM boundary

Rationale:

Network-based IDS / IPS provides tunable, automated alerting capabilities; however, the network-based IDS / IPS does require a moderate degree of management and maintenance to ensure the alerts triggered by the implemented rules are not largely false positives (“noise”) that result in wasted security investigation efforts.

Related CMS ARS Security Controls include: SI-3 - Malicious Code Protection, SI-4 - System Monitoring, and SC-7 - Boundary Protection.

Malware Detection / Prevention

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-21: Malware Detection / Prevention Capability

The SDM must:

• Route inbound and outbound Internet traffic containing CMS data through a federally approved TIC service
• Deploy web-based and email malware analysis, detection, and prevention capabilities when end user platforms (such as servers, appliances, devices, workstations, etc.) can connect to non-CMS networks without first passing through a TIC. These capabilities must:
  • Support auto-configured test environments to safely execute and inspect suspected malware payloads
  • Deploy at strategic network ingress/egress points to ensure complete coverage of both enterprise and enclave perimeters
  • Support collection of data for analysis through either a network tap or a span port on the infrastructure router(s); network taps are preferred, which provide more reliable visibility into network traffic
  • Span ports may only be used in cases network taps cannot be deployed.
    • Span port use must be documented and approved by CMS.
• Support detection and blocking of detected threats, including:
  • Advanced zero-day exploits
  • Outbound callbacks

The SDM-deployed web-based malware analysis, detection, and prevention capability must:

• Dynamically generate actionable malware intelligence, including:
  • Detect and alert on web-based attacks:
    • Leverage both signature and signature-less engine(s) for detection
    • Support automated response (i.e., active blocking that is capable of automatically responding to and stopping an attack) to web-based attacks
  • Automated response (active blocking) must be coordinated with all stakeholders (i.e., ISSO, SDM, ISPG, and business owner) and documented before activation
  • Forward alert, security-related, and log data to the CMS enterprise logging tool
  • Monitor assets without reliance on deployed software agents

The SDM-deployed email malware analysis, detection, and prevention capability must:

• Dynamically generate actionable malware intelligence, including:
  • Detect and alert on email-based attacks:
    • Leverage both signature and signature-less engine(s) for detection
    • Support automated response (i.e., active blocking that is capable of automatically responding to and stopping an attack) to email-based attacks
  • Automated response (active blocking) must be coordinated with all stakeholders (i.e., ISSO, SDM, ISPG, and business owner) and documented before activation
  • Forward alert, security-related, and log data to the CMS enterprise logging tool
  • Monitor assets without reliance on deployed software agents
  • The point(s) of monitoring for the SDM malware analysis, detection, and prevention solution sensors must provide access to unencrypted network traffic, either prior to any TLS (highest available level) encryption or as part of a solution to decrypt TLS traffic.

Rationale:

The FISMA system (or SDM) must implement and support a technical capability to capture traffic traversing from systems within the FISMA system enclave(s) and detect malware within the content.

Related CMS ARS Security Controls include: SC-5 - Denial of Service Protection, SC-7 - Boundary Protection, SC-07(03) - Access Points, AC-17 - Remote Access, AC-17(3) - Managed Access Control Points, IR-4 - Incident Handling, IR-4(11) - Integrated Incident Response Team, SI-3 - Malicious Code Protection, SI-4 - System Monitoring.

Network Firewalls

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-22: Network Firewall Perimeter Requirements

As described in the CMS TRA Multi-zone architecture , the firewalls may be virtual or physical and may be part of a vendor service when the systems are implemented within the cloud (e.g. AWS Virtual Private Cloud (VPC)). The guidance below applies to both CMS data center and cloud implementations.

The SDM must:

• As detailed in business rule BR-CCIC-04, implement and maintain secured, separate enclaves or zones of systems and devices to implement the CMS-defined security architecture
• Incorporate a perimeter protections solution that includes:
  • Stateful inspection / application firewalls (i.e., full packet inspection) (as a minimum)
  • Configure firewalls for least privilege—block, deny, or drop by default (deny all, allow by exception)
  • Logging actions and/or other policy / rule hits
• Collect and analyze perimeter protections solution logs and security-relevant data, as described in Appendix A
  • Facilitate and maintain any firewall or routing changes necessary for security-relevant data and log collection

Rationale:

The FISMA system and SDM maintain secured, separated enclaves or zones of systems and devices as defined by the CMS TRA to provide the proper oversight, monitoring, and incident response capabilities. This requires the implementation of capabilities to protect the secured enclaves or zones within the CMS processing environment. The boundary separating each zone or enclave is protected by firewalls configured to deny by default and only allow by exception.

Each FISMA system and SDM is responsible for maintaining appropriate security and access control of its secure enclaves or zones and for implementing the appropriate tools and technologies to meet CMS and federal requirements.

Related CMS ARS Security Controls include: SC-7 - Boundary Protection, AC-4 - Information Flow Enforcement, AC-18 - Wireless Access, AC-20 - Use of External Systems, AU-6 - Audit Record Review, Analysis, and Reporting, CM-7 - Least Functionality, and CA-2 - Control Assessments.

Network Data Loss Prevention

Data Loss Prevention (DLP) provides consistent protections to block exfiltration of sensitive (especially privacy) data outside the organizational boundary as well as prevent inappropriate use (i.e., outside a documented routine use). DLP capabilities and functions include the following:

• Interpretation of System-Readable Policies and Formalized Connection Agreements – the ability for the DLP solution to instantiate security and privacy rules that will ensure compliance with cognizant Privacy Notices and applicable laws and regulations
• Exfiltration Alerts and Prevention – the ability for the DLP solution to monitor for data movement between systems initiated by a user, or even the system itself, and restrict or limit movement of the data based on rule sets or behavioral patterns. The solution is expected to report and alert on deviation from the defined boundaries or thresholds.
• Protection Orchestration – The ability for the DLP solution to interoperate within a suite of tools or be integrated within a Security Information and Event Management infrastructure that provides the required access control and monitors functionality across systems.

Some DLP solutions further enhance available protections for sensitive information, such as PII, by providing enhanced monitoring and recognition of sensitive information traversing interconnections to ensure:

• The exchange is restricted to authorized information
• The exchange is restricted to authorized purposes
• The exchange is restricted to authorized entities/users

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-27: Network Data Loss Prevention

The SDM must:

• Support compliance with regulations and mandates (e.g., Privacy Notice(s), CMS policy, and interconnection agreements) on sharing of CMS sensitive information on authorized endpoints and interconnections
• Provide audit trail information related to execution of DLP methods and the movement of data in a format compliant with CCIC needs
• Perform DLP using one or more of the following methodologies:
  • Encryption
  • Quarantine
  • Block
  • Notification
  • Allow with user justification
• Provide monitoring or DLP capabilities in accordance with one or more of the following:
  • Network monitoring, alerting on, and preventing the movement of data over the network using various network protocols (e.g., email, web, file transfer, and instant messaging) to detect or prevent data exfiltration

Rationale:

The DLP capability provides automated protections for sensitive information that can reduce the risk of unauthorized access. DLP will use fine-grained access control methodologies to restrict access to information to ensure that only authorized users, roles, and/or systems may access the information. DLP solutions can also provide prevention countermeasures for data in transit that can minimize the risk from unauthorized exfiltration (i.e., transmission of sensitive data to an unauthorized recipient).

Related CMS ARS Security Controls include: AC-3 - Access Enforcement, AC-4 - Information Flow Enforcement, CA-3 - Information Exchange, CA-3(6) - Supplemental: Transfer Authorizations, and SC-7 - Boundary Protection.

Lateral and Endpoint Protections

This topic describes the requirements for protections at the internal endpoints (IT assets within the data center / enclave) using network security endpoint protections, the proper use of encryption, and protections from insider threats.

Network Security Endpoint Protection

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-23: Network Security Endpoint Protection Capability

The SDM must:

• Implement and support a technical capability for performing network security endpoint protection of assets within the SDM’s data center (including assets within the data center secure enclave):
  • Establish a process / procedure (including defining required user and system accounts) for performing:
    • Continuous AV and anti-malware scanning
    • Periodic and scheduled sweeps of the environment as defined within the CMS ARS
    • Ad-hoc sweeps in response to notifications, alerts, and incident response direction from CMS
    • Forward collected (e.g., scan and sweep) data / results to the local SIEM system
    • Host-based IDS / host-based IPS
    • Encryption capabilities (e.g., the capability to encrypt endpoint storage and communications)
• Ensure time is synchronized across SDM assets with the CMS-approved time servers
• Customize received IOCs to address variations, differences, or other unique aspects of the data center environment
• Use the NSEP tool as a primary or backup mechanism for forensic data acquisition on the platforms on which the NSEP tool can be installed

The SDM network security endpoint protection capability must:

• Provide confidentiality and integrity protections that meet or exceed the minimal encryption requirements defined under the HHS Standard for Encryption of Computing Devices and Information.
• Provide proactive monitoring (e.g., using focused sweeps) for IOCs for assets, which must:
  • Report through alerts and logs
  • Ingest custom IOCs using the OpenIOC XML format
  • Ingest threat information in CMS and federally defined standard formats (i.e., STIX / TAXII)
• Use software-based agents on client platforms to perform data collection/acquisition
  • Quickly identify and isolate compromised systems, which includes mitigation procedures to remediate the compromise and secure the system from similar incidents
• Monitor the use of information system accounts and services that:
  • Monitor at the operating system and application level
  • Include COTS and custom applications
  • Provide automated monitoring (i.e., auditing) of account creation, modification, and termination (including disabling)
• Review and analyze auditable events collected from sources listed in Appendix A

For FISMA systems categorized under FIPS 199 as HIGH, the business owner / information system owner / SDM must:

• Incorporate an NSEP solution capable of performing automatic firewall blocking

Rationale:

NSEPs provide a HIDS / HIPS security suite to protect endpoints (e.g., servers in the data center) from compromise, detect incidents, manage vulnerabilities, and provide malicious code detection. NSEPs provide asset management (including allowlisting / denylisting ), encryption, firewalls, application firewalls, AV, and advanced investigation.

Related CMS ARS Security Controls include: SC-7 - Boundary Protection, RA-5 - Vulnerability Monitoring and Scanning, SI-4 - Information System Monitoring, AU-6 - Audit Record Review, Analysis, and Reporting, CA-2 - Control Assessments, AC-18 - Wireless Access, CM-8 - Information System Component Inventory, and IR-4(11) - Integrated Incident Response Team.

FIPS 140-2 or FIPS 140-3 Validated Encryption

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-24: FIPS 140-2 or FIPS 140-3 Validated Encryption Use

The SDM must:

• Ensure that encryption implemented meets or exceeds the minimal requirements defined under the HHS Standard for Encryption of Computing Devices and Information. The implemented level of encryption must be sufficient to mitigate the risk based on the sensitivity of the data. The actual physical data residing on the storage device within the tool or service (e.g., Oracle database) would require FIPS compliant encryption be enabled for the data at rest. For example, a server storing highly sensitive information, such as payroll data, whole disk encryption would not be sufficient to protect information at rest.
• Ensure encryption algorithms to protect transmitted information and information at rest meets or exceeds CMS encryption requirements (i.e., use of a FIPS 140-2 or FIPS 140-3 validated module).
• Ensure information system(s) protect the confidentiality and integrity of transmitted information and information at rest.
• Provide endpoint encryption that applies to information at rest (i.e., full disk, file/folder, and/or database level encryption) and information in transit.
• Provide support for collecting FIPS 140-2 or FIPS 140-3 security control attributes from hardware devices, software products, and configuration settings in support of the CMS and HHS continuous monitoring strategies.

Encryption is required to protect sensitive information in transit on both external and internal networks (within and across zones). The environment must use mechanisms capable of either decrypting transmitted data for security analysis or analyzing the security of the data before transmission or after receipt.

Use of non-encryption for information in transit within any cloud deployments must be fully documented within required security documentation and pre-approved by the AO.

Rationale:

OMB Memorandum M-17-12, Preparing for and Responding to a Breach of Personally Identifiable Information, January 3, 2017, mandates that agencies protect sensitive information. Examples of sensitive information include personally identifiable information (PII), protected health information (PHI), intellectual property, and other information that have a degree of confidentiality. Information sharing between the CCIC and the SDM secure enclave / boundary is through CMSNet. Traffic between the CCIC and the secure enclave is encrypted through an IPSec VPN tunnel to ensure the confidentiality and integrity of the data in transit.

Related CMS ARS Security Controls include: SC-7(24) Personally Identifiable Information, SC-8 - Transmission Confidentiality and Integrity, SC-28 - Protection of Information at Rest, SC-28(1) - Cryptographic Protection, AC-6 - Least Privilege, AC-20 - Use of External Systems, and AC-18 - Wireless Access.

Insider Threat Detection

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-25: Insider Threat Detection

The SDM must:

• Provide security awareness training on recognizing and reporting potential indicators of insider threat as part of the security awareness training program
• Address insider threat under the SDM incident handling capability
• Ensure insider threat policies, processes, and procedures are compliant with CMS-defined insider threat policies, processes, and procedures

Rationale:

An insider threat is a malicious threat to CMS, the FISMA system, or the SDM that comes from individuals within the organization, such as employees, former employees, contractors, or business associates. These individuals typically possess inside information on the organization’s security practices, data, and computer systems. HHS and CMS have implemented policies and procedures to aid in the detection of these individuals who present as insider threats.

Related CMS ARS Security Controls include: PM-12 - Insider Threat Program, , AT-2(2) - Insider Threat (Training), AT-2(3) - Social Engineering and Mining, IR-4 – Incident Handling, AT-2 - Literacy Training and Awareness, AT-3 - Role-Based Training, and PL-4 - Rules of Behavior.

Endpoint Data Loss Prevention

Data Loss Prevention at the endpoint provides consistent protections to block exfiltration of sensitive (especially privacy) data outside the organizational boundary as well as prevent inappropriate use (i.e., outside a documented routine use). DLP capabilities and functions include the following:

• Multi-Platform Capability/Multi-Database Capability – The capability of the DLP solution to be available regardless of underlying applications, databases, operating systems, or hardware platforms
• Interpretation of System-Readable Policies and Formalized Connection Agreements – The capability of the DLP solution to instantiate security and privacy rules that will ensure compliance with cognizant Privacy Notices and applicable laws and regulations
• Role / Attribute-Based Data Protection – The capability of the DLP solution to allow a system administrator to assign data protection schemes (encryption, application and system access controls, hashing, and substitution) to data elements in another system, associate those schemes to defined roles, and assign users to the roles
• Exfiltration Alerts and Prevention – The capability of the DLP solution to monitor for data movement between systems initiated by a user, or even the system itself, and restrict or limit movement of the data based on rule sets or behavioral patterns. The solution is expected to report and alert on deviation from the defined boundaries or thresholds.
• Protection Orchestration – The capability of the DLP solution to interoperate within a suite of tools or be integrated within a SIEM infrastructure in a manner that provides the required access control and monitor functionality across systems

Some DLP solutions further enhance available protections for sensitive information, such as PII, by:

• Providing enhancing monitoring and recognition of sensitive information traversing interconnections to ensure:
  • The exchange is restricted to authorized information
  • The exchange is restricted to authorized purposes
  • The exchange is restricted to authorized entities / users
• Restricting the ability for unauthorized users and services to create “archival” copies (e.g., copies and backups) on unauthorized devices and media

The business rule within this topic applies to all FISMA system and SDM data centers supporting CMS.

BR-CCIC-28: Endpoint Data Loss Prevention

The SDM must:

• Provide support DLP methods to protect data on endpoints (i.e., data at rest and data in use) using one or more of the following:
  • Content monitoring and inspection
  • Contextual monitoring and analysis
  • Metadata / tagging monitoring and inspection
• Support compliance with regulations and mandates (e.g., Privacy Notice(s), CMS policy, and interconnection agreements) on sharing of CMS sensitive information on authorized endpoints via authorized interconnections
• Provide audit trail information related to execution of DLP methods and the movement of data in a format compliant with CCIC needs
• Perform DLP using one or more of the following methodologies:
  • Encryption
  • Quarantine
  • Block
  • Notification
  • Allow with user justification
• Provide a monitoring or DLP capabilities in accordance with one or more of the following:
  • Endpoint monitoring, alerting on, and preventing use or manipulation of sensitive data by end-user activity (e.g., copy, paste, save, open, print operations, and screen captures) to detect or prevent data exfiltration
  • User and/or system monitoring to alert and prevent unauthorized use, storage, and transmission of privacy data by a user and/or system that has other legitimate access to sensitive data

Rationale:

The DLP capability provides automated protections for sensitive information that can reduce the risk of unauthorized access. DLP will use fine-grained access control methodologies to restrict access to information to ensure that only authorized users, roles, and/or systems may access the information. DLP solutions can also provide prevention countermeasures for data in transit that can minimize the risk from unauthorized exfiltration (i.e., transmission of sensitive data to an unauthorized recipient).

Related CMS ARS Security Controls include: AC-3 - Access Enforcement, AC-4 - Information Flow Enforcement, CA-3 - Information Exchange, CA-3(6) - Supplemental: Transfer Authorizations, and SC-7 - Boundary Protection.

Future CDM Considerations

CDM Asset Management is discussed above and represents the initial phase of the CISA Continuous Diagnostics and Mitigation (CDM) Program. DHS is continuing to develop the CDM Program and is expanding it to include other capabilities described in this topic. See CDM Technical Capabilities, Volume Two, Requirements Catalog, Version 2.5 as well as the GSA Continuous Diagnostics and Mitigation Tools website.

CDM for Identity and Access Management

CDM for Identity and Access Management focuses on monitoring user privileges and activities to improve infrastructure integrity through the following requirements:

• TRUST – Provide access control management to ensure there is trust in the people who are granted access. This is also known as Identity, Credential and Access Management (ICAM).
• BEHAVE – Provide security-related behavior management to help detect when behaviors change in an unanticipated manner, which is often a sign of malicious activity
• CRED – Provide credential and authentication management to ensure only authorized users have access to the information systems and data

CDM for Network Security Management

CDM for Network Security Management focuses on boundary protection and event management as key components of information system and information security life-cycle management. Network Security Management will encompass the following requirements:

• Boundary Protection – Ensure that traffic to and from the FISMA system (i.e., network, physical, and virtual boundaries) does not compromise security
• Plan for Events – Ensure that resources are in place to deal with both routine and unexpected events that can compromise security. These include cybersecurity incidents and contingencies (Acts of God) such as floods and earthquakes.
• Respond to Events – Ensure that responses are as planned for both routine and unexpected events that can compromise security and require a response to maintain functionality and security. Events include actual cybersecurity incidents and contingencies (Acts of God).
• Generic Audit/Monitoring – Identify routine and unexpected events that can compromise security. These include actual cybersecurity incidents and contingencies (Acts of God).
• Document Requirements, Policy – Ensure that documentation and policy processes fully integrate the concepts of information security
• Quality Management – Ensure that quality management processes fully integrate the concepts of information security
• Risk Management – Implement operational security (risk management) initially through risk scores and later supplemented by Level 3 maturity metrics

CDM for Data Protection Management

CDM for Data Protection Management focuses on capabilities that help to protect data. Data Protection Management will encompass the following requirements:

• Data Discovery – Ensures consistent identification of data assets across the organization for processing, storing, and transmitting information at all sensitivity levels
• Data Protection – Ensures protection of the data itself. Data protection includes the application of cryptographic methods as well as the ability to hide sensitive data field values using data masking or obfuscation methods. This is in addition to the standard method of controlling access privileges for sensitive information.
• Data Loss Prevention – Ensures consistent protection to block inappropriate exfiltration of sensitive (especially privacy) data outside the organization and prevent unauthorized use (i.e., outside of documented routine use) both internally and externally
• Data Breach / Spillage Mitigation – Ensures implementation of and adherence to policies, processes, and procedures that an organization develops in response to an unauthorized loss of organization data
• Information Rights Management – Ensures access to enterprise information (e.g., documents and files) is managed. IRM solutions provide fine-grained and identity-aware protections that are persistent with the data.

Ongoing Assessment and Authorization

Ongoing assessment and authorization, which may be referred to as continuous monitoring, is part of the overall Risk Management Framework (RMF) for information security. The ongoing assessment and authorization process will determine, using as much automation as possible, whether the set of deployed security controls for the FISMA system remains effective despite planned and unplanned changes that occur in the FISMA system and its environment over time.

The ongoing assessment and authorization program is based on NIST SP 800-137, Information Security Continuous Monitoring for Federal Information Systems and Organizations, NIST SP 800-37R2 (RMF), Risk Management Framework for Information Systems and Organizations and OMB A-130 Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource. Ongoing assessment and authorization produce greater transparency of the security posture of the FISMA system, which facilitates timely risk management decisions. Security-related information collected through continuous monitoring processes is used to dynamically update the FISMA system’s SSP, Information Security Risk Analysis, and POA&Ms. These updated documents, as well as the real-time operational feeds, enhance the accuracy of the security authorization package while simultaneously providing information about security control effectiveness. Through these documents, CMS can make timelier informed risk management decisions and better address changing threats and conditions.

System and Devices Logs and Data Sources

To support CMS incident detection and response capabilities, meet various CMS reporting needs, and comply with HHS and federal security information logging and analysis requirements, CMS requires that specific log data be collected by the SDM from systems, infrastructure components, and other data sources.

The SDM must collect this log data in a local SDM SIEM instance that is compatible with both CCIC SIEM platform requirements and CMS CDM tools to enable integration with and secure log transport to these CMS monitoring platforms. The CCIC SIEM platform and CDM toolsets provide a variety of software agents and collection mechanisms to collect and securely transport logs from various enterprise systems and devices. Integration and monitoring of these collected logs files require close collaboration with the CCIC and CDM teams. The SDM also must follow audit requirements (AU and CM controls) within CMS ARS, especially settings for event generation cited in AU-2 and AU-12 as well as applicable configuration settings (e.g., STIG and USGCB) directed by CM-6 controls. SDM contractors must work with the CCIC and CDM teams to integrate the corresponding data feeds / logs to ensure secure data in transit and at rest.

For specific information regarding integration with the CMS CCIC SIEM and CDM tools, and which logs are to be provided to each platform, send an email to CMS - ISPG Logs Onboarding mailbox to receive the latest CMS requirements. (CMS - ISPG-DCTSO may be used as an alternate)

The following topics provide a representative baseline of the types of CMS-specific security data that must be collected and forwarded to a local SDM SIEM and in turn integrated into the CCIC SIEM Platform and/or CDM toolsets. The information in the topics below is intended to provide overall guidance but does not provide the complete list of required log or other monitoring data as requirements change over time. Use the process noted above to obtain the details on current logging requirements

Encryption

The suite of tools implemented by the CCIC and required for implementation at the SDM is designed to monitor unencrypted traffic, log files, and data sources.

The SDM is required to:

• Ensure that any monitored traffic, logs, or data sources are available (e.g., through submitted queries) to CCIC security tools in unencrypted formats:
  • For applications that use TLS (highest available level) for encryption in transit, the monitoring point must occur after the point at which TLS traffic has been unencrypted.
  • If the TLS (highest available level) traffic occurs in an end-to-end fashion, then the contractor must implement the infrastructure necessary to decrypt that traffic (e.g., Metronome).
• Protect logs and/or data sources in transit across networks between the point of monitoring and the tools consuming them through either of the following methods:
• Encrypt logs during transmission
• Provide logical and physical segregation from normal traffic via an out-of-band solution, dedicated VLAN or subnet, or a combination thereof

SIEM forwarders typically have the required encryption capability built in and should be used where technically possible. Once at the destination, log data should be unencrypted and processed by the SDM SIEM platform. FIPS 140-2 or FIPS 140-3 compliant encryption should be enabled and configured within the SDM SIEM platform (not this may not be enabled by default)

Domain Name Service Servers

The US-CERT, other government agencies, incident response teams, the Department of Defense, and commercial vendors frequently publish lists of domains and IP addresses of websites that host malware, botnets, command and control networks, and other malicious content. Access to these known sites and/or Domain Name System lookups for these sites is a very strong indicator that the internal HHS system is already infected or compromised by malware. Access to DNS information will provide an early indicator of a successful compromise or intrusion, which allows the system to be quickly identified and taken offline before data can be destroyed, compromised, modified, or exfiltrated.

Some organizations have had success in monitoring or data mining DNS and Microsoft Active Directory (AD) logs for consecutive DNS lookups, which indicate internal compromises reaching out to establish footholds on other systems. DNS logs are also used for detection of DNS cache poisoning and DNS redirect attacks. For DNS logs to have maximum value, the DNS logs must be directly attributable and traceable to the originating host system.

The SDM must collect DNS logs according to the following requirements:

• DNS logs must be directly attributable and traceable to the originating host system for all systems that make DNS queries within the SDM.
• If a caching architecture is implemented in the environment, CMS requires logging data from the primary DNS resolvers for the environment(s) as well as any upstream caching servers within the data center.
• Configuration data from the systems performing DNS lookups and/or resolution must be provided to CMS on request.

Email Servers

Email servers accept, forward, deliver, and store electronic messages between email clients. Email messages typically consist of a message header and message body. Email server logs contain information that can be used to trace spear phishing attacks and detect malware attachments sent by email.

US-CERT, the Department of the Treasury, and other government agencies publish daily and weekly advisories on email phishing attacks that can be used to analyze email logs.

The SDM must collect email server logs according to the following requirements:

• If systems within the SDM’s security boundary use email, the email logs must be made available to CMS as a data source for monitoring.
• Any email filtering systems must be able to provide security-related logging data to CMS as a data source.
• Configuration data from the systems sending and/or processing email must be provided to CMS on request.

Proxy / URL Filters

A URL filter is a form of proxy server that acts as a go-between for requests from clients seeking hypertext transfer protocol (HTTP) resources from a remote web server. A URL filter server can block access to unsafe websites.

URL filter servers produce logs that track access to known malware hosting sites and URL block list access. These logs can assist a security analyst in identifying compromised hosts on the local network.

The SDM must collect and forward proxy / URL logs according to the following requirements:

• Logging data from these systems must be provided in such a fashion that the full session information can be captured with the following attributes (at a minimum):
  • Attribution to the originating host system, including IP address and HTTP header information
  • Indication of whether or not the request was served out of a local cache
  • Indication of whether the request was blocked or allowed and what category (e.g., social networking, news media, and shopping) was associated with the request. Category classes provide granular visibility into the type of web traffic traversing a given network.
  • Attribution information for the involved user (if the request involved user interaction)
• Read-only access to the reporting, alerting, and administrative configuration features must be provided.
• Additional logging fields within the tool must be turned on should the logging fields be required for security monitoring purposes as determined by ISPG. Table - Example URL Filter Fields provides an example list of URL filter fields that should be captured for monitoring.
• Proxy/URL filtering implementation must allow for customized categories and rules to respond to notifications and/or alerts from various sources.

Firewalls

Firewall log data is a vital part of network security, because the firewall is the first line of defense against unauthorized external access. Firewall logs generate data that can be useful in identifying security events. Port scans, operating system identification, denial of service (DoS) attacks, network mapping attempts, blocked network address access attempts, and inbound perimeter breach attempts are examples of security incidents that can be detected while analyzing firewall logs. Firewall logs can also detect instant messaging, peer-to-peer (P2P) file sharing traffic through HTTP, and firewall policy changes as well as outbound access attempts to blocked URLs, network addresses, and listed malicious websites.

The SDM must collect firewall logs according to the following requirements:

• Logging data from firewalls must be provided for any firewalls that protect the perimeter or any segment of the SDM systems.
• Logging data must:
  • Be attributable to the originating system, except where internal proxies are routing traffic for hosts internal to the network
  • Log blocks, denies, drops, or other policy / rule hits
• Read-only access to Layer-3 devices, the configuration repository, aggregation server, or configuration management database must be provided on CMS request for analysis.
• The use of additional logging capabilities within the firewall systems may be required, depending on the nature of the operational environment and the monitoring requirements ISPG determines.

Intrusion Detection / Prevention Systems

IDS / IPS logs are valuable tools for detecting various network attacks such as port scans, remote access attempts, malicious remote commands, and executed commands. IDS / IPS logs contain event data that may be used for forensics or in a correlation engine within a SIEM solution. Information on user login failure attempts, Internet messaging traffic, email communication, and P2P traffic is useful in network security monitoring and trend analysis.

The SDM must collect IDS / IPS logs according to the following requirements:

• IDS / IPS logging/alerting data must be provided, and include (at a minimum):
  • The rule that triggered the alert (by reference identifier or the full rule itself)
  • Category of the rule and any associated risk rating / scoring data
• IDS / IPS implementations must (at a minimum):
  • Allow for implementation of customized signatures in response to notifications and/or alerts from various security entities
  • Provide the option to automatically save an associated PCAP for triggered alerts that ISPG requests in support of incident response activities or for limited retention durations upon CMS request
  • Provide read-only access to configuration data upon CMS request or the configuration files themselves via a centralized network management facility

DHCP Servers

Dynamic Host Configuration Protocol is a server service that automatically distributes network addresses to requesting clients on the local access network. DHCP logs record the mapping of network addresses to computer names similar to how a phonebook maps names to telephone numbers.

DHCP server logs provide time-stamped mapping of client network addresses to computer hostnames for desktop and laptop network activity tracking.

The SDM must collect DHCP logs according to the following requirements:

• Baseline activity logging must be provided, including reservation and host details as requested by CMS.
• A naming convention for systems on the network must be provided to CCIC and updated with changes no less often than once every 90 days.
• Configuration data from the DHCP servers must be provided to CMS on request but no less often than once every 90 days.

Network / Port Address Translation

Network Address Translation / Port Address Translation logs are useful for identifying the originating system or node on an internal network when an IDS or another entity detects a security event outside the network.

The SDM must collect NAT / PAT logs according to the following requirements:

• Any routers or other network infrastructure performing NAT / PAT functions must provide logging data sufficient to attribute traffic to originating hosts for correlation to other network and security data.
• Configuration data from the devices performing NAT / PAT functions must be provided to CMS on request, but no less often than once every 90 days.

Antivirus

Antivirus server logs contain log entries showing the date on which a virus scan detected a virus, the type of virus (e.g., Trojan, spyware, and other forms of malware), the filename, where the virus was found, and the action taken by the scan (e.g., cleaned or quarantined). The AV server logs also contain AV client status information that can be used to identify vulnerable clients on a network.

The SDM must collect antivirus logs according to the following requirements:

• Data related to antivirus state on the host and management server must be provided, including:
  • Current executable version
  • Current rules version
• Logging and data related to activities on the host and management server must be provided, including:
  • Most recent scan
  • Any alert, quarantine, cleaning, or other intervention activity
• Configuration data from host or management server must be provided to CMS on request but no less often than once every 90 days.

Microsoft Active Directory Security Events

Microsoft AD security events contain information about logins to Microsoft systems—user ID, date, time, and location. This data can be used both proactively and forensically. Proactively, the data can aid in the detection of unauthorized user activity: unauthorized system, application, or data access; failed or brute force login attempts; misconfigured application installations; unauthorized password changes; and user account creation. Misuse of administrative login credentials at unauthorized locations, dates, time, or systems is a strong indication of an intruder compromise.

Forensically, access to AD security logs is helpful in post-incident analysis to determine who did what, when, and how after an intrusion has been detected. One of the first steps an intruder usually takes is to delete or remove security event logs from the compromised system. Storing the logs on a secure remote system removes this ability from the intruder. Some organizations have had success in monitoring or data mining DNS and AD logs for consecutive DNS lookups, which indicates internal compromises reaching out to establish footholds on other systems.

The SDM must collect AD logs according to the following requirements:

• AD logging requirements are heavily dependent on the role of AD within the architecture. ISPG may require additional logging data beyond the relevant minimum baseline configuration data depending on the operational environment.
• Configuration data from the AD systems must be provided to CMS on request but no less often than once every 90 days.

Microsoft Windows Security and System Events

Microsoft Windows security events contain information about local logins to Microsoft systems—user ID, date, time, and location. This data can be used both proactively and forensically. Proactively, the data can aid in the detection of unauthorized user activity: unauthorized system, application, or data access; failed or brute force login attempts; misconfigured application installations; unauthorized local password changes; and local user account creation. In addition, these logs can indicate changes to local file, registry, or service permission or ownership changes.

Forensically, access to Windows security and system logs is helpful in post-incident analysis to determine who did what, when, and how after an intrusion has been detected. One of the first steps an intruder usually takes is to delete or remove security event logs from the compromised system. Storing the logs on a secure remote system removes this ability from the intruder.

The SDM must collect Windows system and security logs according to the following requirements:

• Windows logging requirements are heavily dependent on the role of the Windows system within the architecture. ISPG may require additional logging data beyond the relevant minimum baseline configuration data depending on the operational environment.
• Configuration data from the Windows systems must be provided to CMS on request but no less often than once every 90 days.

UNIX / Linux Security Logs

UNIX / Linux security-related logging information provides a critical stream of security data for auditing, monitoring, and incident response. A wide variety of logging services is available, depending on the UNIX or Linux variant used, although most use syslog or a near equivalent.

The SDM must collect UNIX / Linux security logs according to the following requirements:

• UNIX / Linux logging requirements are heavily dependent on the role of UNIX / Linux within the architecture. ISPG may require additional logging data beyond the relevant minimum baseline configuration data depending on the operational environment.
• Configuration data from the UNIX  /Linux systems must be provided to CMS on request but no less often than once every 90 days.

Mainframe Security Logs

Mainframe systems must use a security service that can output its events through a facility such as syslog. These log files can be used to audit activity and provide system-level correlation for network logs and other security data. With the rise of virtualized environments housed on mainframes, the level of detail and scope of security logging is normally site specific outside of established system baseline requirements.

The SDM must collect mainframe security logs according to the following requirements:

• In addition to the logging data required in the applicable baseline configuration standard for the platform, ISPG may require additional logging data from the mainframe security facilities and monitoring tools in use.
• Configuration data from the mainframe must be provided to CMS on request but no less often than once every 90 days.

Netflow or Equivalent

NetFlow is an industry-standard protocol that a firewall can use to export statistics about the IP traffic on its interfaces. The SDM must provide the NetFlow data or its equivalent based on the brand of router in use. Netflow is the statistical data provided by Cisco routers. It describes network connections and communications. Comparable “Netflow” data from competing vendors (e.g., Juniper) must also be provided if deployed within an SDM. It is analogous to telephone call logs, showing the two endpoints, time of call, and duration. Netflow does not contain information about what occurred during a call. Intrusion detection systems can use this data to look for suspicious network traffic that hides within normal network communications. Multiple systems sending small packets to the same endpoint on a regular, repetitive timeline is an indicator of compromise. Examples are botnets, command and control networks, or backdoor Trojans calling “home” for instructions. Netflow data can also be matched to the same lists of malicious sites described in the DNS usage log.

The SDM must collect Netflow data according to the following requirements:

• Raw or unprocessed Netflow data from network devices must be provided for integration.
• Internal device Netflow must be part of the architecture, because internal network movement cannot be observed from perimeter device Netflow data.

Routers / Switches

Time-stamped router audit logs provide a trail of user connectivity data, including router configuration changes. Logging of failed logon attempts can indicate Telnet and SSH-based attacks on the network infrastructure.

The SDM must collect router / switch / load balancers audit logs according to the following requirements:

• Configuration data from the routers, switches, and load balancers must be provided to CMS on request.
• Configuration data must be provided to the CCIC for contextual risk management and threat identification application analysis.

Authentication Servers

Authentication servers provide centralized authentication, limited authorization, and account management for computers to connect and use a network service. Authentication server logs are used to detect unauthorized logon attempts and unusual logon successes (e.g., user logons when a user is known to be on vacation or outside of scheduled hours).

The SDM must collect authentication server logs according to the following requirements:

• All events identified in CMS ARS Security Control AU-2, Event Logging, must be logged.
• All logon and logoff events (failed, successful), including suspicious events, must be logged.
• All logon attempts must be logged.
• Account lockouts and unlocks must be logged.
• Account revokes / terminations must be logged.
• Account creation / deletions must be logged.
• Account use of escalated privileges (assigned and inherited), including Windows (Administrator, Domain Admins, Service Accounts, Run As accounts) and Linux (Sudo, etc.), must be logged.

Virtual Private Network Servers

A virtual private network server provides a secure, private communication tunnel between two or more devices across a public network.

VPN server logs track security-related events, such as unauthorized VPN access attempts, VPN client logon failures, and remote file access attempts and successes. VPN server logs provide a time-stamped log of VPN user connectivity, including file names and the amount of data transferred between VPN client and a remotely accessed resource. These logs can provide a security analyst with useful forensics data and help to provide a detailed view of a user’s session activity.

The SDM must collect VPN server logs according to the following requirements:

• All events identified in CMS ARS Security Control AU-2, Event Logging, must be logged.
• Activity logs must include:
  • User / system attribution
  • Connect / disconnect times
  • Data transfer statistics
  • Remediation / Network Access Control activities related to the host
  • Host information
  • Link information
• Lists of subnets assigned to VPN via DHCP or statically must be updated no less often than once every 90 days and provided to the CCIC.

Vulnerability Scanners

A vulnerability scanner is software designed to scan computers and use a vulnerability database to scan applications, operating systems, or networks for vulnerabilities. Vulnerability scanners produce data that allow a security analyst to reduce false positives, enabling the analyst to concentrate on real attacks.

Vulnerability logs contain patch status data and missing software update information that provides additional value when combined with inventory and incident management systems, and form part of the foundation for meeting emerging OMB-mandated continuous monitoring requirements.

The SDM must collect vulnerability scanner data according to the following requirements:

• Notify CCIC of the IP addresses and expected behavior of vulnerability scanners to avoid false positives.
• Provide log data from requested or routine usage of the vulnerability scanners in support of incident response, monitoring, or other security requirements.
• Provide relevant results of any additional vulnerability scans not directly tied to current scans from the CMS enterprise vulnerability scanning platform within the SDM. The CCIC may gain additional information for monitoring purposes from vulnerability scanning of internal SDM environments through tools other than those part of the CMS enterprise vulnerability scanning platform.

Wi-Fi

The SDM and CMS can generate information for monitoring activity on CMS’s wireless networks from wireless access points within the SDM used to access CMS capabilities.

The SDM must collect Wi-Fi data according to the following requirements:

• Notify CCIC of the IP addresses and expected behavior of hosts accessing the Wi‑Fi network to avoid false positives.
• Provide log data from requested or routine usage of the access points in support of incident response, monitoring, or other security requirements.

Host-Based Sensing

The following artifacts are considered vital to detecting malicious adversarial behaviors on an enterprise network:

• Process Data. The following artifacts should be collected for process STARTs and TERMINATES:
  • Computer name, user, command line, executable name, process ID (PID), process image path, MD5 and Secure Hash Algorithm 2 (SHA2) w/256-bit digest (SHA256) hash of process, parent process, parent process ID (PPID), parent process image path, system ID (SID), and the signer of the executable
• Process Threads (injection). The following artifacts should be collected for process threads:
  • Computer name, user, source PID/target ID (TID), Target PID/TID, stack base, stack limit, start address, start function, start module, start module name, sub process tag, user stack base, and user stack limit
• File Data. The following artifacts should be collected while monitoring file activity on a system, including CREATE, DELETE, MODIFY, READ, WRITE, and ATTRIBUTE MODIFICATION:
  • Computer name, user, company name, create time, file name, file path, fully qualified domain name (FQDN), image path of the process that created the file, PID of the process, parent process PID and image name, MD5 and SHA256 of file created, and the signer
  • Base Address (for Drivers only)
  • Monitor any file creations in specific Windows vital folders (windows, system32, syswow64, etc.)
  • Monitor file creations of executable file types in any location (exe, zip, zipx, msi, py, ps1, scr, dll, cmd, bat, rar)
• Registry Data. The following artifacts should be collected for any registry activity, including CREATE/DELETE/MODIFY KEY/VALUE:
  • Computer name, user, key name, value name, data, hostname, and value type
  • Monitoring the registry can cause volume issues, because registry edits occur on a regular basis in Windows. If a reasonable way of tracking registry activity is not possible, then at a minimum watching all Service and Autorun keys is recommended.
• Service Data. The following artifacts should be collected for changes to any service on the system being modified, deleted, or created:
  • Computer name, user, service name, command line, executable making the change, FQDN, and image path of the executable
• Modules Installed. The following artifacts should be collected for any module that is installed on a system:
  • Computer name, user, base address, FQDN, MD5 and SHA256 hash of module, module name, module path, PID, signer, and TID
• User Sessions. The following artifacts should be collected for user sessions logging into a system:
  • Computer name, user, destination/source IP (remote logons), destination / source port (remote logons), logon id, logon, type, and the privileges associated to the logged on user
• Network Data. The following artifacts should be collected for network connections originating or connecting to a network node:
  • Computer name, user, destination / source IP and port, destination / source hostname, destination / source FQDN, start time, end time, flags, image path of process responsible for the connection, PID and PPID of process, packet count, MAC address, protocol, and proto info
• Others
  • Monitor for windows hooking
  • Collect Windows Management Instrumentation (WMI), security, and system logs

Monitoring file activity can cause volume issues, because Windows is constantly creating temp files and other artifacts that would be considered false positives. If a reasonable plan cannot be devised to account for this, then at a minimum the following actions should be taken to monitor file activity on a system:

Business Application Logic

Business application logs give insight into any unusual business application activity, as identified by the business application owner in response to auditable event types identified under CMS ARS Security Control AU-2. Often, the application developer custom codes these event logs, and the event logs may rely in part on events found in web server access logs, application service activity logs, and database transaction logs. The application operator uses these logs to understand problems in logic and workflow through the application, but they also help users or administrators to detect inappropriate use of the application. Security staff use these logs to help detect attacks such as SQL injection or cross-site scripting.

The SDM must collect application-coded logs designed to comply with the following types of auditable events identified in CMS ARS Security Control AU-2, Event Logging:

• Application Modifications (e.g., adding, removing, or modifying application items, successful by application admins, and failed attempts by application users)
• Application alerts and error messages (e.g., logic / capacity / loss errors and logic high-processing alerts)
• Configuration changes (e.g., successful changes or failed attempts to change application parameters and preferences)
• Reading, Modification, or Printing of sensitive information (e.g., successful or failed actions against sensitive data as seen by the application logic performed by application users and administrators)
• Account creation, modification, or deletion (e.g., adding or removing application users or application administrators)

Other Feeds or Logs

Additional data feeds may also be required (and determined in coordination with CMS) depending on the nature of the architecture and work performed by the SDM. CCIC may place additional monitoring assets and capabilities in place to monitor the raw data at those key aggregation points, as ISPG determines necessary.

The SDM must collect additional data feeds as needed by CCIC including, but not limited to, log events and alerts from databases, application servers and hypervisors.

Access Control and Identity Management Introduction

Introduction

This chapter presents a general overview of CMS practices and services for access controls and identity management for CMS enterprise environments. Specific guidance on access controls and identity management may be found in the CMS ARS, the CMS Information Systems Security and Privacy Policy, and in the Business Rules topic of this chapter.

Relevant Documents

This chapter is not all inclusive. It complements and incorporates CMS’s existing policies, standards, and procedures, thereby offering an architectural view of the standards. See CMS Information Security and Privacy Overview. Where there are conflicts, the following standards, and any successor documents, will take precedence:

• CMS Acceptable Risk Safeguards (ARS)
• CMS Business Partners System Security Manual, CMS Pub 100-17
• CMS Security and Privacy Handbooks
• CMS Access Control Handbook

Other related guidance includes:

• FIPS PUB 201-3: Federal Identity Verification (PIV) of Federal Employees and Contractors – January 2022

Key Concepts and Definitions

To ensure the audience fully understands the conceptual foundation for this guidance, the following terms, definitions, and explanations are presented in a sequence that progressively build the foundation for the guidance. The Glossary defines additional terms for the reader’s benefit.

Identity Management

The primary goal of Identity Management is to establish a trustworthy process for assigning attributes to a digital identity and to associate that identity to an individual. Identity management includes the processes for maintaining and protecting the identity data of an individual over the life cycle of the digital identity.

Privilege Administration

The process of establishing and maintaining the entitlement or privilege attributes that comprise an individual’s access profile. Privilege Administration processes entail reviewing, assigning, and removing privileges over time as an individual’s access needs change.

At CMS, business application owners are responsible for implementing user Privilege Administration processes for their applications.

Assignment and administration of privileges within an application, such as application-specific roles and role-based access controls, are not supported by CMS enterprise infrastructure systems, and are the responsibility of the application owner.

RBAC Profile (also known as Job Code or Role)

Also known as Enterprise User Administration (EUA) Job Codes, Production Control Identifiers, Business Profiles, or RBAC (Role-Based Access Control) Profiles. Profiles are used to control which applications a given user has been authorized to access. Each UserID may be assigned zero or more Profiles, and each Profile may impart to the UserID zero or more Access Control Entitlements (ACE). A Profile assigned to a UserID indicates that user is authorized to authenticate (i.e., log into) to a given application or set of applications. Please refer to Privilege Administration and Enterprise User Administration below for additional discussion of Profiles and Roles.

User Certification

The periodic review of a user’s authorization status. The process of certification verifies the user is still an active user, is still authorized to use CMS systems, has received security awareness training, and has reviewed and accepted the CMS Privacy Statement. User Certification is, at minimum, an annual requirement.

Credential Service Provider (CSP)

Not to be confused with Cloud Service Provider (also CSP) used elsewhere in the CMS TRA, a Credential Service Provider is a trusted entity that issues or registers subscriber authenticators and issues electronic credentials to subscribers. A CSP may be an independent third party or issue credentials for its own use.

E-Authentication Assurance Levels

Federal information systems are required to incorporate information security controls to protect the information systems supporting their operations and missions. CMS is required to ensure the adequate protection of its information assets and must meet a minimum level of information security.

Previously, CMS guidance on e-authentication assurance levels aligned with NIST SP 800-63-2, Electronic Authentication Guideline, August 2013, and OMB Memorandum 04-04, E-Authentication Guidance for Federal Agencies, and defines four (4) levels of assurance (LOA) for electronic transactions in terms of the consequences of the authentication errors and misuse of credentials:

• Level 1 affords little or no confidence in asserted identity’s validity. Identity proofing relies on the user’s own assertions. The authentication token may be a UserID and password.
• Level 2 provides some confidence in the asserted identity’s validity. Identity proofing requires verifying the individual’s government-issued ID or a financial account and other information. The authentication token may be a UserID and password.
• Level 3 provides high confidence in the asserted identity’s validity. Identity proofing requires verifying the individual’s government-issued ID and a financial account and other information. Multi-factor authentication is required.
• Level 4 provides very high confidence in the asserted identity’s validity. In-person proofing is required. Multi-factor authentication is required.

NIST has superseded this definition of e-authentication assurance levels. NIST SP 800-63-3, Digital Identity Guidelines, June 2017 and updated March 2020, supplements OMB Memorandum 19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access ManagementAuthentication Guidance for Federal Agencies, and defines three (3) components of assurance for electronic transactions in terms of the consequences of the authentication errors and misuse of credentials. These guidelines provide mitigations of an authentication error’s negative impacts by separating the individual elements of identity assurance into discrete, component parts. For non-federated systems, agencies select two components, referred to as Identity Assurance Level (IAL) and Authenticator Assurance Level (AAL). For federated systems, agencies select a third component, Federation Assurance Level (FAL).

These guidelines retire the concept of a level of assurance (LOA) as a single ordinal that drives implementation-specific requirements. The components of identity assurance detailed in these guidelines are as follows:

• IAL refers to the identity proofing process.
• AAL refers to the authentication process.
• FAL refers to the strength of an assertion in a federated environment, used to communicate authentication and attribute information (if applicable) to a relying party (RP). FAL is not used at this time per CMS policy.

The separation of these categories provides agencies flexibility in choosing identity solutions and increases the ability to include privacy-enhancing techniques as fundamental elements of identity systems at any assurance level.

CMS has not yet adopted the new e-authentication assurance components in their guidance documents. Because the new components provide functional separation and clarity when describing e-authentication, this release of the CMS TRA uses both the current four (4) levels of assurance (LOA) and the new e-authentication assurance components in its narrative describing identity management and authentication functions and services. This release does not provide a mapping between the current four (4) levels of assurance and the new e-authentication assurance components.

NIST SP 800-63A Enrollment and Identity Proofing

NIST SP 800-63A addresses how applicants can prove their identities and become enrolled as valid subscribers within an identity system. It provides requirements by which applicants can both identity proof and enroll at one of three different levels of risk mitigation in both remote and physically present scenarios.

NIST SP 800-63A sets requirements to achieve a given IAL. The three IALs reflect the options agencies may select from based on their risk profile and the potential harm caused by an attacker making a successful false claim of an identity. The IALs are as follows:

• IAL 1. There is no requirement to link the applicant to a specific real-life identity. Any attributes provided in conjunction with the authentication process are self-asserted or should be treated as such.
• IAL 2. Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL 2 introduces the need for either remote or physically present identity proofing. Attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.
• IAL 3. Physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained representative of the CSP. As with IAL 2, attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.

NIST SP 800-63B Authentication and Lifecycle Management

For services in which return visits are applicable, a successful authentication provides reasonable risk-based assurances that the subscriber accessing the service today is the same as who accessed the service previously. The robustness of this confidence is described by an AAL categorization. NIST SP 800-63B addresses how an individual can securely authenticate to a CSP to access a digital service or set of digital services.

The three AALs define the subsets of options agencies can select based on their risk profile and the potential harm caused by an attacker taking control of an authenticator and accessing agencies’ systems. The AALs are defined in SP 800-63B as follows:

• AAL 1. AAL 1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL 1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.
• AAL 2. AAL 2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL 2 and above.
• AAL 3. AAL 3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL 3 is based on proof of possession of a key through a cryptographic protocol. AAL 3 authentication requires a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device may fulfill both these requirements. In order to authenticate at AAL 3, claimants are required to prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.

NIST SP 800-63C Federation and Assertions

NIST SP 800-63C provides requirements when using federated identity architectures and assertions to convey the results of authentication processes and relevant identity information to an agency application. In addition, this volume offers privacy-enhancing techniques to share information about a valid, authenticated subject and describes methods that allow for strong multi-factor authentication (MFA) while the subject remains pseudonymous to the digital service.

The three FALs reflect the options agencies can select based on their risk profile and the potential harm caused by an attacker taking control of federated transactions. The FALs are as follows:

• FAL 1. Allows for the subscriber to enable the Relying Party (RP) to receive a bearer assertion. The assertion is signed by the Identity Provider (IdP) using approved cryptography.
• FAL 2. Adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party who can decrypt it.
• FAL 3. Requires the subscriber to present proof of possession of a cryptographic key referenced in the assertion in addition to the assertion artifact itself. The assertion is signed by the IdP and encrypted to the RP using approved cryptography.

Identification and Authentication

The topics below provide a high-level overview of CMS Identity and Authentication (IA) policies and services. For more specific information, see Business Rules and Recommended Practices.

In addition, please consult the CMS ARS guidance on the Identification and Authentication  policy family for detailed guidance.

The primary goal of Identity Management is to establish a trustworthy process for assigning attributes to a digital identity and to associate that identity to an individual. Identity management includes the processes for maintaining and protecting the identity data of an individual over the life cycle of the digital identity. Directory services provide applications with access to repositories of digital identities and associated attributes, as well as services and data required to authenticate user passwords and control access to application resources.

CMS, or a CMS-authorized third party, acts as a Credential Service Provider that issues or registers subscriber authenticators and issues electronic credentials to subscribers. According to NIST SP 800-63, an individual or applicant opts to be identity proofed by a CSP. If the applicant is successfully proofed, the individual is then termed a subscriber of that CSP. The CSP establishes a mechanism to uniquely identify each subscriber, register the subscriber’s credentials, and track the authenticators issued to that subscriber. The subscriber may be given authenticators at the time of enrollment, the CSP may bind authenticators the subscriber already has, or they may be generated later as needed. Subscribers have a duty to maintain control of their authenticators and comply with CSP policies in order to maintain active authenticators. The CSP maintains enrollment records for each subscriber to allow recovery of authenticators, for example, when they are lost or stolen. See NIST Special Publication 80-63-3, Digital Identity Guidelines, June 2017.

While CMS business owners may implement their own solutions, CMS has available several shared Identity, Credentialing & Access Management (ICAM) services to support CMS applications in any CMS processing environment.

Enrollment and Identity Proofing

For CMS staff, contractors, and other government agencies, the enrollment and identity proofing processes are integrated with human resources and contracting processes. These processes require in-person identity proofing and support the provisioning of a CMS badge or PIV card, and if needed, an Enterprise User Administration account (please refer to Enterprise User Administration for more information about EUA services). Similar processes are required for non-organizational users who require a Level 4 or IAL 3 identity assurance level:

• Organizational user. Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors and guest researchers). Please refer to control IA-2 in NIST SP 800-53.
• Non-organizational users. Non-organizational users include information system users other than organizational users explicitly covered by IA-2. Please refer to control IA-8 in NIST SP 800-53.

CMS business owners may implement their own processes for subscriber enrollment and authorization for their access to business-specific CMS applications.

• A recommended solution for enrolling non-organizational users is the CMS ePortal, which implements subscriber enrollment and authorization for CMS applications that use the CMS Identity Management Service (aka. IDM). Please refer to Shared Services for more information about the CMS Identity Management Service.
• The Scalable Login System (SLS) is an internal CMS web application that supports the Federally Facilitated Marketplaces (FFM) website, healthcare.gov. SLS provides the identity management of consumers that create accounts on healthcare.gov and medicare.gov.

A CMS-authorized, third-party Remote Identity Proofing service may be used to support, but not replace, an identity proofing process for Level 2, Level 3, or IAL 2 identity assurance levels.

Remote Identity Proofing

Remote Identity Proofing (RIDP) is an automated process (not in-person) that uses government and/or commercially available data to validate an individual’s identity by asking questions of the individual. See Quick Start Remote Identity Proofing (RIDP) User Guide

The RIDP process requires the individual to provide:

• Personal information, such as name, date of birth, address, exactly as recorded on either his / her driver’s license or any Government ID
• Answers to questions related to user’s personal and financial history

The individual’s answers are verified using both authoritative sources (e.g., state motor vehicle administration, court records, and licenses) and non-authoritative sources (e.g., credit reports, professional organizations, merchants, warranties, and travel industry). A commercial remote identity proofing service with access to these data sources generates the questions and scores the answers. CMS uses a number of commercial services to provide a layered approach.

CMS understands that Remote Identity Proofing is fallible. RIDP uses questions based on publicly available data, or non-authoritative data sources, simply to raise confidence in an individual’s identity, but does not provide direct evidence. When using RIDP, there are some additional considerations that may require defining policies:

• As some RIDP questions may be perceived by the public as CMS overstepping privacy norms, it is advisable to set limitations on what types of questions may be used for RIDP.
• There should be restrictions on what CMS and commercial remote identity proofing providers may do with data collected while providing remote identity proofing services.

CMS understands that Remote Identity Proofing is not feasible for all applicants, such as people who do not have established credit histories, lack US or state government IDs, or are unable to provide answers directly. For this reason, an alternative proofing process must be available for applicants who are unable to gain approval via remote identity proofing.

Credential Provisioning

For CMS staff, contractors, and other government agencies, credential provision processes are integrated with human resources and contracting processes. These processes require in-person identity proofing and support the provisioning of a CMS badge or PIV card, and if needed, an EUA account. Similar processes are required for non-organizational users who require a Level 4 or IAL 3 identity assurance level.

For non-organizational users who require a Level 2, Level 3, or IAL 2 identity assurance level, CMS applications may provide their own CSP services, or use the CMS Enterprise Identity Management Service. The CMS Scalable Login System (SLS) supports users of the Federally-Facilitated Marketplaces (FFM) website, healthcare.gov.

Please refer to Shared Services in this chapter for more information about EUA, IDM and SLS services.

For non-organizational users who require a Level 1 or IAL 1 identity assurance level, CMS applications may provide their own CSP services, provided that the service collects minimal or no PII, and meets CMS requirements for security and protection of PII and the CMS applications.

Multi Factor Authentication

Multi-Factor Authentication is a security mechanism to verify the legitimacy of a person or transaction. MFA requires the user to provide, in addition to user ID and password, more than one form of verification to prove user identity. MFA registration is required only once when a user is requesting a role, and it is verified each time a user logs in. During the MFA registration process, the CSP requires registration of a phone number, computer, hardware or software token, or email address to use as an MFA mechanism to add an additional level of security to a user’s account. See CMS’ Identity Management

Although industry has introduced many alternative mechanisms for implementing MFA, not all are acceptable for a given CMS application or situation under NIST or CMS guidelines. These mechanisms should be reviewed for security vulnerabilities and risk before deciding to implement them. For example, please refer to NIST SP 800-63-3B guidelines, section 5.1.3.1 Out-of-Band Authenticators, which provides that, “Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.” which provides that, “Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.”

Please refer to Shared Services in this chapter for more information about MFA services and integration with EUA, IDM, and SLS services.

Self-Service and Help Desk Identity Life-Cycle Management

Self-service and Help Desk support must be available to subscribers for the following functions: recovering a forgotten user ID or password, enabling access to a temporarily disabled account, resetting a password, and updating user profile information. Restoration of access to a revoked account must be performed exclusively by a Help Desk agent.

Non-User Accounts and Special-Purpose ID Types

In addition to user accounts, Table - Special-Purpose ID Types presents the accounts for special-purpose ID types and a discussion of each.

The CMS ARS requires periodic resetting of passwords for non-user accounts. New passwords are generated on schedule, coordinated with business owners or training facility managers, and put into effect through procedures managed by the EUA team (EUA UIDs), Tier 2 (AD), and Enterprise Database Group (EDG).

Reconciling Identities

When multiple directories or databases hold identity profile data on the same or overlapping sets of individuals, the identity profiles should be periodically reconciled between the directories and databases to detect and eliminate duplicates, outdated profile information, and invalid or unauthorized identities.

Identity reconciliation allows CMS a unified view of user / system identities by synchronizing identity records from multiple databases. It detects duplicate records existing across multiple access control systems or within one access control system itself. It correlates the data through data matching techniques that are used to identify duplicate records, inconsistent formats, and other data problems that can weaken system access controls for sensitive data for CMS.

Privilege Administration

Privilege administration is controlling user access to systems based on roles and responsibility. Privilege Administration consists of the following functions:

• Identifying user privileges
• Managing user roles
• Granting user privileges and roles
• Revoking user privileges and roles
• Granting roles for operating system or network
• Listing privileges and roles

Please refer to Shared Services in this chapter for more information about privilege administration in EUA, IDM, and SLS services, as well as Directory Services.

Periodic User Certification and Account Review

User Account Review, a.k.a. User Certification, is the periodic review of a user’s authorization status. User Certification is, at minimum, an annual requirement. For each user of a CMS system, the process of certification verifies that the user:

• Is still an active user
• Is still authorized to use CMS systems
• Has received the required security awareness training
• Has reviewed and accepted the CMS Privacy Statement

CMS business owners implementing processes for authorizing user privileges and roles must also implement processes supporting User Certification. The EUA, IDM, SLS, and other CMS shared IDM and directory services may implement features to support User Certification processes, such as tracking User Certification expiration dates and compliance.

Privileged Access Management and the CMS Zero Trust Forge

Access Control (AC) Procedures require privileged accounts with elevated access to sensitive systems or data be limited to only the permissions necessary. This is known as Privileged Access Management (PAM). While CMS Hybrid Cloud provides “stock” roles for Role-Based Access Control (RBAC), these may be overbroad. This is a challenge in improving the Zero Trust maturity of systems. All ADO teams are encouraged to use the CMS Zero Trust Forge, which addresses this by guiding and streamlining the definition of custom, granular roles.

Directory Services

Directories are databases specifically designed to store and retrieve individual user profiles, including login credentials, demographic information, roles, and privileges.

Enterprise Directory Services

The CMS Enterprise Directory Services and the Enterprise LDAP data enable the recognition of a UserID as a user identity in applications throughout CMS. Attributes of user accounts managed by EUA are synchronized with data stores for the Enterprise LDAP, LDAP proxies, RACF and certain databases. Applications may access the Enterprise LDAP data to authenticate users, retrieve email addresses, or retrieve other general information about users.

Enterprise Directory Services make the following synchronized data elements and functions available to applications:

• UserID
• Physical token ID numbers (SecureID or other)
• Password verification
• LDAP groups
• Assurance level (not presently implemented)
• Email address

Other information is also available from the Enterprise Directories. The Enterprise Shared Services Group (ESSG) can provide a complete dictionary for the managed data in each directory domain.

CMS maintains multiple managed directory systems offering directory services to all CMS applications and application platforms.

LDAPS and LDAP Proxies

CMS applications may connect directly to the CMS Enterprise LDAP proxies to perform user authentication or access user attributes. An LDAP bind operation may be used to verify user credentials. Note: CMS does not permit anonymous binds to LDAP. Applications requiring direct LDAP access will be assigned system accounts. Only secure LDAP (LDAPS) is accessible to applications, and a security certificate is required to access the secure server.

Applications using LDAPS to authenticate users are responsible for implementing their own mechanisms for managing access requests, including authentication, session management, policy, client detection, naming, and logging.

By default, the Enterprise LDAP proxies are read-only to most applications. Application-specific LDAP domains may be established with TRB approval.

RACF

Mainframe applications may use RACF. When practicable, mainframe z/Linux and z/OS applications should use the same authentication and directory service mechanisms as mid-tier servers.

Reconciling Identities

EUA supports new user registration processes to detect whether a new applicant already has an existing active, disabled, or archived UserID. The UserIDs in EUA are never reissued; a returning former employee or contractor whose UserID was archived is issued a new UserID.

EUA synchronizes passwords and core attributes of EUA-managed UserIDs in all of the supported domains and the EUA team reconciles non-EUA UserIDs in the domains with the EUA data repository to ensure only CMS-authorized UserIDs exist in the domains. All authorized UserIDs in the RACF and AD domains are also in the EUA data repository.

Major Shared ICAM Services at CMS

Enterprise User Administration

Enterprise User Administration is the CMS Identity Management system for CMS staff, contractors, and other government agencies. EUA user accounts are associated with CMS PIV cards and required for access to most CMS staff workstations and internal applications. EUA identity and access management is not available for all CMS application or data centers.

EUA Profiles and Roles

Each CMS user account may be authorized for and assigned one or more profiles. A profile (also known as EUA Job Codes, EUA Profiles, Production Control Identifiers, Business Profiles, or RBAC Profiles) is a specific set of Access Control Entitlements for a specific set of applications. Most profiles are unique to a given application, but a profile may also include ACE for multiple applications. When a user is assigned a profile, EUA may also initiate additional processes to provision or initialize application accounts or resources required for the user.

EUA manages user profile data and synchronizes profile data with the enterprise LDAP, RACF, and other CMS directories.

Privilege Administration in EUA

Job Codes are assigned to a user by a CAA only after a business owner and the user’s line manager approve a request. CAAs may use EUA Workflow to perform all user identity management functions, including adding new users, resetting user passwords, assigning Job Codes to users, and disabling, archiving, or restoring EUA user accounts.

Reconciling Identities

EUA supports new user registration processes to detect whether a new applicant already has an existing active, disabled, or archived UserID. The UserIDs in EUA are never reissued; a returning former employee or contractor whose UserID was archived is issued a new UserID.

EUA synchronizes passwords and core attributes of EUA-managed UserIDs in all supported domains. The EUA team reconciles non-EUA UserIDs in the domains with the EUA data repository to ensure only CMS-authorized UserIDs exist in the domains. All authorized UserIDs in the RACF and AD domains are also in the EUA data repository.

Identity Management System (IDM)

CMS’ Identity Management (IDM) system is an established, enterprise-wide, identity management solution. IDM is leveraged by CMS business applications across the agency. End users of all business applications that integrate with this solution can use a single set of user credentials to access any integrated application.

The previous Enterprise Identity Management (EIDM) has been decommissioned and replaced with IDM.

Scalable Login Systems

The Scalable Login System is an internal CMS web application that supports the FFM website, healthcare.gov. SLS provides the identity management of consumers who create accounts on healthcare.gov.

SLS is a database application that manages the life cycle of consumers’ User IDs, passwords, and supporting data collected from consumers, from initial creation until the account is archived. It provides the identity verification and account management of online accounts that consumers create on the FFM.

SLS collects and shares personally identifiable information with FFM to establish a consumer’s primary online account. This information includes a broad list of information such as the consumer’s name, address, telephone, employer, SSN, gender, ethnicity, citizenship status, household income, identifying information about any dependents or household members, and preferred language.

SLS services are grouped into two functional areas: the Registration service, which verifies each user’s identity through the New User Registration process using RIDP; and the Experian RIDP web service, which enables SLS to remotely verify the identity of the consumer applying for insurance. The Identity Life-Cycle Management Service provides self-service for the consumer-user, allowing the consumer-user to change a forgotten ID or password, enable a temporarily disabled account, restore access to a revoked account, and update the consumer-user’s profile.

Third-Party CSP and Related Services — A Layered Approach to Identity Verification

CMS uses several commercial services to support identity proofing and credential management. This RIDP solution includes several components, including Experian Precise ID, FraudNet, Boku and Ekata which all work together to provide a comprehensive and effective RIDP solution.

Experian Precise ID

Experian’s Precise ID helps CMS verify the identity of individuals by matching personally identifiable information (PII), such as name, address, and date of birth, against a variety of authoritative data sources.

For non organization users, some CMS applications use Experian’s solution for Remote Identity Proofing (RIDP) to validate that sufficient information exists to uniquely identify an individual without requiring document upload or biometric verification.

Importantly, Experian’s RIDP does not support document-based verification (e.g., uploading ID documents), facial recognition, or liveness checks. It avoids the document intensive approach of standard IAL2 because those methods typically result in lower pass rates. Instead, RIDP relies solely on PII and risk analytics, enabling higher verification success while still achieving strong fraud detection.

FraudNet

FraudNet is focused on detecting and preventing fraudulent activity. It uses advanced analytics and machine learning to analyze patterns of behavior and identify potential fraudsters. FraudNet can flag suspicious activity, such as multiple attempts to use the same identity information or attempts to use stolen or fake identities. It is important to note that your Application Maintainer will need to add Experian-provided Javascript collector software to User Interface (UI) to gather information from device for use by FraudNet.

Ekata

Ekata provides additional data to help verify identities. It draws from a variety of sources, such as address directories, public records, and phone directories, to provide CMS with additional information that can help confirm an individual’s identity. More importantly, by analyzing the metadata associated with the email address, Ekata can confirm that the email belongs to the person claiming to be associated with it.

Twilio

Twilio is focused on mobile identity verification. It leverages mobile phone information, such as phone number and carrier, to help verify an individual’s identity.

Taken together, these components provide CMS with a powerful RIDP solution that can help protect against fraud and ensure that the people they are dealing with are who they claim to be.

Federal Data Services Hub

The Federal Data Services Hub is used by systems like the Health Marketplace and Medicaid systems to verify eligibility. It consolidates access to multiple federal databases (SSA, DHS, IRS, VA, and others) and supports Medicaid and health insurance marketplaces by providing real-time verification of key eligibility criteria, including U.S. citizenship.

Taken together, these components provide CMS with a powerful RIDP solution that can help protect against fraud and ensure that the people they are dealing with are who they claim to be.

Okta Identity and Access Management Services

Some CMS applications use Okta identity and access management services for web-based applications, both in the Cloud and behind the firewall. All access to, and communication with, the Okta service is over an HTTPS connection. The Okta service offers:

• Single Sign-on. Okta supports SSO to web apps in two ways: secure web authentication (SWA) and federation.
• Directory Integration. User management may be integrated with AD or LDAP, including user provisioning and de-provisioning. Okta refers to this service as a “delegated authentication” where it uses AD or LDAP server credentials to authenticate users.

Access Control

CMS ARS guidance on the Access Control (AC) policy family is self-explanatory. The following subtopics provide an overview of some of the CMS services and practices available to support AC controls.

Please consult the CMS ARS directly for specific guidance.

Local System Access Controls

Local system security requirements are essential prerequisites for local Access Controls described in the CMS ARS. Please refer to the Security Services section in this chapter for a more comprehensive discussion of CMS security requirements.

Account Management

Account control mechanisms are required to authorize and monitor the use of guest / anonymous accounts, and to remove, disable, or otherwise secure unnecessary accounts. The CMS ARS requires removing or disabling default user accounts, renaming active default accounts, and using unique and separate administrator accounts for administrator and non-administrator activities.

Account managers must be notified when CMS information system users are terminated or transferred and associated accounts are removed, disabled, or otherwise secured. Account managers must also be notified when there are changes in the users’ information system usage or need to know.

Terminated or obsolete user accounts must be disabled and, after a defined period, archived. User accounts are never deleted because this action may impact an application’s data or logs. Applications should be designed to allow for such a possibility by recording a user’s full name and other pertinent information rather than relying on the future availability of that information in the directory.

Access Enforcement

Access control policies (e.g., identity-based policies, role-based policies, and rule-based policies) and associated access enforcement mechanisms (e.g., access control lists, access control matrices, and cryptography) are employed to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.

Operating system controls must be configured to disable public “read” and “write” access to files, objects, and directories that may directly impact system functionality and/or performance, or that contain sensitive information. The information system must restrict access to privileged functions (e.g., system-level software, administrator tools, scripts, and utilities) deployed in hardware, software, and firmware, and security-relevant information shall be restricted to explicitly authorized individuals. Default access will be set to “denied” unless explicitly allowed.

Encryption of Stored Information

If encryption is used as an access control mechanism, it must meet CMS-approved encryption standards (FIPS 140-2 & FIPS 140-3 compliant and use a NIST-validated module). (Please refer to SC-13, Use of Cryptography, in the CMS ARS )

CMS generally does not require that its applications include specific encryption functions (e.g. FIPS 140-2 or FIPS 140-3) as part of the business logic. Encryption and encryption key management are often provided through configuration of the servers and infrastructure services supporting the application but this should not be assumed. CMS application owners must ensure that required encryption and key management controls are in place.

Information Flow Control

Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. The CMS TRA Multi-Zone Architecture includes many of the safeguards that are necessary for Information Flow Control.

Flow control must be enforced over information between source and destination objects within CMS information systems and between interconnected systems based on the characteristics of the information. (Please refer to Security Control AC-4 in the CMS ARS.) System policies and application interconnection agreements should address the types of permissible and impermissible flow of information between information systems and the required level of authorization to allow information flow.

System Use Notifications

The system displays an approved warning / notification message on successful log on and before gaining system access. The warning message notifies users that the CMS information system is owned by the U.S. Government and describes conditions for access, acceptable use, and access limitations. The system use notification message provides appropriate privacy and security notices and remains on the screen until the user takes explicit actions to log on to the CMS information system.

In high-risk systems, mechanisms must be in place to provide users with information about previous logons, both successful and unsuccessful.

The CMS ARS provides important additional requirements for the content and implementation of System Use Notifications.

Session Control

Information systems must identify and terminate all inactive remote sessions (both user and information system sessions) automatically.

The CMS ARS has the following Implementation Standard(s):

1. Configure systems to disable local access (i.e., lock the session) automatically after a period of inactivity specified by CMS ARS Security Control AC-11 (Device Lock). Require a password to restore local access.
2. Configure the information system to automatically terminate all remote sessions (user and information system) after period of inactivity specified by CMS ARS Security Control AC-02(05).
3. Concurrent User ID network log-on sessions are limited to one (1); however, the number of concurrent application / process sessions is limited to what is expressly required for the performance of job duties and must be documented in the System Security Plan if it is more than one (1) concurrent session.

System and Communications Protection

CMS ARS guidance on the System and Communications Protection (SC) policy family is self-explanatory. The following subtopics provide an overview of some of the CMS services and practices available to support SC controls.

Please consult the CMS ARS directly for specific guidance.

Public Key Infrastructure Certificates

All public key certificates used within the CMS information system must be issued in accordance with a defined certification policy and certification practice statement. Registration to receive a public key certificate must include authorization by a supervisor or a responsible official and must be conducted by a secure process that verifies the identity of the certificate holder and ensures that the certificate is issued to the intended party.

Mobile Code

Mobile code (also known as active content) refers to macros or code embedded in a web page, email message, document, or other communicated medium that executes on a user’s device (workstation, cell phone, other). Mobile code technologies include, for example, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript.

CMS establishes usage restrictions and implementation guidance for mobile code technologies based on the potential to cause harm to CMS information systems. The organization must document, monitor, and implement controls for the use of mobile code within the CMS information system. The TRB has the authority to permit or deny the use of mobile code.

Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Control procedures prevent the development, acquisition, or introduction of unacceptable mobile code within the information system. NIST SP 800-28 provides guidance on active content and mobile code.

Audit and Accountability

CMS ARS guidance on the Audit and Accountability (AU) policy family is self-explanatory. The following subtopics provide an overview of some of the CMS services and practices available to support AU controls.

Please consult the CMS ARS directly for specific guidance.

As appropriate and defined in the CMS ARS, logs should be collected, aggregated, and analyzed in the Security Zone. Security documentation should define the events, categorization, and required responses. Each security event should document the corresponding actions taken. To ensure proper analysis of audit / logging information, a network time protocol should be used to ensure synchronization of time stamps across the environment.

Logging must be enabled for administrator and user account activities, failed and successful log on, security policy modifications, use of administrator privileges, system shutdowns, reboots, errors, and access authorizations.

Applications must include audit mechanisms that support the following CMS ARS requirements:

• Disclosures of sensitive information, including protected health and financial information, must be recorded. The log should include information type, date, time, receiving party, and releasing party. Verify every 90 days for each extract that the data is erased or its use is still required.
• For most auditable events, the audit record content must include (1) date and time of the event; (2) the component of the information system (e.g., software component and hardware component) where the event occurred; (3) type of event; (4) user / subject identity; and (5) the outcome (success or failure) of the event. NIST SP 800-92 provides more detailed guidance on computer security log content and management.

The selection of auditable events must be based on a risk assessment to determine which events require auditing on a continuous basis and which events require auditing in response to specific situations. The CMS ARS implementation standards for AU-2, Event Logging, provide a list of auditable events. NIST SP 800-92 provides guidance on computer security log management.

Audit Monitoring, Analysis, and Reporting

Information system audit records must be reviewed and analyzed regularly to identify and detect unauthorized, inappropriate, unusual, and/or suspicious activity. Such activity must be investigated and reported to appropriate officials, in accordance with current CMS Procedures. (Please refer to Security Control AU-6 in the CMS ARS.)

Automated mechanisms must be established and supporting procedures developed, documented, and implemented effectively to enable human review of audit information and the generation of appropriate audit reports. (Please refer to Security Control AU-7 in the CMS ARS.)

Audit Record Retention

Audit records must be retained to provide support for after-the-fact investigations of security incidents, and to meet regulatory and/or CMS information retention requirements. The National Archives and Records Administration maintains criteria for record retention across many disciplines.

The CMS ARS implementation standards for AU-11 and AU-3(3) include guidelines for PII, PHI, and other record types. The organization retains audit records for ninety (90) days and archives old records for one (1) year to provide support for after-the-fact investigations of security incidents and to meet regulatory (e.g., Federal Rules of Evidence) and CMS information retention requirements.

The data centers routinely back up and retain database data, operating system logs, all data storage, and logs from communications and infrastructure services. If an application creates custom application-specific logs or audit trails, they must be identified in the System Security Plan and the Operations & Maintenance Manual, including any unique backup and retention requirements. For example, if an application uses the operating system logging service, or the WebSphere Application Server logging service to create an application-specific log, that log may not be backed up unless it has been identified in the System Security Plan.

Business Rules for Access Control and Identity Management

CMS developed the following business rules to guide the development of the Agency’s Access Control and Identity Management (ACID) architecture and implementations. These business rules and policies are based on the CMS ARS and in part on the following guiding premises:

• An individual who accesses CMS systems should have only one identity known to CMS. That individual may or may not have multiple credentials for accessing CMS systems, but all such credentials must be associated with a single vetted identity.
• Business application owners are responsible for implementing procedures and mechanisms to authorize individuals for application-specific roles.

BR-ACID-1: Valid Purpose Required to Access CMS Information Systems

CMS must have an appropriate degree of confidence that its information systems are used only by those individuals with a valid business purpose.

Related CMS ARS Security Controls include: AC-3 - Access Enforcement and
AC-2 - Account Management.

Rationale:

Individuals accessing CMS information systems without a valid purpose are a potential threat to CMS services and data.

BR-ACID-2: Known Identity Required to Access CMS Information Systems

CMS must know with an appropriate degree of confidence the identity of every individual accessing CMS systems.

Related CMS ARS Security Controls include: AC-2 - Account Management, IA-2 - Identification and Authorization (Organizational Users), and AU-10 - Non-Repudiation (High).

Rationale:

Except for public information and services intended for anonymous users, unknown individuals accessing CMS information systems are a potential threat to CMS services and data.

BR-ACID-3: Single Identity Record for Each Individual Accessing CMS Systems

CMS will maintain for each user a single identity record to manage the user’s credentials for authentication to CMS networks and resources.

Related CMS ARS Security Controls include IA-2 - Identification and Authorization (Organizational Users), AC-2 - Account Management, and AU-10 - Non-Repudiation (High).

Rationale:

By maintaining a single identity record for each user, CMS can simplify the user experience, prevent duplicate identities, simplify identity management, and better understand who has access to CMS information systems.

BR-ACID-4: User Identities Must Be Vetted and Managed Using a Common Framework

The identities of every user must be vetted and managed using a common framework to ensure confidence in the user’s identity at each identity assurance level across CMS business applications.

CMS bases its policy for creating and managing identities for agency employees and support contractors on Homeland Security Presidential Directive 12 (HSPD-12), Federal Information Processing Standards Publication 201 (FIPS PUB 201), and the CMS ARS.

Above and beyond the core framework CMS provides for adjudication, the business owner is responsible for reviewing and approving any application-specific criteria and procedures used to vet the identities of new users of their business applications.

Related: OMB 11-11; HSPD-12; FIPS PUB 201; and CMS ARS Security Controls include:
IA-2 - Identification and Authorization (Organizational Users).

Rationale:

Identity vetting using certain criteria is required for compliance with NIST. Moreover, using a common framework for vetting enables CMS business owners to have confidence in the identity of established CMS users (those already having a CMS UserID) requesting access privileges to their business applications.

BR-ACID-5: Use Personally Identifiable Information Only When Appropriate

CMS will use Personally Identifiable Information only when appropriate.

Related CMS ARS Security Controls include: SA-8(33) - Minimization, PM-5(1) - Inventory of Personally Identifiable Information, PM-25 - Minimization of Personally Identifiable Information Used In Testing, Training, and Research, PT-2 - Authority to Process Personally Identifiable Information, PT-3 - Personally Identifiable Information Processing Purposes, PT-4 - Consent, PT-5 - Privacy Notice, PT-6(1) - Routine Uses, PT -7 - Specific Categories of Personally Identifiable Information, SI-12(1) - Limit Personally Identifiable Information Elements

Rationale:

Protecting PII held by the government is crucial to building and maintaining public trust. Since the purpose of Identity Management is to validate a personal identity, PII is essential to the process. CMS will support the government’s efforts to review and use PII only when appropriate.

BR-ACID-6: Minimize Retention of PII in Identity Life-Cycle Management

CMS will minimize retention of PII in identity life-cycle management, and only retain that PII needed for performance of identity life-cycle management functions after issuance of credentials, such as credential maintenance, account maintenance, authorization, or periodic certification.

Related CMS ARS Security Controls include: MP-6 - Media Sanitation, PT-2 - Authority to Process Personally Identifiable Information, PT-3 - Personally Identifiable Information Processing Purposes, SI-12 - Information Management and Retention, SI-12(3) - Information Disposal

Rationale:

Protecting PII held by the government is crucial to building and maintaining public trust. In some processes, such as in remote identity proofing, the PII collected may include both required proof of identity information (e.g., driver’s license, passport, and valid email address), and supplemental information used only to build confidence in an individual’s identity. Sources of supplemental information may include credit bureaus, public records, other agencies, or commercial providers. Once the individual’s identity has been established with sufficient confidence, the supplemental information is no longer needed, and only the required proof of identity information may be retained. Discarding this supplemental information reduces the potential for unauthorized disclosure and eliminates the expense to maintain and update it.

BR-ACID-7: Collect and Use Social Security Numbers Only When Necessary

CMS will collect, retain, use, or disclose Social Security Numbers (SSN) in identity proofing and management functions only when necessary and where no practical alternative exists.

Related CMS ARS Security Controls include: SA-8(33) - Minimization, PM-5(1) - Inventory of Personally Identifiable Information, PT-7(1) - Social Security Numbers, and SI-12(1) - Limit Personally Identifiable Information Elements

Rationale:

CMS may require an individual to provide a SSN to facilitate proofing at LOA 2 or 3. Without an individual’s SSN, identity proof will be more challenging and time consuming. Collecting SSNs may reduce the likelihood of fraud and abuse.

RP-ACID-8: Use Third-Party Data Sources for Identity Proofing and Credential Management

This recommended practice does not apply to vetting or identity management of organizational users (i.e., federal employees, contractors, administrators, etc.).

For non-organizational users, and where practical or as mandated, CMS will use third-party data sources (other government agencies, credit bureaus, commercial identity service providers, or commercial data brokers) to provide information and managed services that support identity life-cycle management functions such as identity proofing and credential management. For additional guidance, please refer to CMS ARS Security Control IA-8, which is the baseline for non-organizational user authentication requirements (i.e., “e-Authentication”).

Related CMS ARS Security Controls include: IA-8 - Identification and Authentication (Non-Organizational Users).

RP-ACID-9: CMS May Delegate Registration and Identity Proofing to Employers

This recommended practice may not be used for vetting or identity management of organizational users (i.e., federal employees, contractors, administrators, etc.).

For non-organizational users, and when appropriate, CMS may delegate the responsibility to perform registration and identity proofing to external organizations for their employees. For additional guidance, please refer to CMS ARS Security Control IA-8, which is the baseline for non-organizational user authentication requirements (i.e., “e-Authentication”).

Related CMS ARS Security Controls include: IA-8 - Identification and Authentication (Non-Organizational Users).

BR-ACID-10: EUA Manages UserIDs of CMS Employees and Contractors

The EUA system is the primary identity management system used to register organizational users and control issuance of UserIDs, passwords, and job codes for access to internal CMS applications (other than Internet-facing applications) for CMS employees, contractors, and other organizational users.

EUA identity and access management is not available for all CMS application or data centers.

Related CMS ARS Security Controls include: IA-2 - Identification and Authorization (Organizational Users) and AU-10 - Non-Repudiation (High).

Rationale:

Centralized identity management for CMS employees, contractors, and other organizational users accessing internal CMS systems is essential to protecting CMS services and data.

BR-ACID-11: CMS Business Owners Provide Privilege Administration

CMS business owners must develop their own processes for privilege administration, role administration, user provisioning of application resources, and related administration and management tools.

Privilege administration processes must establish that a user has an ongoing legitimate need to access a given application in an application-defined role. Identity proofing or possession of a CMS UserID does not represent vetting of an external user’s business relationship with CMS or other entities.

Related CMS ARS Security Controls include: AC-2 - Account Management and IA-2 - Identification and Authorization (Organizational Users).

Rationale:

Privileges and roles are very specific to each application and business. Only CMS business owners are in a position to define the privilege administration requirements and business processes for their applications.

BR-ACID-12: Local User and System Accounts Must Be Auditable

CMS requires strong technical and business reasons before permitting local user and system accounts on CMS processing systems. Like other accounts, local user and system accounts require management, auditing, and reconciliation.

Local user accounts are those that exist only in a single instance of an application (such as a database management system, business application, service daemon, infrastructure tool, or utility) or operating system on an individual server (either virtual or physical) and are not shared with or recognized by applications on other servers.

System accounts are used by superuser administrators, by services or daemons that run on individual machines, or by services to authenticate communications between services.

For all local user and system accounts, applications should use an Application LDAP domain, the CMS Enterprise LDAP domain, or a directory service synchronized with the Enterprise LDAP domain.

Exemptions to using an LDAP or other directory service for local accounts may be permitted for performance or other technical reasons. Exemptions must be documented in the system design documents, CFACTS, and risk assessment for both the system and the environment. Appropriate compensation information security and privacy controls must be implemented.

Related CMS ARS Security Controls include: AU-10 - Non-Repudiation (High).

Rationale:

Using a LDAP or other directory service helps support user account management, auditing, and reconciliation across CMS. Like other accounts, local user and system accounts require management, auditing, and reconciliation.

BR-ACID-13: OIT Is Responsible for Identity Management of Users with Credentials Provisioned in the CMS Enterprise Directory

For users with credentials provisioned in the CMS enterprise directory, including the CMS LDAP, Active Directory, and RACF directories, the Office of Information Technology and the Office of Support Services and Operations are responsible for identity proofing, identity management, and user credential management for users accessing internal CMS systems. Application owners are responsible for authorizing users to access their applications.

In some cases, the business owner may be responsible for proofing the user’s identity before making a request to a CMS Access Administrator to issue the user a CMS UserID.

Rationale:

Centralized identity management for CMS employees, contractors, and other users accessing internal CMS systems is essential to protecting CMS services and data.

NETWORK SERVICES 

CMS NETWORK SERVICES 

Network Services Introduction 

The CMS Processing Environment, which includes data centers, networks, applications, and cloud-hosted services, must comply with CMS Information Systems Security and Privacy Policy (IS2P2) and the CMS Acceptable Risk Safeguards (ARS). This section of the CMS Technical Reference Architecture (TRA) focuses on network services and provides supplemental engineering guidance for complying with the CMS ARS requirements for appropriate boundary protections (SC-7), monitoring (SI-4), malware protections (SI-3), protecting information at rest (SC-28) and in motion (SC-8), integrity (SI-7), remote access (AC-17), and other requirements. The reader should consult the IS2P2, the CMS ARS and the other topics of this chapter for more details and specific guidance on network service requirements. There are certain portions of this section that only apply to CMS data centers and not to CMS cloud implementations, where the network infrastructure would be a cloud-provided service. Clarification will be provided when the TRA content applies only to CMS data centers. 

Basic Description of the CMS Networking Environment 

The CMS networking environment includes the following components: 

1. The internal CMS Local Area Network (LAN) and Wi-Fi – connects personal computers and other devices in CMS office spaces and other CMS facilities. 

2. CMS Data Centers – provide gateways connecting all the CMS networks and provide hosting of CMS business applications. 

3. CMSNet – a secure private Wide Area Network (WAN) that: 

• Provides connectivity to CMS applications and systems for employees and CMSNet Business Partners (CBP) 
• Provides multi-zone connectivity for data hosting environments 
• Procures services via a government-only contract vehicle 
• Provides transport of data, Voice over Internet Protocol (VoIP), and video services 

4. CMS Extranet – a secure private WAN that provides connectivity to CMS applications for Extranet Business Partners (EBP). Services are procured via private commercial agreement among customers and CMS WAN provider at CMS’s discretion and approval. 

5. VPN – a Virtual Private Network (VPN) gateway providing secure Internet-based connectivity for servers. 

6. Internet – connectivity of CMS networks to and from the public internet is through a Managed Internet Gateway and the Department of Health and Human Services (HHS) Trusted Internet Connection (TIC), which: 

• Provides access for consumers to various CMS-published resources 
• Provides CMS employees, guests, and select CBPs access to Internet resources, i.e., cloud services providers (CSP), social media, streaming services 

The CMS networks support both Internet Protocols (IP) versions 4 and 6. Programs may use IPv6 transition mechanisms or native IPv6 transport on IPv6-compliant systems connected to CMS networks as described in the following chapter. 

Within the CMS data centers, the CMS TRA Multi-Zone Architecture, described in TRA Foundation, CMS Multi-Zone Architecture) provides Defense-in-Depth for computing environments. The multi-zone architecture, built upon a services framework, details a flexible architecture that can support both data center and cloud implementations. Within CMS data centers, the boundaries between presentation (edge), application and data zones are more clearly defined than in the cloud where some services may be supplied by the cloud vendor. For more detailed information, please review the Service Framework chapters within the Foundation section (see CMS Services Framework) (Internal Link). 

In CMS data centers, Application infrastructure resides in three zones — Presentation, Application, and Data, which span the CMS data centers. Security and Management Zones provide infrastructure and supervisory services to manage the zones. 

Firewalls and other security and monitoring components are located at appropriate boundaries between networks and zones. Transactions within a zone are permitted without restriction, unless the traffic is firewalled between data centers. Transactions traversing the zones are controlled and protected via firewalls and other security mechanisms. Transport and Management Zones provide infrastructure and supervisory services to manage the zones. 

CMS encourages resource sharing and reuse, and the concept of shared services. Applications can communicate within a zone both within a data center/cloud and between data centers or cloud regions. 

In a standard 3-zone data center implementation, users or resources granted access to a zone must meet the security challenges necessary for access to that zone. In addition, corresponding zones implemented in two (or more) data centers must have equivalent security configurations/posture. Hence, data zone components in one data center can communicate with data zone components within another data center, since their security postures are equivalent. 

In the cloud, where the network boundaries are less rigid, the zones may not be as clearly defined. In the cloud, protected application resources are generally implemented within a private cloud (non-public subnet), without a defined ‘zone’. Applications from CMS data centers or other applications within the cloud can be provided access to this private cloud with the appropriate network configuration. However, the same concepts of meeting security challenges and having equivalent security configurations also apply to inter-zone communication in CMS cloud implementations. The application developer will need to verify that security has been appropriately addressed when accessing cloud resources from a CMS data center or another CMS cloud implementation. In addition, applications granted an Authorization to Operate (ATO) can run in multiple data centers concurrently and share information between data centers as needed. 

Responsibilities for configuration and monitoring of applications and the network environment, as well as incident response, require coordination and cooperation between: 

• Business application owners and system maintainers 
• Data center and network operators and supporting contractors 
• The CMS Cybersecurity Integration Center (CCIC) 
• Trusted Internet Connection Access Provider (TICAP) 

CMS Stakeholder Requirements 

CMS’s stakeholders can be categorized into five communities of interest: CMS data center operators, CMS Offices, CMS Business Partners that include other government agencies, Extranet Business Partners, and beneficiaries. Each of these stakeholders has varying access requirements for the CMS applications, for inbound and outbound access to the Internet, and for communications among the various CMS business partners. 

CMS Data Center Operators 

The CMS data centers host CMS applications and provide services to CMS stakeholders. The CMS data centers also host the CMSNet, Extranet, and Internet gateways that serve as secure entry and exit points for all transactions and communications between the stakeholders. In providing this service, the data centers bridge and transport traffic between networks and facilitate seamless transaction processes. 

CMS Employees 

CMS employees access the Internet over a Managed Internet service. CMS employees at regional offices and satellite offices access the Managed Internet Gateway service over the CMSNet. 

CMS Business Partners 

The CMS Business Partners consist of the CMSNet Business Partners (CBPs), Extranet Business Partners (EBPs), and their communities. The following subtopics describe the network access services for each business partner type. 

CMSNet Business Partners 

CMS CBPs are the major users of the CMSNet. Some of the primary CMS CBPs include HIGLAS (Healthcare Integrated General Ledger Accounting System), Medicare Administrative Contractors (MAC), Unified Program Integrity Contractors (UPICs), Beneficiary Call Centers, Benefits Coordination & Recovery Center (BCRC) and CMS data centers. The CBPs use the CMSNet to access CMS business applications and to communicate with other business partners. CBPs access CMS applications through the CMSNet gateways hosted at the CMS data centers. The CMSNet Managed Service provides a secure site-to-site connection from CMS CBP locations to the CMSNet gateway at a CMS data center. CMSNet’s cloud-based infrastructure enables CMSNet sites the capability of access to any CMS data center or communication with other CBPs via logical configuration based on business requirements. CMSNet includes failover capability at data centers including multiple active-active connections or capability of routing to another data center. 

Extranet Business Partners 

CMS EBPs are other CMS business partners that require access to CMS’s non-web applications or sites. They include banks, clearinghouses, Managed Care Organizations (MCO), Coordination of Benefits (COB) contractors, and aggregators. 

EBPs are not permitted direct access to the CMSNet. Instead, EBPs are provisioned to a separate VPN cloud called the “CMS-Extranet,” established exclusively for use by EBPs. All traffic traversing the “CMS-Extranet” is encrypted according to Federal Information Processing Standards (FIPS) 140-2-compliant standards. 

CBP and EBP Communities 

A CBP can communicate with another CBP on CMSNet using a secure connection; however, CMS policy prohibits an EBP from communicating with another EBP on the Extranet. It is possible that a CBP on the CMSNet may need to communicate with an EBP on the Extranet and vice versa. When this occurs, the CBP traffic reaches the CMSNet gateway at a CMS data center over a secure connection on the CMSNet, and the EBP traffic reaches the Extranet gateway at a CMS data center over a secure connection on the Extranet. Traffic may be bridged between the CMSNet gateway and the Extranet gateway as long as the access policy permits the two business partners to communicate with each other. 

CMS Beneficiaries 

CMS beneficiaries use the Internet to access CMS business applications. Beneficiaries access CMS applications at a CMS data center via the Internet gateway. The CMS data centers are responsible for securing the Internet gateway and providing reliable service to the beneficiaries. 

CMS Network Services Overview 

This topic describes network services available to network users and application developers. 

CMS Internal Domains 

Primary and secondary DNS zones are distributed among CMS data centers to allow application and name resolution sharing across multiple sites. Please refer to the Domain Name System Services (Internal Link)  topics for detailed discussion of CMS DNS services topics for detailed discussion of CMS DNS services. 

Common Platform Services 

Common Platform services are technology services provided within the data centers in support of all hosted applications. Platform Services vary by data center hosting provider, and system maintainers must review specifics when selecting a provider. Platform services may include, but are not limited to, the following: 

• Web Content Management 
• Domain Name System – please refer to Domain Name System Services (Internal Link) 
• Dynamic Host Configuration Protocol (DHCP) – configured for AWS Virtual Private Network (VPC) and for Azure Virtual Network (VNet) 
• Network Time Protocol (NTP) 
• Logging and log analysis – see CMS Hybrid Cloud guidance for Logging configurations and Splunk log ingestion 
• Lightweight Directory Access Protocol (LDAP)— use CMS Active Directory E-LDAP 
• Enterprise File Transfer (EFT) / Managed File Transfer 
• Load Balancing 
• Database Administration 
• Storage Area Network (SAN) Administration 
• Operating System (OS) Administration 
• Message Queuing (MQ) 

Application developers should use Enterprise Shared Services and common platform services where possible rather than implementing specialized or single-use software. Enterprise Shared Services and common platform services ensure adherence to CMS standards and simplify support and management. Consult Required CMS Hybrid Cloud configurations for AWS Commercial accounts to ensure that platform services are configured correctly. 

CMS Continuous Monitoring 

CMS maintains an enterprise-wide, continuous monitoring program to improve situational awareness and provide near real-time risk management, compliant with NIST Special Publication (SP) 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, September 2011, and aligning with other SPs, including SP 800-37 and SP 800-53. In support of federal requirements to perform security and privacy continuous monitoring, CMS requires manual or automated audits, scans, reviews, or other inspections of CMS processing environments. CMS uses key data and metrics from many sources, including but not limited to, network monitors, asset management, vulnerability management, configuration management, malware detection, patch management, Security Information and Event Management (SIEM) integration, and other sources. 

CMS Continuous Monitoring Requirements are detailed in CMS Cybersecurity Integration Center Integration. 

Trusted Internet Connections 

CMS follows a Trusted Internet Connections deployment strategy aligned with HHS. The mission of the TIC program is to provide a means for monitoring, isolating, and securing federal external network connections in the event of cyberattacks. The program requires the Agency to route all traffic to and from external networks through TIC Zones managed by Trusted Internet Connection Access Providers. 

HHS provides TIC services for all HHS Operating Divisions, including CMS data centers and applications. The National Institutes of Health (NIH) operates the HHS TIC services. 

CMS application owners and data center operators are responsible for extranet connections to external networks, and for working with the HHS Office of Information Security (OIS) and NIH TIC teams to ensure the extranet connections are properly implemented and extranet traffic is monitored through HHS TIC services. This includes extranet connections to cloud providers and to other government networks. 

More information about the TIC program is available from DHS at Trusted Internet Connections. 

Email Services 

Various policies govern CMS email, Mail Transfer Agent (MTA), Simple Mail Transfer Protocol (SMTP), and other email-related services. These policies address concerns, which include: 

• Insecure SMTP and MTA services in production data centers may simplify exfiltration of data by malicious agents or software. 
• Official email from CMS must always have a “.gov” sending address. 
• Official government correspondence, such as invoices and notices, must be retained in accordance with federal and CMS policies. 

For these reasons and more, CMS requires the use of  CMS Enterprise Email as a Service as opposed to Messaging Application Programming Interface (MAPI) and Internet Message Access Protocol (IMAP) protocols by business applications within a CMS data center or cloud environment. To send email, applications must use a CMS secure SMTP relay or a secure web service other than SMTP to request that a security-hardened email proxy server prepare and forward the outbound message to the CMS Enterprise Email service. 

Pursuant to Executive Order 14028: Improving the Nation's Cybersecurity, the use of secure SMTP relays is required as of September 1, 2024. 

For guidance concerning email to or from CMS applications, please refer to CMS TRA – Application Development section, business rule (BR) BR-SA-10, and NIST SP 800-45 and its supplement NIST SP 800-177. Related CMS ARS Security Controls include SI-8, Spam Protection. Security Controls include SI-8, Spam Protection. 

IPv6 

IPv6 is the next-generation Internet Protocol (IP), designed to replace version 4 (IPv4) that has been in use since 1983. IP addresses are the globally unique numeric identifiers necessary to distinguish individual entities that communicate over the Internet. The global demand for IP addresses has grown exponentially with the ever-increasing number of users, devices, and virtual entities connecting to the Internet, resulting in the exhaustion of readily available IPv4 addresses in all regions of the world. 

Over time, numerous technical and economic stop-gap measures have been developed in an attempt to extend the usable lifetime of IPv4, but all of these measures add cost and complexity to network infrastructure and raise significant technical and economic barriers to innovation. It is widely recognized that full transition to IPv6 is the only viable and sustainable option to ensure future growth and innovation in Internet technology and services. It is essential for the Federal government to consistently expand and enhance its strategic commitment to the transition to IPv6 in order to keep pace with and capitalize on industry trends. Building on previous initiatives which date back to 2003, the Federal government remains committed to completing this transition. 

The Federal government's IPv6 initiative has served as a vital catalyst, fostering commercial development and adoption of IPv6 technology. In the last five years, IPv6 momentum in industry has dramatically increased, with large IPv6 commercial deployments in many business sectors driven by reducing cost, decreasing complexity, improving security and eliminating barriers to innovation in networked information systems. Several large network operators, software vendors, service providers, enterprises, state governments, and foreign governments have deployed significant IPv6 infrastructures. In fact, many of these organizations have migrated, or are planning to migrate, to "IPv6-only" infrastructures to reduce operational concerns associated with maintaining two distinct networking regimes. 

Information and guidance on the IPv6 policies can be found at HHS Policy Transition IPv6 

Specific questions and information concerning the CMS IPv6 transition can be directed to the mailbox at IPv6_Transition@cms.hhs.gov 

WIDE AREA NETWORK SERVICES 

Introduction to Wide Area Networks 

CMS has established WAN architecture and design requirements to guide implementations and application development. These requirements help ensure that CMS Processing Environment contractors deploy implementations consistently in accordance with the CMS TRA vision. They also communicate system-level requirements to CMS application developers to fully inform them of these dependencies in developing their solutions. This topic presents CMS’s WAN architecture and design requirements. 

CMS WAN Architecture 

The CMS WAN consists of the CMS Private Network (CMSNet), QIES VPN, the Internet, and the CMS Extranet. Together, these WAN elements serve the communication needs of Agency data centers, business partners, employees, and beneficiaries. 

The CMS WAN consists of the following components: 

• CMSNet – A secure private WAN that: 
• Provides connectivity to CMS applications and systems for employees and CMSNet Business Partners 
• Provides multi-zone connectivity for data hosting environments 
• Procures services via government-only contract vehicle 
• Provides transport of data, Voice over Internet Protocol (VoIP), and video services 
• CMS Extranet – A secure private WAN that provides connectivity to CMS applications for Extranet Business Partners. Services are procured via private commercial agreements among customers and a CMS WAN provider at CMS’s discretion and approval. 
• QIES VPN – A virtual private network providing secure Internet-based connectivity for the Quality Improvement & Evaluation System user community. 
• Internet – Connectivity of CMS networks to and from the public internet is through a Managed Internet Gateway and the HHS Trusted Internet Connection Access Provider. The Internet: 
• Provides access for consumers to various CMS-published resources. 
• Provides CMS employees, guests, and select CBPs access to Internet resources, i.e., cloud services providers, social media, and streaming services. 

General Requirements 

The CMS TRA contains a high-level overview of the CMS WAN services. The CMS WAN requirements support the engineering details necessary to implement the CMS WAN infrastructure. These requirements will be implemented consistent with the CMS Information Security Policy Standards and Guidelines; the CMS ARS; DISA Network Infrastructure Security Technical Implementation Guide; and NIST SP 800-81, Secure Domain Name System (DNS) Deployment Guide. 

CMS Multi-Zone Environment 

The CMS WAN consists of multiple VRF segments that constitute the multi-zone environment and are referred to collectively as CMSNet. Each VRF in the WAN maps to a zone in the infrastructure architecture as defined in CMS TRA – Foundation. 

CMS Processing Environments consist of one or more of the following zones to provide Defense-in-Depth: 

• Presentation Zones (PZ) – To support the presentation of content. Presentation Zones are accessible to external networks via firewalls through a Trusted Internet Connection. 
• Application Zones (AZ) – To support business logic for applications and creating dynamic user presentations. 
• Data Zones (DZ) – To contain data and data services used by applications. 
• Management Zone – To support specialized services, such as Public Key Infrastructure, Domain Name System services, and system management services. 
• Security Zone– To support security services. 

WAN connections between like zones in different data centers must maintain the same level of Defense-in-Depth protections. Various types of zone-to-zone interconnections are documented in this chapter. 

WAN connections must: 

• Utilize mutual authentication and encrypted tunnels to secure zone-to-zone connections 
• Include a Web Application Firewall and IDS / IPS capable of deep packet inspection at both ends of all tunnels 

WIDE AREA NETWORK SERVICES 

Business Rules and Recommended Practices 

Security 

The Security Services section in this chapter contains more detailed requirements that CMS contractors must follow for hardening the WAN components. 

BR-WAN-S-0: Use Mutual Authentication and Encrypted Tunnels between Data Centers 

Connections between CMS data centers must: 

• Utilize mutual authentication and encrypted tunnels to secure zone-to-zone connections 
• Include a WAF or firewall and IDS / IPS capable of deep packet inspection at both ends of all tunnels 

Related CMS ARS Security Controls include: AC-4 - Information Flow Enforcement, SC-28 - Protection of Information at Rest, SC-13 - Cryptographic Protection, and SC-8 - Transmission Confidentiality and Integrity. 

Rationale: 

The CMS ARS requires using appropriate approved cryptographic mechanisms (such as digital signatures and cryptographic hashes) to protect the integrity of data while in transit from source to destination outside of a secured network, to prevent unauthorized disclosure of information and to detect changes to information during transmission. 

BR-WAN-S-1: The WAN Must Implement FIPS 140-2 or FIPS 140-3 Compliant Encryption 

The WAN must implement an encryption capability that is FIPS 140-2 or FIPS 140-3 compliant using encryption products that have been validated under the Cryptographic Module Validation Program. 

When cryptographic mechanisms are needed, the information system uses encryption products that have been validated under the Cryptographic Module Validation Program (please refer to https://csrc.nist.gov/projects/cryptographic-module-validation-program ) to confirm compliance with FIPS 140-2 or FIPS 140-3 in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. 

Related CMS ARS Security Controls include: SC-13 - Cryptographic Protection, AC-3 - Access Enforcement, AC-17 - Remote Access, AC-18 - Wireless Access, AC-19 - Access Control for Mobile Devices, AU-9 - Protection of Audit Information, CM-2 - Baseline Configuration, 
IA-7 - Cryptographic Module Authentication, SC-8 - Transmission Confidentiality and Integrity, SC-12 - Cryptographic Key Establishment and Management, and SC-28 - DoubProtection of Information at Rest. 

Rationale: 

In accordance with FISMA, the CMS WAN will implement the security controls based on the FIPS 199 categorization of the system and service. This general support system is considered HIGH and must comply with the following controls for encryption standards: SC-13 - CRYPTOGRAPHIC PROTECTION and associated controls: 

FIPS publications 

Cryptographic Module Validation Program 

BR-WAN-S-2: CMS Business Partners Only Access the Presentation Zone 

CMS Business Partners only access the Presentation Zone unless they have a defined business need to access other zones. Exceptions must be documented in the system design documents, CFACTS, and risk assessment for both the system and the environment. Appropriate compensating information security and privacy controls must be implemented. 

Related CMS ARS Security Controls include: AC-3 - Access Enforcement, AC-4 - Information Flow Enforcement, AC-6 - Least Privilege, CM-6 - Configuration Settings, and CM-7 - Least Functionality. 

Rationale: 

This business rule adheres to the zone requirements in CMS TRA Foundation, Processing Environments and Multi-Zone Architecture. 

BR-WAN-S-3: Communication between CMS Data Centers Is Only Permitted between Like Zones 

Communication between CMS data centers is permitted only between like zones (i.e., presentation to presentation, data to data). 

Related CMS ARS Security Controls include: AC-6 - Least Privilege, CM-6 - Configuration Settings, and SC-7 - Boundary Protection. 

Rationale: 

This rule maintains the Defense-in-Depth aspects of the CMS TRA Multi-Zone Architecture while extending the architecture across CMS data centers. It ensures that inter-zone transactions within a data center are only possible by using the required mechanisms and protections. Inter-zone transactions between data centers would add complexity and risk to the required inter-zone mechanisms and protections, create uncertainty over responsibilities between data centers, and may expose additional vulnerabilities. 

BR-WAN-S-4: Business Partner Access Restrictions 

The CMS WAN is designed to facilitate communication between CMS applications and CMS Business Partners. There are different restrictions for CBPs using CMSNet or the CMS Extranet. 

CMSNet CBPs are subject to the following restrictions: 

• CMSNet CBPs may communicate with one another as determined by business requirements. 
• CMSNet CBPs may access the Internet via CMSNet based on business requirements and as approved by CMS. 

Extranet Business Partners are subject to the following restrictions: 

• CMS must approve any connection to specific location(s) or application(s) for which the EBPs have a business need. 
• EBPs are only allowed to access the Transport Zone and Presentation Zone; access to other zones requires TRB approval. 
• EBPs are not allowed access to the Internet via the CMS Extranet connection. 

Related CMS ARS Security Controls include: AC-4 - Information Flow Enforcement, 
AC-5 - Separation of Duties, and AC-17 - Remote Access. 

Rationale: 

Some CBPs may require Internet access or access to services from other CBPs to fulfill CMS contractual or other business obligations. 

In contrast to CMSNet CBPs, EBPs reside outside of the defined CMS WAN security boundary. Allowing EBPs to access the public Internet via CMS networks would present undesired extra costs (due to increased demand on bandwidth and other resources) and risks (due to EBP actions) to CMS. 

BR-WAN-S-11: Customer Edge Devices Must Be Configured Securely 

Customer Edge (CE) devices must be configured in accordance with CMS security policies, and secured in response to CMS, CISA Cybersecurity Advisors, and NIST National Vulnerability Database (NVD) advisories. 

Related CMS ARS Security Controls include: CM-6 - Configuration Settings, CM-7 - Least Functionality, and SI-2 - Flaw Remediation. 

Rationale: 

This rule adheres to CMS security policies, DISA STIG, (CIS) guidance, US-CERT and NIST NVD advisories, and best practices. 

BR-WAN-S-12: Management of CMSNet Is Via a Dedicated Logical Network 

Related CMS ARS Security Controls include: AC-4 - Information Flow Enforcement, 
SC-7 - Boundary Protection, SC-8 - Transmission Confidentiality and Integrity, and SC-32 - Non-Mandatory: Information System Partitioning. 

Rationale: 

NIST SP 800-53 rev 5 has a requirement for information system partitioning (SC-32) to assure Defense-in-Depth and minimize exposure of critical processes. Accordingly, management access is on a separate dedicated logical network. 

IP Addressing 

BR-WAN-IP-1: WAN Services and Devices Will Be Internet Protocol Version 6 (IPv6) Capable 

The CMS networks support both IPv4 and IPv6. Programs may use IPv6 transition mechanisms or native IPv6 transport on IPv6-compliant systems connected to CMS networks. 

an annual independent evaluation of the system must be assessed - Information Flow Enforcement. 

Rationale: 

This rule adheres to the OMB mandates for IPv6. 

BR-WAN-IP-2: The WAN Provider Will Use IP Space Provided by CMS 

The WAN provider will use IP space provided and maintained by CMS. 

Related CMS ARS Security Controls include: AC-4 - Information Flow Enforcement. 

Rationale: 

HHS provides CMS with IP space for use on the WAN. 

Related CMS ARS Security Controls include: AC-4 - Information Flow Enforcement. 

RP-WAN-IP-3: CMS or Data Centers Provide IP Space for the Multi-Zone Environment 

CMS or data center operators provide IP space for the Multi-Zone Environment. 

Rationale: 

The HHS-provided IP space is limited. 

BR-WAN-IP-5: Extranet Business Partners Provide Their Own IP Space 

EBP-provided publicly routable IP address space is required for EBPs to use the Extranet. 

Rationale: 

CMS IP space is reserved for entities that are connected directly to the CMS WAN (CMSNet). 

Change Management 

BR-WAN-CM-1: WAN-Related Service Requests Will Be Maintained on the CMS SOR 

All WAN-related service requests and management reporting related to service requests will be initiated and maintained on the CMS System of Record (SOR). 

Related CMS ARS Security Controls include: CM-3 - Configuration Change Control. 

Rationale: 

The CMS WAN Service Provider is responsible for maintaining all WAN components, configurations, and tools in accordance with CMS Change Management and Configuration Management processes. The CMS Network Service Provider is also responsible for tracking all updates to these systems for consistency across the CMS Processing Environments. 

BR-WAN-CM-2: CMSNet Services Must Be Certified Annually 

In accordance with FISMA mandates, an independent assessment of the system must be performed annually to maintain an Authorization to Operate (NIST 800-53 rev 5, CA-2 Security Assessments). 

Related CMS ARS Security Controls include: CA-2 - Control Assessments and CA-6 - Authorization. 

Rationale: 

As a federal agency, CMS and HHS compliance with FISMA is required for general support systems. 

BR-WAN-CM-3: Ensure Timely Version, Patch, and Configuration Management Practices Relative to the Identification and Release of New Security Features 

CMS WAN security objectives focus on protection of the WAN component hardware, software, and data traversing the WAN against threats to confidentiality, integrity, and availability. The security measures implemented must be commensurate with the function of the WAN component—i.e., Internet-facing components will require the highest level of security relative to other types of components. 

Multicast Routing 

BR-WAN-M-1: IP Multicast Routing Support across the CMS WAN 

IP Multicast Routing will be configured across specific CMS WAN elements as necessary, including CMSNet gateways, and CMS regional and satellite offices. 

To implement Multicast Routing across the WAN, CMS requires the following: 

• Protocol-Independent Multicast-Sparse Mode (PIM-SM) must be enabled between the Service Provider PE and CMS CE router. 
• PIM-SM must be enabled between the CMS CE router and the LAN switch. 
• IP Multicast Boundary list must be implemented on the CMS CE routers to restrict certain multicast group addresses from traversing the WAN. 
• PIM version 2 must be supported to provide for the distribution of Rendezvous Point information via Bootstrap Router (BSR) protocol. 
• PIM-SSM (Source Specific Multicast) must be supported for a privately addressed multicast group range on the CE router. 
• CMS sites that utilize Hot Standby Routing Protocol (HSRP) must use a dynamic routing protocol (OSPF) to support PIM. (PIM does not support scenarios in which infrastructure devices are pointing routes to a HSRP address.) This enables the use of PIM for IP multicast support and ensures routing redundancy. 

Related CMS ARS Security Controls include: AC-4 - Information Flow Enforcement, AC-6 - Least Privilege, CM-7 - Least Functionality, and SC-7 - Boundary Protection. 

Rationale: 

A variety of network-based applications such as Voice Over Internet Protocol (VOIP), audio and video streaming, and others require Multicast Routing. The CMS WAN must be able to support such applications for CMS and CMS Business Partners when there is a CMS business need. 

Other 

BR-WAN-O-2: Access to the Public Internet Will Comply With HHS TIC Policy 

CMS follows a TIC deployment strategy aligned with the Department of Health and Human Services, as required by the HHS Policy for the Implementation of Trusted Internet Connections (TIC) (Internal Link), March 21, 2021.  

Related CMS ARS Security Controls include: AC-17(3) - Managed Access Control Points and SC-7(3) - Access Points. 

Rationale: 

This rule adheres to guidance from OMB M-19-26, Update to the Trusted Internet Connections (TIC) Initiative, September 12, 2019, which rescinds previous memoranda providing TIC guidance, (M-08-05, M-08-16, M-09-32, M-16-27) and provides an enhanced approach for implementing the TIC initiative that provides agencies with increased flexibility to use modern security capabilities. This memorandum also establishes a process for ensuring the TIC initiative is agile and responsive to advancements in technology and rapidly evolving threats. 

 PREFERRED - Secure user access to CMS from Windows and Macintosh endpoints requires the Zscaler Client Connector (ZCC) agent on both GFE and contractor-owned systems. Connectivity from these clients uses the Zscaler Zero Trust Exchange. 

DOMAIN NAME SYSTEM SERVICES 

Introduction to Domain Name System Services 

This chapter presents a general overview of CMS practices and services for the Agency’s Domain Name System Services (DNS) architecture, design, and implementations supporting CMS enterprise environments. Specific guidance may be found in the CMS ARS, the CMS Information Systems Security and Privacy Policy (IS2P2), and in DNS Business Rules. .  

The DRaaS-CACHE Domain Name System provides a highly fault-tolerant and distributed DNS resolution environment for CMS. It includes physical and virtual appliances deployed in redundant fashion, accessible by all CMS serving entities on CMSnet. Public-facing DNS is managed by the Office of Communications and provided by Akamai Information about DNS requests is provided at CMS Hybrid Cloud: Introduction to DNS request. 

Additional references: 

• CMS Information Systems Security and Privacy Policy (IS2P2) 
• CMS ARS 
• CMS Confluence: DRaaS-CACHE Program and Service Offerings: Enterprise Domain Name System 
• CMS Hybrid Cloud: Introduction to DNS request 
• NIST SP 800-81-3,Secure Domain Name System (DNS) Deployment Guide, September 2013 (Internal Link) 
• OMB Memorandum M-23-22,Delivering a Digital-First Public Experience, September 22, 2023 
• HHS Policy for Domain Name System (DNS) and Domain Name System Security Extensions (DNSSEC) Services 
• HHS Policy for Internet Domain Names (Internal Link)  

DNS Business Rules 

Because internal DNS services are provided by DRaaS-CACHE, many of these rules apply to enterprise-level or datacenter-level DNS. Most are applicable for individual internal application systems that do not implement their own physical DNS infrastructure. 

BR-DNS-1: Keep Domain Names Flat 

CMS requires that all domain names be kept flat (close to root) and simple to all users. 

BR-DNS-2: The Physical Location of Name Servers in CMS Data Centers Must Be Easily Identifiable 

This is applicable in data centers that utilize physical equipment. 

BR-DNS-3: Minimal DNS Changes When Transitioning from One Environment to Another 

CMS must be able to transition applications from development to test, to implementation, and to production environments with minimal DNS configuration changes, i.e., no hard coding of domain names. 

BR-DNS-4: Use Stealth Primary Name Servers 

Stealth Primary name servers must reside in the Management Zone, must not have direct access to the Internet, and must not answer DNS queries, and must not answer DNS queries. 

BR-DNS-5: Secure Means Must Be Used for Zone Transfers 

BR-DNS-6: Provide Segregated DNS Resolution of Internal and External Queries 

Implement split zones to provide segregated resolution of internal and external queries. 

BR-DNS-7: Inter-Data Center Hosting of Secondary DNS Servers Is Required 

To ensure redundancy and geographic dispersion, at least one CMS data center DNS server must host or act as a secondary DNS server for another CMS data center’s DNS server. 

BR-DNS-8: Place Primary and Secondary Name Servers in Each CMS Data Center 

To improve fault tolerance and load sharing, strategically place primary and secondary name servers in each CMS Data Center. 

BR-DNS-9: Every “A” Record Defined Must Have a PTR Record 

This includes “AAAA” records for IPv6. 

BR-DNS-10: (Retired after TRA 2016R1): CMS must limit DNS zone data updates to trusted sources 

BR-DNS-11: (Retired after TRA 2018R1): DNS Protocol Must Be BIND 9 or Above and IPv6-capable (for Future Use) 

BR-DNS-12: CMS DNS Design Must Minimize Impact to the WAN 

BR-DNS-13: All DNS Changes Must Be Subject to CMS’s Change Management Procedures 

Information about DNS requests is provided at CMS Hybrid Cloud: Introduction to DNS request. 

BR-DNS-14: DNS servers deployed within ATO(ed) environments must use DNSSEC 

Per OMB Memorandum M-23-22, Delivering a Digital-First Public Experience, September 23, 2023, Domain Name System Security (DNSSEC) is required for all federal information systems. See Zone Transfers and Domain Name System Security for more information. While this practice is required in CMS production environments, maintaining signatures for DNSSEC zones adds some operational complexity that may not be justified for the lower environments of a FISMA system. 

 PREFERRED - Find detailed information about CMS DNS at CMS Cloud: Introduction to DNS request.  

DNS Services Infrastructure and Design Considerations 

The DNS design considerations presented in this topic supply the necessary engineering details used to implement the existing CMS DNS infrastructure. The requirements described in this topic ensure a simplified name space, provide a secure DNS query scheme among users in different contexts, and establish efficient and logical placement of DNS servers in appropriate locations within CMS infrastructure. 

These DNS requirements are consistent with the CMS Information Security Policy Standard and Guidelines Handbook, the CMS ARS, and NIST SP 800-81-2, Secure Domain Name System (DNS) Deployment Guide. 

CMS Domain Name Space Design Approach 

CMS DNS services are available to the Internet; all CMS data centers; the intranet; and CMS Presentation Zone, Application Zone, Data Zone, and Management /Security Zones within the standard CMS TRA Multi-Zone Architecture. The CMS DNS design is hierarchical, which helps achieve better security, ease of management, and scalability for future business needs. The name space design includes DNS functionality throughout CMS’s multi-zone infrastructure. 

Split DNS is used for CMS DNS Architecture. This means that the same domain name is used both internally and externally for accessible resources. Split DNS is implemented via views to separate external and internal records and provides differing access to the enterprise DNS for internal and external hosts. Splitting the internal and the external DNS servers also protects internal hosts and permits certain hosts to advertise to the Internet. Views facilitate the DNS administrator’s ability to define how a name server will answer queries based on the location of hosts and name servers requesting the information. 

See CMS Domain Name Spaces for more details 

CMS Internal DNS Services Infrastructure 

To support CMS’s internal networks and VDCs, CMS DRaaS-CACHE manages an enterprise-wide distributed system for IP Address Management (IPAM), DNS management, and IPv6 services. The system features: 

• DNS and DHCP services for CMS workstations at the main campus and Regional Offices (RO) 
• Integration with Windows Active Directory (AD) DNS services 
• Servers and virtual appliances to provide replicated DNS resolution in all CMS environments, including AWS commercial and GovCloud; Microsoft Azure Government (MAG); and CMS on-premises data centers 
• DNS firewall to detect and block malicious activity 
• Centralized IPAM and DNS management 
• Enterprise Failover Resiliency, Local Survivability Failover, and Disaster Recovery 

The system is configured to provide services through three network tiers: 

Tier 1 – Mission Control 

Authoritative name servers providing the actual answer to DNS queries such as mail server IP address or website IP address (a resource record) 

Tier 2 – VDCs and CMS HQ, Regional Offices, and Local Offices 

Acting as Internal Service Zone for internal DNS queries and Office Automation (OA). Tier 2 name servers will not respond to queries from external networks and will be configured for bi-directional synchronization with Windows AD. 

Tier 2 is further divided into separate network “grids” for OA and for each VDC. The OA grid includes CMS HQ, Regional Offices, and Local Offices. 

Tier 3 – HQ Caching Layer DNS Proxy to the Internet 

Cache-only DNS servers for public-facing DNS queries and DNS Firewall services. 

CMS Domain Name Spaces 

CMS maintains different domain name spaces for use in different CMS processing regions. These are: 

• Public-facing (e.g., www.cms.gov, *.healthcare.gov, *.medicare.gov). These are generally program-specific and managed by the Office of Communications (OC) with Akamai services. The OC Web Help Service Desk supports these. CMS also has internal zones for some public domains. 
• CMS Cloud internal (*.cmscloud.local) and The CMS Enterprise Cloud Service Desk supports these requests. 
• CMS private (all other *cms.local). Requests for these should contact the CMS IT Service Desk through CMS Connect. 

CMS Internal DNS Name Space 

Primary and secondary DNS zones are distributed among CMS data centers to allow application and name resolution sharing across multiple sites. 

The CMS DRaaS-CACHE service maintains a distributed set of servers and virtual appliances across all CMS enclaves to provide continuous, redundant service. For Windows workstation environment. DNS services follow these strategic principles: 

• DNS services for the Central Office and ROs are provided by CMS AD. 
• Each “AD domain controller” is a DNS server and provides DNS services for its respective regional office. 
• DNS zone transfers take place through AD replication that allows for secure and encrypted communication. 
• Microsoft DNS integrates seamlessly with DHCP to provide encrypted dynamic registration of resource records for workstations and servers. 
• At least one (1) domain controller / DNS server is allocated per RO. 
• All clients point to a secondary DNS server for name resolution in the event of a failure, as follows: 
• CO users point to a secondary DNS server in the CO. 
• RO users point back to the CO for a secondary DNS server. 

Production DNS Name Space 

In production, CMS DRaaS-CACHE provides ubiquitous, redundant service across all enclaves. 

CMS External (Internet-Facing) DNS Name Space 

External DNS services are managed by the Office of Communications (OC) and provided by an external DNS service provider (Akamai). 

CMS Tier 3 name servers are configured to transfer their zone information to other name servers located on the intranet for external name space queries. 

CMS Development / Test / Implementation DNS Name Space 

The Development, Test, and Implementation Environments maintain their own DNS name servers to reduce management complexity. The extra zones ensure that developers and operational staff connect to non-ATO(ed) environments during Development, Test, and Implementation test activities. CMS DNS infrastructure is designed to ensure that business applications do not need to change configurations while transitioning between Development, Test, Implementation, and Production Environments. 

Multi-Zone Infrastructure 

Domain Name Services are available to the Presentation Zone, Application Zone, Data Zone, and Management / Security Zones within the standard CMS TRA Multi-Zone Architecture. External DNS services are available to the Presentation Zone for resolving connections to and from the private networks or other CMS ATO(ed) environments. The multi-zone DNS is segmented into multiple DNS sub-domains, such as ALOM and HIDS, to improve security. Internal DNS servers are located in the Management Zone for internal resolution of connections originating from the ALOM and HIDS network segments.  

Guidelines and Best Practices for DNS Implementation 

This topic presents the guidelines and operational best practices for execution of the CMS-approved DNS implementations to ensure efficient, reliable, and consistent DNS services for domain names and delegation. 

The following guidelines, representing industry and government best practices, apply to the CMS DNS infrastructure in general. This includes name space operations as well as management and delegation standards when deploying and maintaining the DNS infrastructure of the CMS ATO(ed) environments. 

Change Management 

CMS data center contractors manage all DNS zones, configurations, and tools in accordance with CMS Change Management and Configuration Management processes. For example, CMS requires a service request for any modification of static DNS record entries or DNS server configuration changes. CMS production environment contractors track all updates to these systems for consistency across the CMS ATO(ed) environments. To allow quick response and mitigate DNS security exploitation, it is good practice for the CMS CISO to retain the ability to change critical DNS records from a single point of control over top-level records. 

Management and Reporting 

The CMS production environment contractors currently provide integrated DNS system and error logs into other existing network management facilities to enable a real-time view of the Enterprise DNS for CMS Operations staff. 

Availability and Resilience 

CMS employs highly available zone transfers between data centers to facilitate availability and resilience in the overall DNS Architecture. Internal and external name servers in a given data center perform zone transfers to corresponding internal and external name servers at another data center to provide redundancy in the event of a primary name server failure. For example, a primary name server hosted by a CMS contractor transfers its zone records to secondary name servers located on CMS premises to improve reduce round-trip time (RTT) and provide redundancy in the event of primary server failure. CMS highly recommends that each data center contractor provide regularly tested DNS disaster recovery plans that address all DNS outage scenarios. 

Guidelines for DNS Configuration Requirements 

• Authoritative Name Servers 

CMS’s DNS Architecture employs two types of authoritative name servers: primary and secondary. To improve fault tolerance, both types of name servers are deployed in each CMS data center. It is important to note that while a name server acts as primary for one zone, the same physical server may also receive transferred zone information from other servers and act as secondary name server for the zone transferred. 

• Name Servers 

A primary name server contains zone files created and edited manually by the zone administrator. Sometimes a primary name server allows the zone file to be dynamically updated by authorized DNS clients. A name server configured with this feature usually is called the primary name server. CMS currently employs dynamic DNS update features. For security reasons, the primary name servers hosting records for ALOM and HIDS zones must be deployed in each data center’s Management Zone . 

CMS also employs secondary name servers to facilitate lowest RTT, availability, DR, and COOP. Primary name servers are configured with the DNS NOTIFY feature to facilitate automatic zone transfers to secondary name servers. 

• Stealth Primary Name Servers 

One name server feature that CMS should consider deploying is a Stealth Primary name server, which must be located in each data center’s Management Zone. The main purpose of a Stealth Primary name server is to provide a central point of administration for all externally facing DNS records that CMS has not delegated to a CMS production environment contractor. The main requirements for Stealth Primary name servers are that they: 

• Must not have direct access to the Internet. 
• Must not answer DNS queries. 
• Must protect or hide internal hosts from the public in situations of either interrogation (query or zone transfer) or if the DNS service is compromised. 

Zone Transfers and Domain Name System Security 

Per OMB Memorandum M-23-22, Delivering a Digital-First Public Experience, September 23, 2023, Domain Name System Security (DNSSEC) is required for all federal information systems. DNSSEC provides cryptographic protections to DNS communication exchanges, thereby removing threats of DNS-based attacks and improving the overall integrity and authenticity of information processed over the Internet. CMS requires DNSSEC for DNS servers deployed within CMS ATO(ed) environments. 

In accordance with best practices, the DNS name servers must comply with the following standards from Requests for Comment submitted by the Internet Engineering Task Force (IETF): 

• IETF RFC 9364: DNS Security Extensions (DNSSEC) 
• IETF RFC 4033: DNS Security Introduction and Requirements 
• IETF RFC 4034: Resource Records for the DNS Security Extensions 
• IETF RFC 4035: Protocol Modifications for the DNS Security Extensions 
• IETF RFC 6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) 
• IETF RFC 1995: Incremental Zone Transfer in DNS 
• IETF RFC 9103: DNS Zone Transfer over TLS 
• IETF RFC 1996: A Mechanism for Prompt Notification of Zone Changes 
• IETF RFC 2136: Dynamic Updates in the Domain Name System 
• IETF RFC 8945: Secret Key Transaction Authentication for DNS(TSIG) 
• IETF RFC 3007: Secure Domain Name System Dynamic Update 
• IETF RFC 3596: DNS Extensions to Support IPv6 

While this practice is required in CMS production environments, maintaining signatures for DNSSEC zones adds some operational complexity that may not be justified for the lower environments of a FISMA system. 

DNS security objectives focus on the protection of the DNS host platform, DNS software, and DNS data integrity from availability threats. The security measures CMS implements must be commensurate with the function of the DNS server, i.e., Internet-facing and authoritative DNS servers will require the highest level of security relative to other types of DNS servers. CMS requires adherence to the recommendations in NIST SP 800-81-3, Secure Domain Name System (DNS) Deployment Guide. 

DNS content exploitation focuses on malicious manipulation of zone transfer files. Mitigation techniques concentrate on restricting exchanges to only authorized entities and implementing integrity checks on zone files. Using secure means for zone transfers is mandatory and helps protect data integrity during exchanges. 

INFRASTRUCTURE SERVICES

Virtualization

Introduction to Virtualization

Scope

This chapter defines the Virtualization guidelines and standards for the Centers for Medicare & Medicaid Services (CMS) Processing Environments. It notes where these intersect with CMS Cloud capabilities and services, and provides links. It does not cover Virtual Desktop Integration (VDI) or other desktop virtualization technologies.

Objectives

CMS’s overarching goal for virtualization is to facilitate the Agency’s transition from managing individual data center components to managing pools of computing resources. The following goals are common to all server virtualization implementations:

• Cost savings
  • Consolidating applications to run on fewer physical servers
  • Improving the efficiency of data center operations by increasing the utilization of computing resources
  • Simplifying the management and maintenance of infrastructure
  • Reducing “server sprawl,” which diminishes power requirements and server hardware footprint
• Increased scalability and elasticity capabilities
• Enhanced business continuity and disaster recovery (DR) capabilities

Server Virtualization

Server virtualization is crucial to ensuring the success of server consolidation projects that maintain the isolation of separate systems. This topic addresses the principles of server virtualization and applicable business rules (BR). It identifies the design and implementation requirements for consistency with the CMS Technical Reference Architecture (CMS TRA) and describes implementation options.

Although virtualization may be generally applicable within the CMS Processing Environments, there are a few situations for which virtualization may not be appropriate:

• Need for specialized hardware
• Need for extreme performance
• Need for higher security

These exceptions are becoming less common over time.

CMS Cloud Server Virtualization

 PREFERRED

The CMS-preferred solution for virtual servers is to use AWS Elastic Compute Cloud (EC2) (password required) instances or Microsoft Azure VMs (password required), running Windows or Linux. For single-purpose services, it is often more cost-effective and flexible to use AWS or MAG integrated services.

One CMS strategic solution is the CMS Cloud Gold Image. Gold Image AMIs are standard, baseline operating system (OS) images for most common Linux and Windows versions. Updated monthly, these contain:

• Current approved patches to resolve vulnerabilities
• Latest DISA STIG or CIS configurations to ensure configuration compliance
• Pre-installed Shared Service applications and agents that are utilized in the CMS AWS environment

Terminology

Despite the large numbers of products available for virtualization, there is significant commonality in the underlying architectural and operational requirements for the deployment of server virtualization. This commonality stems from the common goals of and architectural elements employed by server virtualization implementations. The terminology in the table below applies to all server virtualization implementations.

Despite this commonality, there are significant differences between Solaris, Linux, Windows, and IBM mainframe virtualization implementations. Specifically, there are substantial differences in the hardware, software, and security architectures employed by these implementations. These architectural differences require identification of the hypervisor and network security boundaries with implementation-specific architectural elements. The table Virtualization Implementation-Specific Security Boundaries defines the terms for implementation-specific security boundaries.

Hardening

All CMS infrastructure must be hardened to CMS standards. The CMS policy on hardening is specified in CMS ARS Security Control CM-6.

Business Rules

Although server virtualization (SV) technologies are evolving at a rapid pace, CMS has established the following business rules and recommended practices (RP) to help the implementation of these technologies meet CMS’s needs. The following server virtualization BRs support the consistent implementations of these technologies.

BR-SV-1: Apply Separation of Duties to Virtualization Administration

CMS will maintain separation of administrative duties between the hypervisor administration and VM administration.

Related CMS ARS Security Controls include: AC-5 - Separation of Duties.

Rationale:

The responsibilities of the hypervisor administrator are different from the responsibilities of VM administration. Because the hypervisor administrator can create and destroy VM instances (and other virtual resources), their role is different and separate from the day-to-day administration of virtual machine instances.

In a Cloud Service Provider (CSP) environment, the CSP typically controls the hypervisor. In this case, the CSP application programming interface (API) allows authorized users to create and destroy virtual resources, effectively acquiring hypervisor administrator privileges.

BR-SV-2: Provide Hypervisor Root Access Only to Specific Administrative Accounts

CMS will not grant unrestricted root (or system administrator) access to production hypervisor servers to the developers or end-users. Instead, root access should be restricted to a specified list of administrative accounts.

Related CMS ARS Security Controls include: CM-05 – Access Restrictions for Change and AC-06 – Least Privilege.

Rationale:

Giving out unrestricted full root access to hypervisors allows users to alter system configurations and system audit logging controls, which CMS ARS Security Control CM-6 specifically prohibits. Limiting access helps limit the risk due to the highly sensitive nature of these accounts. (Please refer to National Institute for Standards and Technology [NIST] Special Publication [SP] 800-125.)

BR-SV-3: Different Administration Account on Blade Controllers and Hypervisors

Administration accounts on the blade controllers and hypervisors must be different from those used to administer VM instances.

Rationale:

Using different accounts to administer blade controllers and hypervisors helps to enforce separation of duties.

Related CMS ARS Security Controls include: CM-5 - Least Privilege and AC-5 - Separation of Duties.

BR-SV-4: Configure UserIDs and GroupIDs to Be Unique across the Processing Environment

User groups and usernames must be unique across all file systems to prevent unintended inter-VM, hypervisors, and (when possible) Host access.

Rationale:

Network-based file servers use the UNIX userid and group--id when accessing files. It is possible for two different users to have the same userid number when on two different machines. Files created by the first user on a network share would be accessible by the second user. Ensuring different user-ids avoids accidental disclosure through this mechanism. In addition, the use of consistent UNIX ids allows for more consistent audit log correlation.

When a userid is no longer needed (such as user leaving, etc.), the userids should be retired and not reused.

RP-SV-5: Maintenance Window Planning

Applications that have conflicting maintenance windows and uptime requirements should not be hosted on the same VM or hypervisor.

Rationale:

During planned maintenance, it may be necessary to reboot virtual machines. If applications have different maintenance windows, it may be very difficult to schedule maintenance. Similarly, if the hypervisor or VM software needs upgrades or patches (for example), it is important to determine the impact to applications before undertaking this maintenance. Testing and Training systems can have similar constraints, which makes sharing difficult.

RP-SV-6: Consider High-Availability Configuration

All virtualization servers and VMs should consider configuring high-availability and disaster recovery services to mitigate failure and meet business owner-defined availability limits.

Rationale:

High-availability configurations, such as the use of clustering technology or redundant servers, should be used to meet business-owner-defined availability limits. If no such requirements exist or the limits are sufficiently low, a non-redundant configuration may be used.

BR-SV-7: No Co-Hosting on Production and Non-Production Hypervisors

In a physical data center, production and Non-Production environment virtualization servers, and their associated VMs, must reside on separate physical server hardware or logical partitions (LPAR).

Rationale:

CMS prohibits commingled workloads, thereby jeopardizing production workloads. Instead, host non-production workloads on different hypervisors.

BR-SV-8: Do Not Oversubscribe ATO(ed) Environments and Management Zones

All VMs in ATO(ed) environments or in Management Zones must have adequate resource constraints (upper and lower bounds) to ensure that they do not adversely impact the performance of other VMs on the same virtualization server. Over-subscription of pooled or shared resources is not permitted.

Please refer to BR-SV-20 and BR-SV-21 for additional related guidance.

Rationale:

Oversubscription can jeopardize meeting Service Level Agreements (SLA). In Production applications, this can result in sub-par performance and potentially impact application security. This is critical because any system processing CMS data is a Production system.

Please refer to CMS TRA Foundation, CMS Processing Environments for a formal definition.

BR-SV-9: Use Storage Quotas for Virtual Machines

Storage quotas must be enacted on a per-user and group basis.

Rationale:

Using quotas helps prevent filling file systems and object storage, which can lead to service failure and raise vulnerability to a denial-of-service attack.

BR-SV-10: ATO(ed) Environment VMs and Resource Pools Must Not Be Shared between Zones

Rationale:

A virtual machine can only exist in one zone—otherwise compromise of one virtual machine can lead to compromise of multiple zones, nullifying the advantage of defense-in-depth architecture.

RP-SV-11: Collect Virtualization Performance Metrics

CMS must gather virtualization server and VM performance metrics on a consistent basis to ensure maintenance of proper resource allocation.

Rationale:

Along with traditional server performance monitoring, virtualization technology offers additional performance metrics that may be useful to monitor.

BR-SV-12: Perform Asset Management of Virtual Instances

All virtual instance resources must be tracked in an asset management database, provided either by CMS or the hosting provider, and must provide a cross-reference to the host server hardware and host operating system.

Rationale:

Virtual instances must be identified in a durable form (such as Object Identifier [OID]) to track the use of assets and perform crosswalks between security and audit logs and virtual instances.

Related CMS ARS Security Controls include: CM-8 - Information System Component Inventory.

BR-SV-13: Keep Forensic Evidence per CMS Security Rules

Before deleting or disposing of virtual machine instances, determine if image copies should be retained for forensic purposes.

Rationale:

A copy of the instance can be used for forensic analysis by CMS. CMS may require adherence to specific rules for evidence gathering. Consult with CMS security to determine proper chain of custody rules.

RP-SV-14: Use VM Configuration Templates

Rather than generating VM instances as one-off configurations, consider using virtualization templating technology to define and create instances from repeatable configurations.

Rationale:

Repeatability is desirable because it facilitates change and configuration management and allows for replication of configurations in other processing environments. Unlike Graphical User Interface (GUI) forms, templates can be stored in source control systems, allowing for better auditing and change control.

BR-SV-15: Production Management Zone VMs May Not Use IP Multipathing

IP Multipathing (IPMP) on UNIX/Linux/Solaris or Multipath Input/Output (MPIO) on Windows Host OS are not permitted in the CMS Production environment.

Rationale:

Multipathing is discouraged because Intrusion Detection Systems (IDS)/Intrusion Protection Systems (IPS) are sometimes not available to re-assemble a full multipath Transmission Control Protocol (TCP) session and, therefore, are unable to properly inspect traffic. As a result, multipathing can be used to obfuscate attacks.

BR-SV-16: Originate Administrator Access to Blade Controllers and Hypervisors from the Management Zone

All administration access to the Blade controllers and hypervisors must originate from the Management Zone only and must use a CMS-approved secure access method.

Rationale:

Ensuring that network access to blade controllers and hypervisors originates from the Management Zone helps thwart administrator access from within the Application Zone.

Related CMS ARS Security Controls include: CM-5 - Least Privilege and AC-5 Separation of Duties.

BR-SV-17: All Management Traffic Must Originate or Terminate in the Management Zone and Use Only Isolated and Protected Interfaces

• All management network traffic must originate or terminate in the Management Zone.
• Management traffic must only use management interfaces and VLANs.
• Management traffic must be protected from inspection and tampering by other users.
• Production environment virtualization server NICs must be Media Access Control (MAC) address locked to prevent spoofing.

Rationale:

This rule ensures that management access is exclusively performed from the Management Zone. It also reduces the likelihood that unauthorized access could be performed on the business application network. Management protocols may be used between a Zone and the Management Zone only. For example, one cannot run a local syslog server in the Application Zone because syslog is, presumably, a management protocol.

BR-SV-18: Hypervisor Access Is Permitted Only Via the Management Interface

Access to the hypervisor must be allowed only via the management interface on the hypervisor host.

Rationale:

Management of the hypervisor is the sole responsibility of the operations team, which uses the Management Zone to initiate access to hypervisors. Limiting access from the Management Zone on the management interface prevents malicious actors from accessing the hypervisor from within the Application Zone.

BR-SV-19: Separate Security Segment from All Other Management Zone Segments

Management interfaces serving the Security segment must be isolated from those serving all other Management segments, e.g., Backup segments.

When Application and Presentation Zone VMs use virtual network interfaces:

• They must route to each other through the external switch, i.e., no loopback routing; and
• They must have compatible ports, protocols, and services policies that can be enforced by an external switch and firewall.

Related CMS ARS Security Controls include: AC-06 - Least Privilege, SC-03 - Security Function Isolation (High), SC-03(02) - Supplemental: Access/Flow Control Functions, and SC-07 - Boundary Protection.

Rationale:

Network traffic between Zones must be available for inspection by security services not running on the hypervisor, such as Network-based Intrusion Detection System (NIDS), and must be filtered by a firewall or equivalent.

BR-SV-20: Oversubscription of Non-Production Instances Is Permitted

Oversubscription of non-production instances is permitted, with business owner approval.

Please refer to BR-SV-8 for additional related guidance.

Rationale:

Oversubscription of non-production instances is helpful in reducing the operational cost of lower environments. It is understood that concurrent use could result in sub-par performance.

BR-SV-21: No Business Applications May Run on the Hypervisor’s Host OS

The hypervisor must only be used for the operation and management of virtual machines.

Rationale:

The hypervisor is a high-value, high-impact information technology (IT) asset. Operating business applications on the hypervisor exposes the hypervisor to a larger attack surface and additional sources of instability. By focusing the hypervisor on a single task (virtualization management), it becomes more robust and secure.

BR-SV-22: Operate Applications under Application-Specific System Accounts

Each application running on an operating system instance must operate under an application-unique system account userid. In particular, applications may not operate under an end user ID or RACF ID. Likewise, end users must not log in using an application system account userid.

System accounts must have only the minimum necessary permissions and should not have permission to log in.

Related CMS ARS Security Controls include: AC-02(09) - Supplemental: Restrictions on Use of Shared Groups/Accounts, AU-10 - Non-Repudiation (High), AC-6 - Least Privilege (High and Moderate), and CM-7 - Least Functionality (High, Moderate, Low).

Rationale:

By employing application-specific system account userids, it is possible to use operating system controls to impose access control and have better specificity in audit logs. If users can log in using system IDs, this limits non-repudiation for actions taken while operating as that userid. 

Containerization

The use of operating system containers, hereafter simply “containers,” is becoming the de facto standard for application deployment. Containers are a different form of process isolation than virtual machines and play a somewhat different role.

Containerization is a class of technology that permits isolation to occur either on physical or virtual machines. Containers do not perform CPU virtualization but rather use the facilities of the operating system kernel to sub-divide the machine into containers. Roughly speaking, each container shares a portion of the operating system with the host but has control over their own resources such as filesystems, networking, and memory. Thus, a container has many of the same properties as a real machine but is implemented using the lower overhead of the operating system’s process mechanism instead of CPU emulation, simulation, or virtualization.

Since containers operate within virtual machines and are, in effect, inheriting many of the properties of a process, they have no special status within the CMS TRA. Containers must be deployed within the CMS TRA Multi-Zone Architecture. A single container may not incorporate more than one zone. Container technology must be hardened like any technology within the CMS Processing Environment consistent with the guidance of CMS ARS Security Control CM-6.

Containers are covered in more detail in CMS TRA Application Development, Containers and Microservices.

Network Virtualization

The server virtualization techniques described in this chapter offer numerous benefits. To achieve the full rewards of virtualization, CMS must also virtualize the network links supporting communications between the virtual and physical servers. This topic describes the virtualization techniques to accomplish that end.

One of the key benefits of network virtualization (NV) is that it provides efficient utilization of network resources through logical segmentation of a single physical network. Logical, secure segmentation helps CMS comply with regulations for resource and information security. CMS’s goal is to reduce total cost of ownership (TCO) by sharing network resources while still maintaining secure separation between distinct network segments either within the Agency (e.g., web, application and data zones) or among business partners.

Overview of Network Virtualization

As a general principle, CMS employs best-of-breed network components. The primary technologies involved in delivering network path isolation and virtualization techniques that helps maintain secure logical network segmentation are:

• Generic Routing Encapsulation (GRE)
• Virtual Routing and Forwarding (VRF) Lite (VRF-Lite)
• Multiprotocol Label Switching (MPLS)
• Virtual Local Area Network
• Virtual Device Context (VDC)
• Virtual Switching Systems (VSS)

These technologies help provide solutions that preserve the benefits of existing network design while introducing the capability of logical segmentation. They help carve the network into secure virtual networks by overlaying Virtual Private Network (VPN) mechanisms onto the existing Wide Area Network (WAN) or Local Area Network (LAN). These path isolation and virtualization techniques can also help address issues associated with deploying network-based services and security policies in a distributed manner.

Business Rules for Network Virtualization

CMS has established the following network virtualization business rules to accomplish consistent implementations of these technologies in accordance with CMS TRA guidance.

BR-NV-1: Use Highly Available Network Services to Implement Zone Separation

Each zone must use highly available (HA) network services to implement and maintain the network separation, security, and performance architecture, as prescribed in the CMS TRA for the specific zone.

Virtualization techniques discussed in this chapter, such as VRF-lite, MPLS, VLAN, or VDC, may also be used for path isolation and virtualization.

The following network services must be independently managed components (as defined in CMS TRA Foundation, Processing Environments):

• Border routing
• Network switching
• Load balancing
• Intrusion Detection and Prevention
• Firewalling

These network services cannot be shared with other tenants of the data center.

Rationale:

CMS requires independently managed components to retain operational control and monitoring of the network. The CMS TRA recognizes that underlying technology may be shared, such as in the case of CMS Clouds; however, the configurations, logs, and operational data are CMS sensitive and may not be shared. In addition, CMS must maintain the ability to perform reconfiguration at will without interference with or interference from other tenants.

Mainframe Virtualization

The CMS strategy for Mainframe Consolidation and Virtualization requires a highly centralized and highly consolidated environment that employs server virtualization technology. This strategy will achieve a large reduction in infrastructure and support costs by improving resource utilization and consolidating management functions. The mainframe virtualization figure below provides an overview of the basic components that comprise mainframe server virtualization solutions.

Mainframe Virtualization (page 17)

Business Rules for Mainframe Virtualization

CMS derived the following mainframe virtualization (MV)-specific BRs from various sources, including the CMS ARS and CMS TRA – Foundation. Not all of the Server Virtualization Business Rules apply to the mainframe environment; therefore, only those Business Virtualization rules that do apply appear below.

BR-MV-1: z/VM Sole Configuration

z/VM must be the sole configuration for all logical partitions (hereafter referred to as an LPAR-z/VM).

BR-MV-2: z/Linux as Sole Guest for z/VM

z/Linux (hereafter referred to as a Virtual Machine) must be the sole guest operating system for all z/VMs.

BR-MV-3: No Nested z/VM Instances

Nested z/VM instances must not run on z/VMs.

BR-MV-4: Multiple Zones for a Single Application

Applications are not permitted to run n-zones (web front end / business logic / database) virtualized on a single LPAR-z/VM Production environment.

Mainframe Virtualization-Specific Terminology

The Mainframe Virtualization-Specific Terms table defines the following terms that are specific to virtualization of Mainframe server implementations hosting CMS applications.

Mainframe Server Implementation and Security

The following describes the design and implementation rules for consistency with the CMS TRA.

Mainframe Virtualization Implementation Rules

The general rules apply to all environments and zones within an environment. In addition, rules for each environment and each zone within an environment are provided when required.

General Mainframe Virtualization Implementation Rules

The following implementation rules apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in all environments and zones:

• All management access to VMs (e.g., administrator login), must be limited to a single physical management interface or management interface pool that is not accessible by user processes in a VM.
• All network management access to z/VM instances must be from the Management Zone via a CMS-approved secure access method.
• All network management access to the LPAR hypervisor must be from the Management Zone via a CMS-approved secure access method, e.g., via VPN into attached consoles.
• Management accounts for LPAR-z/VM management access must be different from those used to access VMs.
• Multiple environments must not share LPAR-z/VMs.
• Management interfaces on LPARs must be configured to be in a unique LPAR Management VLAN accessible only from the Management Zone.
• Management interfaces for z/VM instances must be configured to be in a unique z/VM Management VLAN accessible only from the Management Zone.
• Management interfaces serving the Security segment must be physically separate from those serving all other Management segments (e.g., LPAR-z/VM management segments).

Non-ATO(ed) Environment Mainframe Virtualization Implementation Rules

The following implementation requirements apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in Non-ATO(ed) environments, i.e., Test, Development, and Implementation environments, and their zones. The general rules apply to all zones within the environments. In addition, rules for each zone within the environment are provided when required.

• When multiple development projects share the same LPAR-z/VM, each project must reside in a different VM.

Data Zone Rules

The following implementation rules apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in non-ATO(ed) environments and their Data Zones:

• Non-Production Data Zone servers must reside in unique VMs.
• Non-Production Data Zone VMs must use VLAN virtual network interfaces mapped to individual or pooled NICs.

Application and Presentation Zone Rules

The following implementation rules apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in non-ATO(ed) environments and their Application and Presentation Zones:

• Non-Production Application and Presentation Zone servers may share VMs.
• Non-Production Application and Presentation Zone VMs may use shared VLAN virtual network interfaces.

ATO(ed) Environment Mainframe Virtualization Implementation Rules

The following implementation rules apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in ATO(ed) environments. The general rules apply to all zones within the environment. In addition, rules for each zone within the environment are provided when required.

• Production LPAR-z/VMs must not be shared between zones.
• Each Production application server must reside in its own dedicated VM.
• All Production VMs must use VLAN-dedicated physical or pooled network interfaces.
• Management interfaces serving the Security segment must be physically separate from those serving all other Management segments, e.g., Backup segments.

Mainframe Virtualization Security Rules

CMS derived the following Mainframe-specific security rules from security requirements presented in CMS TRA Network Services and the CMS ARS. The general rules apply to all environments and zones within an environment. In addition, rules for each environment and each zone within an environment are provided when required.

General Mainframe Virtualization Security Rules

The following security rules apply to LPAR- z/VMs and VMs running on LPAR-z/VMs in all environments and zones:

• Management interfaces must use dedicated interfaces or interface pools with VLAN separation.
• Management traffic must only use management interfaces and VLANs.
• Management traffic for VMs on the same LPAR-z/VM may share the same VLAN.
• Management traffic for LPAR-z/VMs must use a separate, dedicated VLAN, distinct from that used for VMs.
• Security traffic must use a separate physical interface from other management functions, e.g., backup.
• All management traffic must be encrypted and must only use SSH version 2 or Transport Layer Security (TLS), never telnet. Authentication must be provided by a Role-based Security (RBS) with authentication, authorization, and accounting (AAA) functions provided by a common AAA server. Encryption must be accomplished using Federal Information Processing Standards (FIPS) 140-2 certified modules (please refer to CMS ARS Security Control SC-13).
• All management traffic must originate or terminate in the Management Zone.
• VMs must have individual access rules and roles for authentication through an RBS.
• All accesses and configurations must be in accordance with the CMS ARS.
• Management accounts with administrative privileges in VMs must not have access privileges to LPAR-z/VMs.
• All VMs and LPAR-z/VMs must be assigned unique IP addresses.
• All VMs on a single LPAR-z/VM must be assigned IP addresses from a subnet unique to the LPAR-z/VM.

Non-ATO(ed) Environment Mainframe Virtualization Security Rules

The following security rules apply to LPAR-z/VMs instances and VMs running on LPAR-z/VMs in Non-ATO(ed) environments and their zones. The general rules apply to all zones within an environment. In addition, rules for each zone within an environment are provided when required.

• Information associated with different projects must use project- and user-unique keys for all information protected by cryptographic hashes, rather than those inherited from VMs on which the business applications run.
• Access to file systems associated with a project must be controlled through project-unique security categories to prevent direct access by members of other projects. These security categories must map to UNIX Group Identifiers (GID), with the User Identifiers (UID) of group members associated with the unique GID.

Data Zone Rules

The following security rules apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in non-ATO(ed) environments and their Data Zones:

• Non-Production Data Zone application servers must use separate VMs.
• When Non-Production Data Zone VMs reside on the same LPAR-z/VM, RBS AAA functions must be provided by a common AAA server to ensure that management and user roles are unique for each VM.
• Non-Production Data Zone VMs on the same LPAR-z/VM may route internally between each other on their z/VM instance’s subnet.
• Non-Production Data Zone LPAR-z/VMs must be configured to filter all traffic at the IP subnet level.

Application and Presentation Zone Rules

The following security rules apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in non-ATO(ed) environments and their Application and Presentation Zones:

When Non-Production Application and Presentation Zone application servers share VMs,

1. They must use separate file systems; and
2. They must use different UIDs and GIDs with
   1. RBS AAA functions provided by a common AAA server to ensure that management and user roles are common throughout a zone to prevent accidental or unauthorized access; or
   2. Application account passwords that are unique to the VM instance, e.g., apache account, to enforce separation of roles.

ATO(ed) Environment Mainframe Virtualization Security Rules

The following security rules apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in ATO(ed) environments and their zones. The general rules apply to all zones within an environment. In addition, requirements for each zone within an environment are provided when required.

Production VMs must use:

• RBS AAA functions provided by a common AAA server to ensure that management and user roles are common throughout a zone to prevent accidental or unauthorized access; or
• Application account passwords that are unique to the VM instance, e.g., apache account, must be used to enforce separation of roles; and
• Unique GIDs and UIDs across all file systems to prevent inter-VM access.
• Crash dumps residing on a common log server must be protected to prevent accidental destruction or unauthorized access.
• Each VM must implement the CMS ARS Security Controls as required by the CMS Security Level of the resident application (please refer to CMS Risk Management Framework (RMF): Categorize Step, Task C-2: Security categorization
• Resident applications with different CMS Security Levels or information types may not share a VM.
• When required by CMS ARS requirements on the resident application, each VM will implement a HIPS.
• All LPAR-z/VM access, and management traffic to VMs, must be encrypted using FIPS 140-2 certified modules (please refer to CMS ARS Security Control SC-13).
• When required by CMS ARS requirements on the resident application, each VM will implement a firewall configured to allow communication only with authorized VMs in other zones over approved ports, protocols, and services.
• Access to file systems associated with a project must be controlled through project-unique security categories to prevent direct access by members of other projects. These security categories must map to UNIX GIDs, with the UIDs of group members associated with the unique GID.
• Production LPAR-z/VMs must run at a higher security level than Non-Production environment LPARs.
• Production and Implementation LPAR-z/VMs must not be accessible from Test or Development LPAR-z/VMs.
• Firewall rules must be implemented to deny intra-zone, inter-VM network traffic by default and must allow only ports, protocols, and services authorized for a source and destination IP address pair to pass.

Data Zone Rules

The following security rules apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in ATO(ed) environments and their Data Zones:

• Production Data Zone LPAR-z/VMs must authenticate file systems before remount after VM crash.
• GID and UIDs must be unique to each VM in a Production Data Zone.
• Production Data Zone LPAR-z/VMs must run at a higher security level than all other LPAR-z/VMs on a Mainframe, except when Management Zone LPAR-z/VMs are present.
• Production Data Zone application servers must reside on unique VMs.
• Production Data Zone data sets, e.g., databases, must have unique security categories.
• Processes associated with user applications must not be allowed to use APF.
• Production Data Zone applications accessing Personally Identifiable Information (PII) or Protected Health Information (PHI) must run with a higher security category than those not requiring access to PII or PHI.

Application Zone Rules

The following security rules apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in ATO(ed) environments and their Application Zones:

• Production Application Zone LPAR-z/VMs must authenticate file systems before remount after VM crash.
• Production Application VMs must employ RBS AAA functions that must be provided by a common AAA server to ensure that management and user roles are common throughout a zone to prevent accidental or unauthorized access.
• An application account’s passwords for Production Application VMs must be unique for each VM instance, e.g., an apache account must be used to enforce separation of roles.
• Production Application VMs’ GID and UIDs must be unique across all file systems to prevent inter-VM access.

Presentation Zone Rules

The following security rules apply to LPAR-z/VMs and VMs running on LPAR-z/VMs in ATO(ed) environments and their Presentation Zones:

• Production Presentation Zone LPAR-z/VMs must authenticate file systems before remount after VM crash.
• Production Presentation VMs’ RBS AAA functions must be provided by a common AAA server to ensure that management and user roles are unique for each VM.
• Production Presentation VMs’ GID and UIDs must be unique across all file systems to prevent inter-VM access.
• Production Presentation Zone VMs providing intranet and extranet access must not reside on the same LPAR-z/VM.
• Production Presentation Zone LPAR-z/VMs providing extranet access can run at a lower security level than all other LPAR-z/VMs on the mainframe except those LPAR-z/VMs supporting publicly available Internet web sites.
• Production Presentation Zone LPAR-z/VMs supporting a publicly available Internet web site can run at a lower security level than an extranet.

Cloud IaaS and PaaS Infrastructure Introduction

Forward

Topics in this chapter describe the definitions, principles, and rules surrounding cloud infrastructure. CMS promotes its own strategic implementations of managed cloud environments that are based on these principles and rules. These topics discuss aspects of CMS Cloud, and refer to relevant parts of this preferred implementation. Readers may find these a useful way to better understand CMS Cloud.

Background

As identified in NIST Special Publication (SP) 800-145, The NIST Definition of Cloud Computing, September 2011, the cloud operating model has the following essential characteristics:

• On-demand self-service – A CMS business owner can provision computing capabilities, such as server processing capability and network storage, as needed automatically without requiring human interaction with each service’s provider.
• Resource pooling – The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. Examples of resources include storage, processing, memory, network bandwidth, and server virtual machines.
• Rapid elasticity – Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale back. To consumers, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.
• Measured service – Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service provisioned (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.
• Broad Network Access – Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin- or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

Leveraging these cloud characteristics obligates CMS to provide its IT community appropriate rules and guidance. The CMS TRA has historically addressed the definitions and operations of the Virtual Data Centers (VDC). This chapter expands the CMS TRA data center hosting and managed services architecture to address evolving cloud environments.

Scope

As identified in the CMS Information Security and Privacy Group (ISPG) Cloud Computing Standard, the scope of CMS cloud standards and guidance spans the cloud deployment models of public, private, community, and hybrid clouds as well as the cloud service models of IaaS, Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). This chapter, however, is limited to IaaS and PaaS Clouds.

The original Federal Cloud Computing Strategy (Kundra, 2011) defines a decision framework that should be considered for determining whether a CMS business application is a candidate for inclusion in a cloud environment. Some value drivers include:

• Efficiency
  • Higher computer resource utilization (through virtualization)
  • Lowering labor costs
• Agility
  • Speed of deployment
  • Rapid provisioning
• Access to innovation

It is important to recognize that both value and readiness are provided as dimensions to help plan cloud migrations.

It is highly recommended that CMS business owners familiarize themselves with the Federal Cloud Computing Strategy as well as the Department of Health and Human Services (HHS) document, HHS Cloud Computing Tactical Implementation and Transition, v1.2.2b, Department of Health and Human Services, July 2012 because this CMS TRA chapter does not provide distinct selection criteria or guidance for deploying into a cloud environment.

PREFERRED

However, the CMS strategic solution is to use CMS Hybrid Cloud Services, which are implemented in compliance with the CMS TRA. Whether Amazon Web Services (AWS) or Microsoft Azure Government (MAG), solutions based on CMS Cloud are preferred. Platform & Hosting Solutions provides an overview of the current offerings. CMS has announced initiatives to support additional cloud service providers.

Items in Scope

This chapter represents the CMS guidelines and standards to be used by CMS and CMS / Contractor partners for CMS Processing Environments that are implemented and operated using private or community clouds.

This chapter contains CMS’s architectural standards employed in all CMS Processing Environments that operate in a private or community cloud, as defined by NIST SP 800-146, Cloud Computing Synopsis and Recommendations, and that are using existing and approved CMS cloud infrastructure (IaaS) and platform (PaaS) managed services.

This chapter complements the CMS ISPG Risk Management Handbook Volume III: CMS Cloud Computing Standard and NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing.

Any specific “requirements” mentioned within this chapter apply only to specific items of technology and reference architecture and do not eliminate, replace, supersede, override, or nullify published CMS minimum security or privacy requirements. The security or privacy requirements stipulated in the CMS ARS and RMH have precedence over any perceived conflict among requirements.

Items Out of Scope

It is important to note that selection criteria, assessment, and acquisition of Cloud Service Providers are out of scope for this chapter.

CMS business owners and their IT advisors must perform due diligence and assessment before choosing to host and operate their business application within a CMS data center or the cloud, based upon the application’s business requirements and the application’s security risk profile. The original Federal Cloud Computing Strategy (Kundra, 2011) as well as the HHS Cloud Computing Tactical Implementation and Transition document provide some guidance for determining cloud deployment suitability. The Department has provided some guidance regarding acquisition in section 4.6 of the HHS Cloud Computing Tactical Implementation and Transition.

This chapter does not focus on how to implement a cloud infrastructure, because this is the CSP’s responsibility. Rather, it addresses how CMS can work with a third-party CSP to securely and effectively leverage business value from the CSP’s services. It is anticipated that many of the best practices pioneered by CSPs will eventually find their way into traditional data centers.

Finally, this chapter does not address the use of Software-as-a-Service CSPs.

Cloud IaaS and PaaS Infrastructure

Cloud Environment Business Rules

This topic provides a core set of Cloud Infrastructure (CI) business rules that are binding on all CMS business applications hosted and operated in a cloud solution.

BR-CI-1: Choosing a Cloud Deployment and Service Model

CMS business owners will use the CMS Cloud Computing Standard, CMS Office of the Chief Information Security Officer, Risk Management Handbook Volume III, Version 1.0, May 3, 2011, as a point of reference in (a) choosing the cloud deployment model (private, community, hybrid) and service model (IaaS, PaaS, or SaaS) based upon the business application’s identified security risk; and (b) employing CMS Chief Information Officer (CIO)-approved Cloud Service Providers.

BR-CI-3: Document the Impact of Cloud Deployment

A business application identified for deployment to and operation in a cloud environment must include in its Requirements Document those specific functional, technical, performance, service, and support requirements of the cloud environment as mandated by the CMS Target Life Cycle (TLC). The business owner must also include documentation of the Analysis of Alternatives used to determine the suitability-for-the-cloud assessment in accordance with the guidance of HHS Cloud Computing Tactical Implementation and Transition.

BR-CI-4: Engage TRB Consulting for CMS-Owned Equipment

Business owners should consult with the CMS TRB when planning to install and operate CMS-provided Government-Furnished Equipment (GFE) hardware at the cloud service provider’s facility.

Rationale:

This rule is necessary because of the increased costs and complexity in managing physical devices at a cloud provider, which run counter to cloud efficiency principles. The increased complexity also increases security risk. An analysis of alternatives should be conducted to communicate and document choices.

Examples of CMS-owned GFE include networking equipment used to connect the cloud service provider’s network to the CMSNet.

BR-CI-5: Acquisition of New IaaS or PaaS Cloud Service Providers

The acquisition and procurement of an IaaS or PaaS Cloud Service Provider must follow the guidelines set forth in Federal Risk and Authorization Management Program (FedRAMP), Office of Management and Budget (OMB) memoranda, and other appropriate federal, HHS, and CMS guidelines. Business owners are not permitted to acquire such services directly.

Only a CMS CIO-designated Cloud Management organization or HHS Office of the CIO cloud authority may procure and manage cloud environments.

Related CMS ARS Security Controls include: CA-6 - Authorization.

Rationale:

Only the CMS CIO can issue an ATO for a CMS IT processing environment.

BR-CI-6: Define Data Backup and Contingency Plans in a Cloud

All CMS business applications must evaluate and establish that defined backup and contingency plans, including the desired Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), are achievable and specified within established or planned Service Level Agreements (SLA).

Related CMS ARS Security Controls include: CP-6 - Alternate Storage Site, CP-7 - Alternative Processing Site, and CP-9 - System BackupCP-9(8) - Cryptographic Protection.

Rationale:

While it is true that many CSPs provide services that maintain multiple copies in multiple data centers, this does not constitute data backup but rather addresses reliability and availability concerns. Hosting in a cloud environment does not inherently provide data backup or contingency planning.

BR-CI-7: Cloud Resource Capacity Planning

Anticipated resource capacity needs, along with the expected need for elasticity, must be documented and communicated both in the TLC-specified document templates (such as the System Design Document) and to the CSP if these capacity levels are required. Automated actions required for exceeding those established ceilings must be established either through SLAs or with automated management rules/responses with the CMS management tools and previously agreed to by CMS Cloud as well as the business owner. This may incur additional charges to which business owners must agree. Capacity planning must be included as part of contingency plans as well.

Related CMS ARS Security Controls include: CP-2 - Capacity Planning.

Rationale:

Clouds are capable of fulfilling requests rapidly, which can potentially commit the government to unexpected or unforeseen charges. Capacity planning is necessary to maintain control over existing usage and forecast future usage, to inform business owners of costs and budgetary impacts. Additional guidance is available in NIST SP 800-34.

BR-CI-8: Separate Production, Management, and Non-Production Resource Clusters

Production and Non-Production environments must use distinct resource clusters, as defined above in Cloud Architecture, Resource Aggregation – Resource Clusters and Resource Pools. In addition, the Management Zone (for both Production and Non-Production) must have at least one resource cluster distinct from the Production and Non-Production environments.

Related CMS ARS Security Controls include: SC-6 - Resource Availability

Discussion:

This means there are at least three (3) resource clusters in any CMS TRA-compliant IaaS or PaaS cloud.

Rationale:

The Management Zone cluster is distinct from the Production and Non-Production clusters to ensure that there is no contention for resources.

BR-CI-9: Applicability of Multi-Zone Architecture

IaaS clouds must implement the CMS Multi-Zone Architecture as defined in the CMS TRA. PaaS clouds must be based on an infrastructure that meets the CMS Multi-Zone Architecture.

Rationale:

The CMS Multi-Zone Architecture can and has been implemented in IaaS clouds. The benefits of defense-in-depth architecture can be achieved using cloud technologies, even if the architecture is not an exact one-for-one match with virtualized data centers. For example, clouds may offer different services to perform the role of the firewall in the multi-zone architecture. System developers utilizing cloud technologies are encouraged to consult with the TRB to ensure TRA and defense-in-depth principles are being addressed. Business Rule CI-11 enables the use of such services.

Consider leveraging FedRAMP to make it easier to embrace tested and commercially available cloud services. IaaS clouds must separate information flows logically or physically using FedRAMP-approved mechanisms and/or techniques to accomplish required separations.

BR-CI-10: (Rule Withdrawn after TRA 2016R1): Required Physical Components

BR-CI-11: Cloud Services Covered by a CMS ATO May Be Used in Lieu of Virtual Network Elements

The CMS TRA Multi-Zone Architecture permits the use of certain cloud services instead of virtual machines or applications only if those services hold a CMS ATO.

Rationale:

Some CSPs may offer services rather than virtual machines to provide critical CMS services, such as firewalls, load-balancing, or XML acceleration.

Cloud Architecture

As an extension of the CMS Common Enterprise Infrastructure environment, the cloud infrastructure must conform to the same guidelines and policies as the other CMS operating environments. Cloud architectures at CMS are built on:

• Cloud infrastructure components
• Cloud multi-zone architecture
• Cloud-suitable applications

The infrastructure components serve as the architecture’s “building blocks.” The cloud multi-zone architecture outlines the “city plan” for constructing with those building blocks. Like a city, there are shared services that are defined for clouds to provide certain capabilities that are above and beyond traditional data centers. Application software can leverage the cloud architecture to provide business services that meet cloud computing expectations of scalability, elasticity, and self-service. The following subtopics address these architectural aspects.

Cloud Infrastructure Components

Some Cloud Service Providers may offer all three types of cloud service models (IaaS, PaaS, and SaaS). The delineation between IaaS and PaaS is often blurred depending on the CSP’s service offering as described in its cloud service catalog. More common are CSPs that coordinate with third-party providers or system integrators to supply and operate SaaS and/or PaaS independent of the IaaS offerings.

For purposes of discussion within this chapter and as defined by NIST, IaaS represents the core computing resources of CPU, memory, and virtual machine hypervisor instances; storage capacity; LAN throughput and Internet connectivity; and management software for managing these resources. Additional IaaS services often include backup storage for off-line / off-site storage, infrastructure and hypervisor security services, additional logging and reporting services, load balancing services, relational database and unstructured database storage services, and cloud administrator account management services to allow monitoring and managing of PaaS services. Other services such as database administration or web hosting typically fall under the PaaS category.

Role of Virtual Machines in Cloud

The core infrastructure component of the IaaS cloud is a virtual machine. A VM is a set of resources, provided by one or more physical devices, configured to provide x compute cores, y memory, z disk storage, and t network interfaces. These values for (x, y, z, and t) vary by provider. The VM can run any general-purpose operating system certified by the IaaS provider. In addition, the VM may also support special purpose components such as routers, firewalls, Graphics Processing Units (GPU), and Extensible Markup Language (XML) appliances, which use manufacturer-hardened OS, for virtual security appliance roles.

Not all flavors of OS are supported by the specific hypervisor(s) in use at a CSP. Most CSPs offer a catalog of the OS images their infrastructure supports. In addition, CMS may provide additional security-hardened images as needed, especially if virtual security appliances are necessary.

Whether a platform is IaaS or PaaS, the VM is the core technology that facilitates on-demand provisioning. The primary difference from the standpoint of the cloud user is that in IaaS, the VMs are provisioned on demand while such details are typically not transparent to PaaS users.

Types of Virtual Machines

IaaS Clouds use two kinds of VMs: application and infrastructure. This intentionally mimics the physical machine configurations typically found in data centers.

Application VMs operate application software such as:

• Database servers (both relational and NoSQL)
• Web servers
• Java 2 Platform Enterprise Edition (J2EE) application servers
• Commercial Off-the-Shelf (COTS) applications

Infrastructure VMs provide virtual equivalents of physical data center infrastructure components, including:

• Virtual firewalls and switches
• Virtual caching proxy servers
• Virtual load balancers
• Virtual network intrusion detection system devices
• Virtual XML acceleration processors
• Virtual machine management servers
  • Virtual Lightweight Directory Access Protocol (LDAP) servers
  • Virtual Domain Name Services (DNS) servers

The IaaS cloud configuration combines both kinds of VMs into a multi-zone architecture that meets the security and privacy requirements mandated for CMS systems.

In some situations, the IaaS cloud vendor may offer physical instances for some of the devices listed. There are valid reasons to choose physical devices over virtual devices if the choice is available. For example, using a physical firewall rather than a virtual appliance may improve performance or have a lesser exposure to security vulnerabilities. Due to the rapidly changing cloud infrastructure market, it is important to assess these options within the context of required CMS security and business requirements.

In other instances, the IaaS cloud vendor may offer these capabilities as services, without specifying virtual machines. For example, Amazon Web Services Security Groups and Elastic Load Balancers are not defined as virtual machines.

Services covered by a CMS ATO (above and beyond the FedRAMP Authorization Process) may be used in lieu of virtual machines in the CMS Multi-Zone Architecture. Satisfying the CMS ARS is a higher bar than the FedRAMP controls. In other words, it is not sufficient to satisfy FedRAMP to meet CMS’s requirements. See CMS SaaS Governance for more information.

Hosting CMS Government-Furnished Equipment at a CSP

Depending on the CSP, it may be possible to place CMS GFE into a cloud environment. Typically, the CSP would cage off and use this equipment for very specific purposes. For cost reasons, this is generally prohibited, as reinforced by Business Rule CI-4.

There are, however, several legitimate considerations for hosting GFE in a cloud environment. The following considerations are the most common:

• Non-virtualized hardware may be more suitable in some cases than virtual hardware. This is true for applications that may leverage specific hardware capabilities or that are extremely performance intensive.
• Some applications may not be suitable for a virtualized environment.
• Specialized, non-general-purpose hardware may be required by CMS in the cloud environment.
• Some data must be stored on GFE rather than third-party storage hardware.
• Greater security may be realized with specialized appliances than general-purpose VMs.

Use of GFE constrains available cloud capabilities, such as bursting, elasticity, and managed services. By hosting GFE in the cloud, CMS loses many of the benefits of cloud computing.

Cloud Multi-Zone Architecture

The CMS TRA defines multiple zones in the architecture, including the Presentation Zone, Application Zone, Data Zone, a Transport Zone, and a Management Zone. In a traditional hosted managed services environment, these zones would be physically separated, with redundant paths and multiple (layered) security devices along the paths.

The cloud environment must be adapted to fit the CMS Multi-Zone Architecture. Since each change introduced to the standardized structure results in higher cost and management overhead for CMS, one benefit of cloud architectures is the standardized structure that employs common equipment, network interconnects, and management servers. The tradeoff is the need to provide sufficient detection and preventive security controls to meet CMS requirements.

In an IaaS / PaaS cloud environment, the devices that comprise the various zones (including servers and storage) are usually virtualized instances. The network itself is often a combination of services as well as virtualized and physical devices making extensive use of VLANs.

There are, of course, certain risks to be considered in cloud environments, including:

• High-performance applications may experience performance degradation due to virtualization overhead.
• Maintaining compliance with licensing contracts can be challenging due to relative ease of provisioning, elasticity, and bursting. These features may impact licensing costs, and not all software licenses are cloud compatible.
• Not all software is equally suitable for deployment in a cloud environment.
• For PaaS, the platform is typically upgraded for all customers simultaneously with no option to stay on back-level software.
• The hypervisor introduces some additional security risk because it lies behind the cloud’s private infrastructure.
• Ease of creation of virtual machines may lead to VM sprawl. Although VMs are efficient users of hardware, a VM requires the same amount of technical labor as a physical machine for services above the IaaS layer. Thus, costs can and will grow with elasticity.
• For PaaS, the platform is typically proprietary. Consequently, applications written for this platform will not be portable to other platforms (PaaS or otherwise). There is a very real danger of vendor lock-in when dealing with PaaS.

Resource Aggregation – Resource Clusters and Resource Pools

Cloud computing involves two levels of resource aggregation: resource clusters and resource pools. A resource cluster is defined as a group of connected servers that work together so that, from the point of view of aggregating resources such as CPU processing and memory, they can be viewed as though they were a single computer. For example, a resource cluster might have 30 CPUs and 120GB of RAM. In a community cloud, a CSP builds resource clusters and assigns them to the community. The resource cluster is only available to members of the community.

A resource pool is a set of available CPU and memory resources, and generally consists of multiple “like” resources, i.e., of the same type. In a community cloud, once the resource cluster(s) are created, resource pools are defined and allocated to members of the community. Resource pools may be organized in a hierarchy in which resource pools are subdivided into subordinate resource pools. For example, a resource pool could be defined as “Administrative” and have sub-pools of “HR” and “Payroll.” At CMS, the rule is to use one resource pool per business application.

CMS Reference Architecture

Virtualized Multi-Zone Cloud Infrastructure depicts a conceptual CSP cloud implementation for a CMS reference architecture. Virtualized Multi-Zone Cloud Infrastructure illustrates several key concepts when deploying systems on a cloud infrastructure. To provide a defense-in-depth posture, the firewall and network devices managing Internet communications must be implemented as physical devices. If they were implemented on the same shared VM host, a single exploitation of the hypervisor would compromise the entire infrastructure.

The enclosing boxes in Virtualized Multi-Zone Cloud Infrastructure represent three different physical sets of resources, presented clockwise as the CMS-provided Equipment Cage (at 11 o’clock), the Production Zone Resource cluster at 1 o’clock, and the Management Zone Resource cluster, at 8 o’clock. The single physical firewall at the center of the diagram and the virtual switches are generally part of the CSP IaaS. The addition of virtual firewalls between processing zones meets CMS security requirements regardless of whether CMS manages only the firewall rules or the entire firewall instance.

For technologies that require shared responsibilities, CMS and the CSP must document the demarcations (e.g., firewall configurations managed by the CSP and firewall rules managed by CMS). Separate resource clusters must be defined for production, non-production, and Management Zones. Resource pools within a resource cluster are defined for each business owner or application.

Virtualized Multi-Zone Cloud Infrastructure (page 11)

The cloud environment offers additional architectural flexibility. Some CSPs provide a service through which customers can host agency-provided equipment at the CSP in a caged environment. CMS may choose to implement COTS or Government-Off-The-Shelf (GOTS) products, additional security monitoring equipment, or specialized equipment that handles CMS’s most sensitive data—e.g., Protected Health Information or Federal tax Information (FTI). Business owners should carefully consider costs when using the CSP’s customer hosting services. CMS or the CSP may be responsible for monitoring and managing this equipment.

Note: The diagram Virtualized Multi-Zone Cloud Infrastructure greatly simplifies the details of the Internet connection, especially the requirement for Trusted Internet Connection (TIC) as required by FedRAMP. The CMS ARS provides the details for wide area networking.

Cloud Services Architecture

A cloud can be represented functionally as the combination of many managed services. The following services are needed in a CMS Cloud. It is unlikely that any one commercial cloud offering would contain all such services; however, applications destined for the Cloud and with a DevOps focus need to ensure that these capabilities are available.

Here are cloud services organized from the perspective of the primary user:

Customer View

• Self-Service portal
• Cloud Service Provider Help Desk services

System Programmer View

• CSP Application Programming Interface (to communicate with the CSP services and cloud management infrastructure)

Systems View

Virtualized machine resources

• Virtualized storage resources
• VM configuration management (different from Software Configuration Management)
• Resource and Capacity Management services
• Application Performance Management services
• Storage Management services
• Virtual Machine Image library
• License-tracking services
• Run-book automation services

Security View

• Security services (including firewalls, audit logging, security monitoring, and other such services)
• Remote Log-in services

Network Operations View

• Backup and Archival services
• Virtual Network services
  • VLAN Management services
  • Internet Protocol Address Management services
  • Dynamic Host Control Protocol (DHCP) / DNS services
  • Virtual Firewall services
  • Authenticated Time Servers
• Application Performance Monitoring services

Cloud Service Provider View

• Billing and Payment services
• Hypervisor infrastructure

Data centers commonly use many of these tools today. The highly automated nature of cloud environments now makes their use mandatory.

Cloud Environment Governance and Management

As noted in NIST SP 800-146, Cloud Computing Synopsis and Recommendations:

Attempts to describe cloud computing in general terms have been problematic because cloud computing is not a single kind of system, but instead spans a spectrum of underlying technologies, configuration possibilities, service models, and deployment models.

Many factors influence the definition, benefits, risks, and implementation of a cloud infrastructure. From a pragmatic standpoint, deploying into a cloud infrastructure relies on the same underlying technologies, principles, and processes of a managed services virtualized data center. A cloud infrastructure differs from a virtualized data center by providing the following additional capabilities:

• Self-service, allowing authorized users to provision servers and applications on demand, on behalf of business owners, using streamlined processes
• Automation, beyond that of virtualized and physical data centers
• Rapid elasticity, allowing applications to meet short- and long-term growth goals in a regulated but automated fashion
• Multi-tenancy (in Community Clouds), allowing multiple cloud customers to share resources while securely separating resources for one customer from those of another
• Metered billing, which allows CMS to lease rather than own the cloud resources and pay only for what CMS uses from the CSP

Utilizing both the proper controls, as defined by applicable CMS and federal security mandates, and the requirements for the handling and processing of CMS information and information systems, will help assure a trusted, shared environment that provides the benefits and efficiencies of the cloud environment and cloud solution providers.

 PREFERRED

The CMS strategic implementation that supports these requirements is CMS Cloud. Governance and management facilities include:

• CMS Cloud governance and management plan
• CMS Cloud Costing and Estimation Tool (CET)
• CMS Cloud Estimate at Completion (EAC) 2.0 Dashboard
• Cloudtamer.cms.gov (Kion) (Password Required)

Cloud Environment Management

Controlling and managing the cloud environment requires deployment of cloud management tools.

In aggregate, these tools must provide the following capabilities:

• Cloud virtual resource management
• Cost management
• Capacity management
• License compliance management
• Security management
• Automation of virtual resource configuration management

The following subtopics address each of these cloud management tool capabilities.

Cloud Virtual Resource Management

Cloud resources are virtual resources temporarily allocated to the business owners on demand and by request. At some point when a business owner determines that it no longer requires these resources, the business owner may release the resources back to the CSP’s available resource pool. If the business owner fails to do this, the organization will continue to pay for resources that are no longer utilized. Even though the cloud resource capacity may seem endless, the applications need to be designed and configured to operate with a specific minimum and maximum capacity in mind. The capacity consumed should be monitored carefully to ensure that costs remain bounded within planned parameters. The CSP’s cloud resource management tools and reports are designed for these purposes. At a minimum, these tools must provide:

• Resource provisioning
• Resource de-provisioning
• Resource accounting and inventory
• Capacity management

Cloud Resource Life Cycle

There are six states in the cloud resource life cycle:

• Provisioned virtual resources – have been created using resources either previously cleansed and made available for use or are archived resources that must be restored to operational status. Before making any resources operational, preparatory steps (such as enabling encryption) may be necessary.
• Operational resources – have been provisioned and are running normally.
• Elastic resources – have already been provisioned but may be bursted or made elastic (as needed) by adding or removing capacity to the resources. The last atomic unit of a resource may not be removed except during resource de-provisioning.
• Archived resources – no longer occupy execution resources but do occupy storage. These resources may be provisioned again in the future.
• Cleansed resources – were previously used by CMS and have been wiped based on CMS ARS requirements. Where wiping is impractical, such as with Solid-State Drive (SSD) technology, resources must have been previously encrypted and data handled in accordance with CMS ARS requirements.
• De-provisioned resources – have been fully reclaimed by the CSP’s hypervisor systems.

Resource Provisioning

Once CMS has contracted for cloud services, actual provisioning of IaaS and PaaS services within the cloud must adhere to the CMS TRA, the CMS ARS, the CMS ISPG Cloud Computing Standard (RMH Volume III, Version 1.0), and any other federally mandated policies.

Table - Resource Provisioning Methods presents the three common methods for provisioning resources in existing clouds. Not all vendors accommodate every method. Some of the methods may be accommodated through different means and capability levels.

Whether a CSP or a CMS application owner manages the resource provisioning, the capability to monitor and manage the resources’ performance characteristics must be made available to both parties. This helps ensure the expectations of and consistency in quality and levels of service.

It is essential to carefully control the use of APIs for resource provisioning. Some form of logging, auditing, and notification should support the automated provisioning of resources. Uncontrolled use of automated provisioning routines could have devastating consequences in service performance and cost escalation. Thus, rigorous control is mandatory for the capability to perform automated provisioning and de-provisioning.

CSPs offer tools to gauge performance of their service offerings. Additional tools may be considered to help CMS measure performance characteristics of a CSP’s full services. Aggregation and analysis of CSP data along with CMS data is a likely use case.

System owners must clearly understand the CSP provisioning policies and the physical location of the resources. CSPs have different allocation policies and practices for normal provisioning and elasticity capabilities. Some CSPs may support elasticity within the confines of a specific data center, and only migrate to alternative sites based on complete outages; others may spread provisioned resources over several data centers as a matter of course.

Resource De-Provisioning

Disposing of technical resources after retiring a business capability is not always a clear and simple process. It is even less so in a cloud, where previously allocated resources return to a pool to be reused minutes or even seconds later. Identifying all dependent resources can be particularly difficult in a cloud environment. In private data centers, these types of remnants do not typically have the significant impact on resources or expenses that they do in a private or community cloud environment, where services are billed based on metered consumption and resources are shared among the cloud’s tenants.

CSPs supply resource management tools to manage a business owner’s resource consumption. Depending on the CSP’s infrastructure capabilities, pay-as-you-go services can be very dynamic in nature and difficult to track. In cloud environments, where resources may be manually provisioned for temporary use through bursting or elasticity, the business owners must remember to de-provision the resources when they are no longer required. A follow-up audit may be necessary because CMS may not be aware that copies of data, via mirroring and similar redundancy services, may reside on different logical units of the CSP’s infrastructure.

Although de-provisioning can be performed in either manual or automated solutions, automated de-provisioning is generally recommended. Manual de-provisioning is not properly aligned with the security architecture principle of decreased system footprint. Manual de-provisioning also increases risk of unnecessary costs and is likely to be more error prone than automated. To operate successfully, both automated and manual de-provisioning require reliable system inventory and architectural information.

License Management

Provisioning and de-provisioning virtual machines in an IaaS cloud may generate software license issues. The business application must have sufficient licenses to cover its fully elastic configuration (unless previously negotiated). If bursting was enabled, there may be implications to licensed software that is licensed per CPU or core.

Although open-source software at CMS may be freely employed, there can be associated licensing fees for support, which may limit the number of supported instances of that software.

Automated Virtualized Environments and APIs

CSPs operate an advanced, virtualized environment, using tools to manage multi-tenancy, self-service, and resource consumption tracking that provide expected cloud benefits. Due to the economics of operating a cloud data center, CSPs rely heavily on automation to reduce their labor costs and permit rapid bursting and elasticity.

The need for highly automated environments has driven CSPs to provide APIs to their environments. Essentially, a cloud API allows a cloud consumer to control cloud resources via a programmatic interface instead of using a manual, cloud consumer portal. For example, APIs typically allow for such activities as starting VMs and expanding capacity.

The cloud industry has not yet standardized on APIs for managing cloud environments. Instead, other providers are supporting de facto standards such as the Amazon Elastic Compute (EC2) APIs in both commercial and open-source products (such as Eucalyptus). Currently, it is too early to standardize on a vendor API because of the immature state of the cloud industry. As a result, programming to a cloud vendor’s API involves vendor lock-in. Architectural design techniques may mitigate this risk to some degree, and business owners should consider such mitigations when deploying business applications to the cloud. For example, Apache libcloud provides API wrappers for proprietary cloud APIs, allowing consumers to program to a compatibility layer instead of vendor-specific APIs. Although this approach may be preferable, using API wrappers requires thorough technical analysis of the business application’s requirements.

Cost Management Implications

Given that dynamic resource management is a key element of the cloud value proposition, cost management and its architectural impact is a critical element of cloud resource management.

The cloud’s cost management component must be able to provide detailed resource utilization billing, allowing CMS data center operations to identify the costs associated with CMS business applications. In an IaaS cloud, this means accounting for CPU, memory, network bandwidth, and other agreed-upon billable resources. In a PaaS cloud, the billable resources may be number of user accounts, number of customer accounts, or other metered resources.

Pay-as-you-go billing may have an architectural impact to custom business applications. For example, it is possible that certain resource tradeoffs (such as memory vs. disk I/O) will lower the overall costs. CMS application developers and contractors should provide alternative architectures, when appropriate, to reduce overall costs.

Elasticity, while an attractive concept, has financial impacts that have not been fully explored at CMS. CMS business owners will need to include the cost of resource elasticity in their estimated operational cost for a business application. Cost models should be capable of translating pay-as-you-go billing to existing billing models until pay-as-you-go becomes acceptable in the CMS financial environment. For example, it may be feasible to have a model that uses prior-year average (or even moving average) billing to determine future costs once applications achieve a resource utilization steady state.

Resource elasticity does not normally include the licensing cost associated with COTS software. Provisioning a VM does not mean that the OS and application software are properly licensed. It is CMS’s responsibility to ensure compliance with licenses. Although some CSPs offer license management, it is typically not the CSP’s responsibility to do so.

Capacity Management

The management tools must provide authorized users a snapshot or “dashboard” view, at any given time, of the capacity management statistics, such as percentage of resources utilized, available capacity, growth trends, etc., for a range of duration (day, week, month, year). These tools should have threshold settings that take some automated action when limits are exceeded. These actions could range from simple notifications (alarms) to automatically provisioning more VM resources or VMs (at predetermined allocation increments). Many of these features depend on the CSP and its offered tool set. Different CSPs offer a variety of tool sets based on the cloud framework and vendor-specific technology in use. In addition to thresholds, “caps” should be considered. Caps are soft thresholds put in place on various cloud resources (such as CPUs, CPU cycles, Terabytes of storage, memory, and bandwidth) that may not be exceeded without a certain level of CMS approval. This approach would prevent a spiraling of costs during an unusual surge situation, much like a circuit breaker on an electrical circuit.

Current CMS virtualization business rules prohibit over-subscription of virtual machines and resources in CMS Production Environments. This means that CSPs may not overburden physical machines under the assumption that workload overlap is unlikely. Each production VM must have enough capacity to run at 100 percent load (peak capacity) without impacting another production VM.

Cloud Service Management Support

Cloud operations and support should be the same as the ongoing operational support of any other system / technology in the CMS enterprise. In fact, cloud support should leverage existing support infrastructure and managed services, such as operations staff, help desks, and service management processes. The key distinction between data center and cloud service management support is the varying degrees of managed services and possibly different service providers / contractors for the IaaS and PaaS. This also means there is potentially a large set of stakeholders involved in communications. The larger communications component necessitates more coordination across processes and reporting to help CMS make informed decisions and provide necessary oversight to the CSP and associated contractor(s) regarding their contracted performance.

Service Level Management

All ongoing operations and support should follow a formal process framework, be adequately documented, and be part of a continuous process improvement regimen. SLAs with the CSP should be no different from SLAs with any other CMS data center hosting vendor that provides integrated support and services to CMS. With some cloud providers, IaaS SLAs may be the CSP’s responsibility while PaaS SLAs are the responsibility of an associated integration contractor or broker.

This separation of concerns requires better CMS oversight to assure appropriate management of service levels. The details of service level management are outside of the scope of this chapter, but are addressed by CMS Cloud: Defining Service Level Objectives (SLOs).

IT Processes and Best Practices

Using a CSP makes the integration of standard IT processes and procedures more complex. Problem management, incident management, change management, and configuration management remain critical processes, but often their responsibility is shared between the CSP and associated integration and application contractors. IaaS changes, patches, and configuration adjustments are the CSP’s responsibility. PaaS changes and configuration settings are typically the responsibility of the integration or application contractor. CMS is responsible for ensuring smooth identification, reporting, and resolution of issues.

Cloud Security Requirements

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

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

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

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

 PREFERRED

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

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

Cloud Security Objectives

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

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

Cloud computing implementations include the following major security objectives:

• Preventing unauthorized access to cloud computing infrastructure resources. This includes implementing security domains that have logical separation between computing resources, e.g., logical separation of customer workloads running on the same server by VM monitors (hypervisors) in a multi-tenant environment and using secure-by-default configurations.
• Managing hypervisor threat vectors. Hypervisor attack threat vectors include CSP users and CSP employees. Hypervisor vulnerabilities include poor configurations, missed or delayed security patching, or unauthorized activities from a privileged user. Because hypervisor exploitation can have disastrous results, CMS mandates that all hypervisor solutions must be Type 1 (native / bare metal)-based products. Industry best practices should be implemented where available or the vendor’s own published guidelines should be used.
• Minimizing shared network access. Most CSPs have some common network infrastructure components between various cloud customers; these shared network infrastructure components present significant risk because a single breach of a shared component could compromise all users of a CSP’s service. Thus, configurations must adhere to best practices, and exceptions must be well understood, documented, and accepted by users of a CSP’s service.
• Managing privileged user access. CSP privileged users with access to the hypervisor should be kept at a minimum. CSPs should ensure the timely removal of access based on a CSP employee termination event or when access is no longer required (e.g., a job transfer). CSP targets for managing privileged user access in both cases should be real-time removal of access, audit records should be available to CMS auditors that establish when a request was made, and the actual removal of privilege.
• Ensuring that appropriate security safeguards are deployed at the CSP. CMS should conduct independent assessments to verify that appropriate safeguards are in place. This includes traditional perimeter security measures in combination with the additional safeguards required for cloud computing.
• Defining trust boundaries between CSPs and the CMS consumers. It is crucial to clearly document the responsibility for providing security and that the consequences for non-deployment of agreed-upon security controls by the CSP are well-defined in contracts and SLAs.

CMS Cloud Roles and Responsibilities

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

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

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