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.

 

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

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

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