CMS Technical Ref Arch_ v 2.0_11124009.pdf

Restricted Distribution Sensitive – For Official Use Only

Department of Health and Human Services

Centers for Medicare & Medicaid Services IT Modernization Program

CMS Technical Reference Architecture

Version 2.0

November 24, 2009

CMS Technical Reference Architecture i Version 2.0 November 24, 2009

Restricted Distribution Sensitive – For Official Use Only

Foreword

This Technical Reference Architecture, Version 2.0, provides the technical architecture approach and technical reference standards of the Centers for Medicare & Medicaid Services (CMS).

This Architecture standard has been reviewed and accepted as a foundational component of CMS’ Enterprise Architecture in accordance with CMS’ Information Technology (IT) governance process. The Technical Reference Architecture consists of this foundation document and the CMS Technical Reference Architecture Supplements, authorized and approved by the CMS Chief Information Officer and CMS Chief Technology Officer.

CMS’ Chief Technology Officer leads the development of this Architecture with the support of all components of the Office of Information Services (OIS) and input from CMS’ IT contractors.

The Agency maintains the Architecture according to its established Business Rules, as described in CMS TRA – Business Rules Supplement, Version 1.0.

This CMS TRA document and the CMS TRA Supplement documents, as well as their development and maintenance schedules, are managed by the CMS Enterprise Architecture and Strategy Group (EASG)/Division of IT Policies, Procedures and Audits.

Any changes to the Technical Reference Architecture must be approved by the Chief Technology Officer of the Agency. Any request for grant of special considerations should go to the CMS Technical Review Board (TRB). The CMS TRA – Architecture Change Request Process Supplement, Version 1.0 describes the process for handling all requests for changes.

U/s/ November 24, 2009 U Henry Chao Date Chief Technology Officer (CTO) Office of Information Services

CMS Technical Reference Architecture ii

Restricted Distribution Sensitive – For Official Use Only

Record of Changes

Number Date Reference A=Add, M=Modify, D=Delete

Description of Change CR #

1 November 24, 2009 All Formal release of Version 2.0 NA

CR: Change Request

CMS Technical Reference Architecture iii

Restricted Distribution Sensitive – For Official Use Only

Table of Contents

1. Introduction

1.1 Background

1.2 Vision for the CMS Technical Architecture

1.3 Purpose

1.4 Scope

1.5 Technical Reference Documentation Framework

1.6 Certification & Accreditation

1.7 Alignment of FEA Technical Reference Model and CMS Technical Reference

Architecture

1.8 Intended Audience

1.9 Relevant Documents

1.10 Document Organization

2. CMS Infrastructure Architecture

2.1 Presentation, Application, and Data Zones

2.1.1 Presentation Zone

2.1.2 Application Zone

2.1.3 Data Zone

2.2 Windows Zones

2.3 Management Zone

2.3.1 Management DMZ Segment

2.3.2 Shared Tools Segment

2.3.3 Firewall Management Tools Segment

2.3.4 Security Tools Segment

2.3.5 Backup Tools Segment

2.3.6 UNIX Tools Segment

2.3.7 Windows Tools Segment

2.4 Wide Area Network

2.4.1 CMS WAN Architecture

2.5 Global CMS Standards

2.5.1 Data Center Naming Convention

2.5.2 Physical Separation of Switches

2.5.3 Infrastructure—Dedicated Versus Shared Components

2.5.4 Mid-Tier Server Ports

2.6 Infrastructure Security Considerations

3. CMS Infrastructure Services

3.1 Database Services

3.2 Storage Services

3.3 Domain Name Services

Centers for Medicare & Medicaid Services Table of Contents

CMS Technical Reference Architecture iv

Restricted Distribution Sensitive – For Official Use Only

3.4 Security Services

3.4.1 IPSec VPN Services

3.4.2 Firewall Services

3.4.3 Intrusion Detection System / Intrusion Prevention System Services

3.5 Backup / Restore Services

3.6 Infrastructure Monitoring Services

3.7 Content Deployment Services

3.8 Infrastructure Service Security Considerations

4. CMS Application Services

4.1 Web Services

4.2 Middleware Services

4.3 File Transfer Services

4.4 Application Monitoring Services

4.5 Security Considerations for Application Services

Appendix A. CMS Products / Standards Selection List

Acronyms

List of References

CMS Technical Reference Architecture v

Restricted Distribution Sensitive – For Official Use Only

List of Figures

Figure 1. CMS TRA Document Framework

Figure 2. CMS Multi-Zone Architecture

Figure 3. High-Level View of the CMS Wide Area Network

List of Tables

Table 1. Data Center Naming Conventions

Table 2. CMS Infrastructure Services Overview

Table 3. CMS Application Services Overview

Table 4. CMS Product Selection List for CMS Technology Architecture

CMS Technical Reference Architecture 1

Restricted Distribution Sensitive – For Official Use Only

1. Introduction

1.1 4BBackground The Centers for Medicare & Medicaid Services (CMS) are undertaking the development of a large-scale Information Technology (IT) Modernization initiative to improve the quality and delivery of health care services to beneficiaries, providers, and business partners. This initiative spans the CMS enterprise and includes development and implementation of mid-tier and mainframe infrastructure as a multi-zone architecture that is crucial to the effective operations of all CMS Production environments, including the Enterprise Data Centers (EDC) Program, Baltimore Data Center (BDC), and Agency business. As CMS implements the components of the IT Modernization, the Agency needs new policies, processes, and procedures for implementing the Agency’s technical vision and a secure operating environment for the CMS enterprise.

1.2 5BVision for the CMS Technical Architecture CMS will accomplish its vision to improve the quality and delivery of health care services to beneficiaries, providers, and business partners through a collaborative, evolutionary partnership.

This CMS Technical Reference Architecture (hereafter simply “CMS TRA”) is an essential element of that partnership.

This CMS TRA was developed to provide a standard technical reference for all of the Agency’s production environments (hereafter simply “CMS Production Environments”) and to communicate the architecture decisions determined by CMS/Contractor partnerships to date. It is anticipated that the Agency will require several years to fully implement this Technical Reference Architecture and its associated supplements throughout the CMS Production Environments.

The CMS TRA is intended to:

• Provide technical reference standards for all CMS Production Environments and future application designs to ensure a secure operating environment

• Communicate CMS’ architecture approach and standards as determined by CMS

• Identify CMS’ target technical environments to assist Agency contractors in developing their transition approaches

• Provide technical standards for use in future EDC, Enterprise System Development

(ESD), and CMS task orders.

The current EDCs are built to CMS TRA standards. The Office of Information Services (OIS) recognizes that the CMS TRA will be implemented in a phased approach on an Agency-wide basis. CMS business application owners and the owners of non-EDC production operations will work with OIS to establish transition plans for implementing these standards. These transition plans will establish the priorities for addressing how existing operations and applications will

Centers for Medicare & Medicaid Services Introduction

CMS Technical Reference Architecture 2

Restricted Distribution Sensitive – For Official Use Only minimize CMS’ security risks until migration to an EDC or a fully TRA-compliant operational environment.

1.3 6BPurpose This document articulates the technical architecture of the CMS Production Environments, and is designed to assist all Agency Business Partners in developing to, transitioning to, and maintaining the CMS Production Environments in accordance with CMS’ enterprise technical architecture. The CMS technical architecture supports five critical technical objectives that enable the Agency’s health care mission: (1) secure the CMS operating environment, (2) move CMS Production workloads efficiently, (3) provide appropriate and sufficient disaster recovery capability, (4) facilitate the migration and transition of CMS business owner applications into new production environments, and (5) build an enterprise technical architecture that anticipates and responds to the CMS mission and business needs.

1.4 7BScope This document and its associated supplements represent the agreements on standard architecture to date by the CMS/Contractor partners for the CMS Production Environments. The requirements stated in this document reflect the agreed upon industry and government best practices to support the most viable approach for CMS that meets legislatively mandated security and privacy requirements and current technical standards.

1.5 8BTechnical Reference Documentation Framework The CMS TRA consists of a document set: the foundation CMS TRA document and the supporting CMS TRA Supplement documents. The CMS TRA document focuses on technical architecture definition and alignment with Federal Enterprise Architecture (FEA) models. The CMS TRA Supplements focus on engineering detail to aid in consistent development and implementation in CMS environments.

This CMS TRA document lays the groundwork for additional, more specific, technical architecture and implementation described in the CMS TRA Supplement documentation for all CMS data center environments. Figure 1 depicts the overall framework for the evolution of CMS technical documentation.

As depicted in Figure 1, the foundation CMS TRA document is the starting point and authoritative source for CMS’ technical reference documentation. The CMS TRA document supports the second and third specific layers of detail. At the second layer, the CMS TRA Infrastructure Services document the CMS infrastructure, while the CMS TRA Application Services describe CMS applications at the third layer. The CMS TRA Infrastructure Services supply the foundation for the CMS TRA Application Services, which in turn provide the foundation for CMS workloads and applications.

CMS Technical Reference Architecture 3

Restricted Distribution Sensitive – For Official Use Only

Foundation CMS TRA Document

CMS Enterprise Architecture

CMS TRA Infrastructure Services

TRA Security Services Supplement

TRA Data Archiving Services Supplement

TRA Distributed Systems and Network Virtualization Supplement

TRA DNS Services Supplement

TRA Wide Area Network Services Supplement

TRA Distributed Systems Platform Supplement

CMS TRA Application Services

TRA Access Control and Identity Management Supplement

TRA Java EE Application Development Guidelines Supplement

TRA .NET Developer Guidelines Supplement

Figure 1. CMS TRA Document Framework

The CMS TRA establishes a clear, direct, and auditable linkage between all documentation of the CMS technical architecture and its implementation, from the CMS TRA document through the Infrastructure Services Supplements and Application Services Supplements. Thus, the CMS TRA provides the basis for the increasing level of detail and definition of the infrastructure and application services that operate within all CMS data center environments.

The CMS TRA is intended for use by CMS stakeholders, including business owners, OIS, application development contractors, and infrastructure and operations contractors. Additional supplemental volumes will be published on specific technical solutions.

CMS Technical Reference Architecture 4

Restricted Distribution Sensitive – For Official Use Only

1.6 9BCertification & Accreditation The Production Environment Shared Infrastructure must pass a Certification & Accreditation (C&A) prior to executing production applications. The Production Environment Contractor will support a third party C&A evaluation team selected jointly by CMS and the Production Contractor. The necessary EDC Contractor support for this activity includes supplying physical access to the CMS Production Environment facilities, including the Security Operations Center/Network Operations Center (S/NOC); supplying access to the CMS infrastructure hardware; and supplying access to any documentation identified by the C&A evaluation team.

The C&A evaluation team uses the CMS TRA during the evaluation process. All CMS Production Environment C&As must comply with CMS’ published C&A procedures and National Institute of Standards and Technology (NIST) Special Publication (SP) 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, May 2004.

1.7 10BAlignment of FEA Technical Reference Model and CMS Technical Reference Architecture

To facilitate efforts to transform the federal government into one that is citizen centered, results oriented, and market based, the Office of Management and Budget (OMB) established the Federal Enterprise Architecture (FEA) Program, which is building a comprehensive business-driven blueprint of the entire federal government. The FEA is constructed through a collection of five interrelated “reference models” designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across agencies.

The FEA Technical Reference Model (TRM) provides the standards, specifications, and technologies that collectively support the secure delivery, exchange, and construction of business and application components (Service Components) that may be used and leveraged in a Component-Based or Service-Oriented Architecture. It also unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the reuse and standardization of technology and Service Components from a government-wide perspective.

The FEA TRM is comprised of four core Service Areas. Each Service Area represents a technical tier supporting the secure construction, exchange, and delivery of Service Components.

Each Service Area also aggregates and groups the standards, specifications, and technologies into lower-level functional Service Categories as follows:

1. Service Access & Delivery. Refers to the collection standard and specifications to support external access, exchange, and delivery of Service Components or capabilities. This area also includes the Legislative and Regulatory requirements governing the access and usage of the specific Service Component.

2. Service Platform and Infrastructure. The Service Platform and Infrastructure Area define the collection of platforms, hardware, and infrastructure specifications that enable Component-Based Architectures and Service Component re-use.

CMS Technical Reference Architecture 5

Restricted Distribution Sensitive – For Official Use Only

3. Component Framework. The Component Framework Area defines the underlying foundation and technical elements by which Service Components are built, integrated, and deployed across Component-Based and Distributed Architectures. The Component Framework consists of the design of application or system software that incorporates interfaces for interacting with other programs and for future flexibility and expandability. This framework includes, but is not limited to, modules that are designed to interoperate with each other at runtime. Components can be large or small, written by different programmers using different development environments, and may be platform independent. Components can be executed on standalone machines, a Local Area Network (LAN), intranet, or on the Internet.

4. Service Interface and Integration. The Service Interface and Integration Area defines the discovery, interaction, and communication technologies joining disparate systems and information providers. Component-based architectures leverage and incorporate Service Interface and Integration specifications to provide interoperability and scalability.

In order to achieve CMS alignment with FEA guidance, the CMS Enterprise Architecture group has sponsored efforts to ensure the CMS TRA is consistent with those architecture principles, and in particular, with the FEA TRM. One of the goals of this effort is to maintain clear and auditable linkage between federal standards and the Agency’s standards.

CMS has accomplished this alignment by correlating FEA TRM Service Areas and Service Categories to CMS TRA infrastructure and application services throughout this document and in Appendix A, CMS Products / Standards Selection List.

1.8 11BIntended Audience The CMS TRA communicates the shared infrastructure architecture decisions that have received explicit approval from the CMS CIO/CTO. The CMS Technical Review Board (TRB), the Agency Contractors supporting the CMS Production Environments, and other stakeholder entities made these decisions in partnership. The distribution of this document is expressly restricted to Production Environment Contractors; the CMS TRB; The MITRE Corporation, the Agency’s federally funded research and development center (FFRDC) advisor; and any entity that has received explicit access to this document from CMS executive management.

1.9 12BRelevant Documents This document is not all inclusive and complements CMS’ existing standards documentation, including but not limited to the following documents. Where there are conflicts, the CMS TRA and its corresponding Supplements supersede and take precedence over other existing CMS documentation. An exception to this rule is the CMS Information Security (IS) Acceptable Risk Safeguards (ARS) document.

CMS Technical Reference Architecture 6

Restricted Distribution Sensitive – For Official Use Only

• CMS Enterprise Messaging Infrastructure (Including Architecture, Standards and Implementation Requirements), Document No. CMS-CIO-STD-INT02, December 2003 (hereafter simply “CMS Enterprise Messaging Infrastructure”)

• CMS Enterprise File Transfer (EFT) Infrastructure, Version 1.1, Document No. CMS- CIO-STD-ARC02, June 2006 (updated October 2006)

• CMS Information Security Acceptable Risk Safeguards (ARS), Version 4.0, March 19, 2009 (hereafter simply “CMS Information Security Acceptable Risk Safeguards” or

“CMS ARS”).

1.10 13BDocument Organization This document is organized as follows:

Section Overview

Section 2: CMS Infrastructure Architecture Provides an overview of the CMS Production Infrastructure Architecture. This is the fundamental layer in the stack and provides the foundation for both CMS Infrastructure and Application Services.

Section 3: CMS Infrastructure Services Provides an overview of the CMS Production Infrastructure Services. This is the next layer in the stack and provides the foundation for CMS Application Services.

Section 4: CMS Application Services Provides an overview of the CMS Production Application Services. This is the third and final layer in the stack and provides the foundation for CMS workloads and applications.

Appendix A: CMS Products / Standards Selection List

Presents the CMS Product Selection List from the CMS Target Architecture.

Acronyms Defines the acronyms used in this document.

List of References Lists the references used in preparing this document.

CMS Technical Reference Architecture 7

Restricted Distribution Sensitive – For Official Use Only

2. CMS Infrastructure Architecture The architecture for the CMS Production Environment is characterized as a “Multi-Zone” architecture with each zone separated by firewalls to support application systems’ security. The first or outermost zone—the “Presentation Zone” or “De-Militarized Zone (DMZ)”—supports web servers. The second or middle zone—the “Application Zone”—supports business logic for the applications. The third or innermost zone—the “Data Zone” or “Secure/Protected Zone”— contains the database servers used by the applications. Additional network segments support specialized network services such as Public Key Infrastructure (PKI), Domain Name Services (DNS), etc. The following paragraphs describe other zoned regions.

The CMS TRA supports a single, unified interface with internal and external users/ customers, as well as an operational approach to the applications developed and implemented by and/or for CMS. Various applications hosted in the CMS Production Environment will be able to access data, where and when appropriate, in the data warehouse/data marts and a variety of operational databases located within CMS and its contracted sites in the Data Zone.

The databases accessed by applications are on operational database servers or reside in data warehouses or data marts. Thus, the innermost zone, the Data Zone, contains database servers supported within CMS and databases accessed across all of CMS, securely linking CMS’ Fiscal Agents (FA), Fiscal Intermediaries (FI), Medicare Administrative Contractors (MAC), and Carriers. A common, message-oriented interface between the CMS Production Environment application servers and the database servers facilitates access to the databases at various physical sites.

CMS zones are supported by dedicated:

• Redundant border routers

• Redundant active Intrusion Detection and Prevention (IDP) systems

• Redundant physical switches

• Redundant firewalls

• Redundant passive Intrusion Detection Systems (IDS)

• Redundant load balancers.

The redundant load balancers provide Secure Sockets Layer (SSL) and high-availability support.

The dedicated firewalls and IDSs provide a concentration of security services that include, at a minimum, packet and protocol filtering, information hiding, and audit logging consistent with the CMS ARS guidance.

Centers for Medicare & Medicaid Services CMS Infrastructure Architecture

CMS Technical Reference Architecture 8

Restricted Distribution Sensitive – For Official Use Only

2.1 Presentation, Application, and Data Zones

The CMS TRA supports the Presentation, Application, and Data Zones and their specific access requirements and protections to support the needs for customers of each zone. Each CMS Production Environment employs these three zones to separate user and application connectivity for security purposes. The major drivers for the CMS TRA implementation are to:

• Provide a standardized, secure computing environment for new CMS applications

• Provide the necessary control to implement policy and requirements changes so CMS can comply with statutes and regulations on a timely basis, and to ensure the operational flexibility to handle processing reconfigurations, e.g., for workload distributions and balancing

• Enhance interaction with the CMS Production Environments by providing standard interfaces for entities that access CMS applications and data (e.g., beneficiary data, claims history)

• Improve CMS’ capability to be more independent, responsive, and effective in handling Business Operation Contractor transitions (e.g., departures or replacements).

Figure 2 depicts the latest accepted standards of the CMS Multi-Zone Architecture. The CMS Multi-Zone Architecture consists of four main groups of infrastructure components: the Transport Zone, the UNIX Zones, the Windows Zones, and the Management Zone. The permitted operating system (OS) type for the platforms in the CMS Multi-Zone Architecture are UNIX, Linux, Microsoft Windows, and IBM Mainframe z/OS® implementations. The Mainframe Environment also participates in the multi-zone architecture as discussed in subsection 2.1.4.

The Transport Zone is composed of router, IDP, and switch infrastructure for the sole purpose of managing and controlling network traffic. The external sources of network traffic destined for CMS Production Environments are the Internet, CMSnet, Extranet (also known as EXTRAnet), and Core Networks. Inbound and outbound Internet, CMSnet, and Extranet traffic are governed by two discrete stacks of border routers, IDP, and physical switches. Both CMSnet and Extranet border routers are provided by the Internet Service Providers (ISP). The Core Network, comprised of two routers, connects inbound and outbound traffic destined to other CMS Production Environments. Inbound Internet, CMSnet, Extranet, and Core traffic are routable to the other groups of infrastructure components.

The UNIX Zones are comprised of Presentation, Application, and a common Data Zone that separate user, application, and database connectivity to ensure defense-in-depth. The common Data Zone hosts database environments that support both UNIX and Windows Application Zone connectivity. All inbound and outbound traffic to each of these zones route through redundant switches and firewalls and are protected by redundant passive IDS systems. The CMS TRA – Security Services Supplement, Version 1.0 provides guidance for firewall deployments in each of the zones.

CMS Technical Reference Architecture 9

Restricted Distribution Sensitive – For Official Use Only

The UNIX Presentation Zone is the first physical zone (also referred to as a network segment) that separates the user or end application from the Application and Data Zones. This Zone is supported by redundant SSL-based load balancers and external Domain Name Service (DNS) servers on a dedicated Internet Protocol Security (IPSec)-based Virtual Local Area Network (VLAN). The UNIX Application Zone is the second physical segment. The UNIX Application Zone resides behind the UNIX Presentation Zone, controls the operation of application-specific business functionality, and is supported by redundant load balancers. The common Data Zone is the third physical segment, and resides behind the UNIX and Windows Application Zones. The common Data Zone contains all data access logic and data sources, including data warehouses and data marts as well as operational databases for applications. All information to be stored in the common Data Zone comes through the Application Zone with the exception of file transfers for Fee-for-Service (FFS) applications, which connect directly into the Data Zone for trusted CMS partners.

The Windows Zones are comprised of Windows Presentation, Application, and a common Data Zone. These Zones separate user, application, and database connectivity to ensure defense-in-depth. The Windows Presentation Zone is located in the first physical segment and provides proxy services for web traffic and is protected by redundant IDS systems. The Windows Application Zone is located in the second physical segment and has functional characteristics similar to the UNIX Application Zone. The common Data Zone occupies the third physical segment and is shared between Windows and UNIX environments. All inbound and outbound traffic to each of these Zones route through redundant switches and firewalls to provide filtering between the Zones and are protected by redundant, passive IDSs.

The Management Zone provides security, monitoring, and management in support of all other Zones via redundant firewalls and physical switches. All network traffic destined for this Zone is routed by redundant border routers, physical switches, firewalls, and active IDP systems. The only routing exception is that approved support users may connect directly from vendor-managed networks. The Management Zone is separated into seven (7) functional areas by IPSec-based VLANs: Management DMZ, Shared Tools, Firewall Management Tools, Security Tools, Backup Tools, UNIX Tools, and Windows Tools. Production Environment Contractor sessions into the Management DMZ are routed through IPSec-based VLANs via redundant Virtual Private Network (VPN) Concentrators. The Shared Tools segment houses redundant internal DNS servers that service all applications in the Transport, UNIX, Windows, and Management Zones.

The following subsections provide greater detail for the Presentation, Application, and Data Zones.

CMS Technical Reference Architecture 10

Figure 2. CMS Multi-Zone Architecture

CMS Technical Reference Architecture 11

Restricted Distribution Sensitive – For Official Use Only

2.1.1 33BPresentation Zone The Presentation Zone is the first zone that controls how users and applications interface with CMS Production Environments. The Presentation Zone separates the user or end application from the Application and Data Zones. This separation provides the first layer of security for the CMS Production Environments. All Graphical User Interfaces (GUI) are located in the Presentation Zone.

The Presentation Zone serves both public and private websites. The Presentation Zone servers can serve requests for static content or can proxy requests for static content to the Application Zone. The Presentation Zone server’s executes proxy requests for dynamic content to the Application Zone. The Presentation Zone servers contain presentation logic (HTML) for websites containing static content. No application/business/database logic/processing are executed on servers in the Presentation Zone. Furthermore, all support applications, business logic, databases, tables, and sensitive information for the CMS Internet and CMSnet (also known as Private Network) applications reside on dedicated servers in the Application Zone and the Data Zones. Tables 2 and 3 (see pages 20 and 24, respectively) provide a list of infrastructure and application services that reside in the Presentation Zone.

The Presentation Zone is supported by redundant load balancers to ensure high availability.

Redundant, external DNS servers reside in the Presentation Zone on a dedicated IPSec-based VLAN (enclave) to provide name resolution for external-facing applications.

All inbound and outbound traffic to the Presentation Zone routes through a redundant pair of switches and firewalls to provide filtering between Zones and is protected by redundant, dedicated passive firewalls and passive IDSs. The dedicated Firewalls and IDSs provide a concentration of security services that include, at a minimum, packet and protocol filtering, information hiding, and audit logging consistent with the CMS ARS and CMS TRA – Security Services Supplement.

2.1.2 34BApplication Zone The Application Zone resides behind the Presentation Zone and contains application servers.

This separation ensures that connectivity from the Internet, CMSnet, intranets, EDCs, and all other CMS Production Environments must traverse the Presentation Zone before connecting to the Application Zone. The Application Zone serves requests for dynamic and/or static web content. The Application Zone controls the operation of application-specific business functionality. These application-specific business functions include data validation, execution of business rules, calculations, manipulation of data, and control of the environment. When an Application Zone application requires information or actions from the Data Zone, the application makes the request, and processes the response, using a redundant messaging facility. Business results from the Application Zone are then returned to the Presentation Zone and formatted by the Presentation Zone for delivery to the end user or application for viewing or further processing. Tables 2 and 3 (see pages 20 and 24, respectively) provide a list of infrastructure and application services that reside in the Application Zone.

CMS Technical Reference Architecture 12

Restricted Distribution Sensitive – For Official Use Only

All inbound and outbound traffic to the Application Zone is routed by a redundant pair of switches and firewalls to provide filtering between Zones and is protected by redundant, dedicated firewalls and passive IDSs. In addition, all load-balanced traffic is managed by redundant load balancers to ensure high availability. The dedicated Firewalls and IDSs provide a concentration of security services that include, at a minimum, packet and protocol filtering, information hiding, and audit logging consistent with the CMS ARS and CMS TRA Security Services Supplement.

2.1.3 35BData Zone The common Data Zone resides behind the Application Zone and contains all data access logic and data sources, including data warehouses and data marts as well as operational databases for applications. All information to be stored in the Data Zone comes through the Application Zone.

The Data Zone interfaces with the Application Zone via a redundant messaging and is separated from the Presentation Zone for security purposes. CMS approves direct connection to a database from the Application Zone to the Data Zone when a Session Database is needed for a web application. The Session Database is necessary to provide state services that web applications need to function in a farmed environment. Tables 2 and 3 (see pages 20 and 24, respectively) provide a list of infrastructure and application services that reside in the Data Zone.

File transfers for FFS applications are the only exception to these data transfer restrictions. In support of FFS, file transfers are enabled via Connect:Direct directly into the Data Zone for trusted CMS partners (i.e., MACs and CMS Regional Offices).

All inbound and outbound traffic to the common Data Zone is routed by a redundant pair of switches and firewalls to provide filtering between Zones and protected by redundant, dedicated firewalls and passive IDSs. The dedicated Firewalls and IDSs provide a concentration of security services that include, at a minimum, packet and protocol filtering, information hiding, and audit logging consistent with the CMS ARS and CMS TRA – Security Services Supplement.

2.2 Windows Zones

The Windows Zones consist of three physical network segments, distinct from the UNIX Multi- Zone Architecture described in subsection 2.1. The Windows Presentation Zone is located in the first physical segment and provides proxy services for web traffic. The Windows Application Zone is located in the second physical segment and has functional characteristics similar to the UNIX Application Zone in the UNIX Multi-Zone architecture. The common Data Zone is in the third physical segment and shares functionality with the UNIX Multi-Zone architecture. All inbound and outbound traffic to the Windows Presentation Zone is routed by a redundant pair of switches and firewalls to provide filtering between Zones and is protected by redundant, dedicated firewalls and passive IDSs. All inbound and outbound traffic to the Windows Application Zone is routed by a redundant pair of switches and protected by redundant, dedicated firewalls and passive IDSs. All inbound and outbound traffic to the Data Zone is routed by a redundant pair of switches and protected by redundant, dedicated firewalls and passive IDSs. The dedicated firewalls and IDSs in these Zones provide a concentration of

CMS Technical Reference Architecture 13

Restricted Distribution Sensitive – For Official Use Only security services that include, at a minimum, packet and protocol filtering, information hiding, and audit logging consistent with the CMS ARS and CMS TRA – Security Services Supplement.

2.3 Management Zone

In addition to the Presentation, Application, and Data Zones, the CMS Multi-Zone Architecture provides security, monitoring, and management in the Management Zone. All Internet, CMSnet, EDC intranet, or CMS Production Environment network traffic destined for the Management Zone is routed by a redundant pair of border routers and physical switches. This is the same network infrastructure that provides access to the Multi-Zone Architecture. The only exception is that approved users have the option to connect to the CMS Production Environments for maintenance and management support directly from vendor-managed networks, or other outside networks, via Management Zone components. Vendors can install redundant firewalls in the Management Zone to establish private IPSec-based VLANs to meet their specific needs.

All traffic into the Management Zone is protected by redundant firewalls and active IDP systems. These firewalls and network-based IDP systems provide a concentration of security services that include, at a minimum, packet and protocol filtering, information hiding, and audit logging. All of the network traffic is monitored via redundant IDP systems and each system is configured as required by the CMS ARS and CMS TRA – Security Services Supplement. In addition, all access to the Management Zone must be secured via two-factor authentication.

The Management Zone is separated into functional areas by IPSec-based VLANs as follows:

• Management DMZ

• Shared Tools

• Firewall Management Tools

• Security Tools

• Backup Tools

• UNIX Tools

• Windows Tools.

Each segment is separated from the others to ensure that no connectivity between the VLANs and/or physical switches is allowed in this Zone. In addition, connectivity from each of the Management Zone functional segments to the UNIX and Windows Presentation, Application, and Data Zones is protected by redundant firewalls and physical switches.

2.3.1 36BManagement DMZ Segment The Management DMZ is similar to the Presentation Zone in the UNIX Multi-Zone Architecture. The Management DMZ is the first of the IPSec-based VLANs that provides an interface to the other IPSec-based VLANs in the Management Zone. The subsequent IPSec-based VLANs contain the security and management tools for use by the Production Environment Contractors.

CMS Technical Reference Architecture 14

Restricted Distribution Sensitive – For Official Use Only

All inbound and outbound traffic to the Management DMZ is routed by a redundant pair of switches and protected by a dedicated, redundant pair of border firewalls and active IDP systems.

Connectivity from the Management DMZ to the rest of the Management Zone segments is further protected by another dedicated, redundant pair of firewalls. The dedicated border firewall and IDP systems provide a concentration of security services including, at a minimum, packet and protocol filtering, information hiding, and audit logging consistent with the CMS ARS and CMS TRA – Security Services Supplement. In addition, all access from the Management DMZ to the other Management Segments must be secured via two-factor authentication.

Production Environment Contractor sessions into the Management DMZ are routed to the appropriate IPSec-based VLANs via redundant VPN Concentrators to manage IPSec VPN connections.

2.3.2 37BShared Tools Segment The Production Environment Contractor installs and manages the tools that reside in this segment. All tools in this segment manage the Shared Services that have been contracted to the Production Environment Contractor. The Production Environment Contractor is responsible for maintaining all tools in accordance with CMS Change Management and Configuration Management processes and tracking all updates to these systems for consistency across the Production Environments.

The Shared Tools segment also houses redundant, internal DNS servers that provide name resolution for all applications in the UNIX Multi-Zone Architecture, Windows Zones, and Management Zone.

2.3.3 38BFirewall Management Tools Segment The Production Environment Contractor installs and manages the tools that reside in this segment. All tools in this segment manage the Firewall Management services that have been contracted to the Production Environment Contractor. The Production Environment Contractor is responsible for maintaining all tools in accordance with CMS Change Management and Configuration Management processes and tracking all updates to these systems for consistency across the Production Environments.

2.3.4 39BSecurity Tools Segment The Production Environment Contractor installs and manages the tools that reside in this segment. All tools in this segment manage the Security Services that have been contracted to the Production Environment Contractor. The Security Services located in this segment include, but are not limited to, Intrusion Detection and Prevention tools, security alert tools, and Syslog tools.

The Production Environment Contractor is responsible for maintaining all tools in accordance with CMS Change Management and Configuration Management processes and tracking all updates to these systems for consistency across the Production Environments.

CMS Technical Reference Architecture 15

Restricted Distribution Sensitive – For Official Use Only

2.3.5 40BBackup Tools Segment The Production Environment Contractor installs and manages the tools that reside in this segment. All tools in this segment manage the Backup/Restore Services that have been contracted to the Production Environment Contractor. The Production Environment Contractor is responsible for maintaining all tools in accordance with CMS Change Management and Configuration Management processes and tracking all updates to these systems for consistency across the Production Environments.

2.3.6 41BUNIX Tools Segment The Production Environment Contractor installs and manages the tools that reside in this segment. All tools in this segment manage the UNIX administration services that have been contracted to the Production Environment Contractor. The Production Environment Contractor is responsible for maintaining all tools in accordance with CMS Change Management and Configuration Management processes and tracking all updates to these systems for consistency across the CMS Production Environments.

2.3.7 42BWindows Tools Segment The Production Environment Contractor installs and manages the tools that reside in this segment. All tools in this segment manage the Windows Services that have been contracted to the Production Environment Contractor. The Production Environment Contractor is responsible for maintaining all tools in accordance with CMS Change Management and Configuration Management processes and tracking all updates to these systems for consistency across the CMS Production Environments.

2.4 Wide Area Network

This section provides a brief overview of the CMS Wide Area Network (WAN). For details, please see the CMS TRA – Wide Area Network Services Supplement for the approved WAN standards for the CMS Production Environments.

2.4.1 43BCMS WAN Architecture The CMS WAN, as depicted in the high-level view in Figure 1, consists of the CMS Core Network, CMS Private Network (CMSnet), and the CMS Extranet. Together, these WAN elements serve the EDCs, CMS business partners, CMS employees, and beneficiary communications needs of the Agency.

CMS Technical Reference Architecture 16

Restricted Distribution Sensitive – For Official Use Only

Private MPLS

OC3 CORE

CMS

BDC

EDS

EDC

CDS

EDC

CMSnet Encrypted MPLS Network

Extranet Encrypted MPLS Network

HIGLAS

MAC

Regional Office

Regional Office

Regional Office

Figure 3. High-Level View of the CMS Wide Area Network

The CMS WAN consists of the following components:

• CMS Core Network: A dedicated point-to-point network that connects the EDCs

• CMSnet: A secure network that provides access to the CMS applications for CMSNet

Business Partners (CBP)

• CMS Extranet: A secure network that provides access to CMS applications for Extranet

Business Partners (EBP).

CMS’ stakeholders can be categorized into five communities of interest: EDCs, CMS Offices, CBPs that include other government agencies, EBPs, and beneficiaries. Each of these stakeholders has varying access requirements to the CMS applications residing at the EDCs, for inbound and outbound access to the Internet, and for communications among the CMS business partners.

CMS Technical Reference Architecture 17

Restricted Distribution Sensitive – For Official Use Only

2.4.1.1 51BCMS EDCs The CMS EDCs host the CMS applications and provide services to CMS stakeholders. For security and performance purposes, the business applications at the EDCs are hosted in three zones—Presentation, Application, and Data. The EDCs use the dedicated CMS Core Network that connects them for communicating between the zones during client transactions and data backup. The combination of the three zones, defense-in-depth, and the Core Network dedicated solely for CMS’ use provides security to the traffic even if it is unencrypted.

The EDCs also host the CMSnet, Extranet, and Internet gateways that serve as secure entry and exit points for all of the transactions and communications between the stakeholders. In providing this service, the EDCs leverage the CMS Core Network heavily to bridge and transport traffic between networks and facilitate seamless transaction processes.

2.4.1.2 52BCMS Employees CMS employees at the BDC and the CMS Regional Offices access the Internet over the

CMS WAN.

2.4.1.3 53BCMSnet Business Partners CMS CBPs are the major users of the CMSnet. The CBPs use the CMSnet to access CMS business applications and to communicate with other business partners. All CMSnet sites will have direct access to all EDCs through the CMSNet WAN.

2.4.1.4 54BExtranet Business Partners EBPs access the CMS business applications that reside in the CMS Core Network through the Extranet gateways hosted at two (2) EDCs. The Extranet Service Provider is responsible for providing a secure site-to-site connection from the EBP location to the Extranet gateway at an

EDC.

2.4.1.5 55BCMS Beneficiaries CMS beneficiaries use the Internet to access CMS business applications at the EDCs via the Internet gateway.

2.5 Global CMS Standards

2.5.1 44BData Center Naming Convention Table 1 describes the Data Center naming convention that ensures standard and effective communication between CMS, Production Environment Contractors, and all other parties.

Consensus agreement on this global data center naming convention was achieved at the February 2007 EDC Summit.

CMS Technical Reference Architecture 18

Restricted Distribution Sensitive – For Official Use Only

Table 1. Data Center Naming Conventions

Data Center Name Production Environment Contractor

EDC1 Electronic Data Systems (EDS) Corporation EDC2 Companion Data Services (CDS), LLC EDC3 International Business Machines (IBM) Corporation EDC4 Lockheed Martin Corporation (CMS Baltimore Data Center)

2.5.2 45BPhysical Separation of Switches Virtual Local Area Networks are used at each level in the standard CMS Multi-Zone Architecture. The Presentation, Application, and Data Zones must be physically separated via their own redundant switches. This level of physical separation ensures the integrity of CMS’ Multi-Zone Architecture while employing VLAN technology. Within each of the Presentation, Application, and Data Zones, VLANs can be employed to enable horizontal scalability. VLANs shall not be used outside this guidance without explicit written approval from the CMS CTO.

2.5.3 46BInfrastructure—Dedicated Versus Shared Components A key aspect of the CMS Production Environment is the combination of dedicated components and shared components and dedicated and shared capabilities. CMS defines dedicated components as those that are provided exclusively for CMS Production Environment infrastructure use.0 F

1 All other components that may be shared with other data center customers are considered shared components. The Shared System infrastructure includes, but is not limited to, Firewalls, Network-based IDS/IDP, Host-based IDS, Identity Management, Monitoring, File Transfer, WAN Connectivity (routers and switches), Backup, DNS, and Storage Area Network (SAN) Storage services.

The Government reserves the right to gain login access for administrative or repair purposes on any dedicated component in the Production Environment through a Firecall process. The Government will define the Firecall process and provide it to the Production Environment Contractors following contract award.

CMS defines dedicated capability within the CMS Production Environment as those components that are part of a mainframe processing infrastructure dedicated to CMS rather than shared with other data center customers. CMS has determined that it is not acceptable to have Logical Partitions (LPAR) on the same mainframe machine used by other data center customers. The entire mainframe computing resource must be dedicated to CMS.

1 For example, all routers and switches internal to the CMS local area network (LAN) infrastructure must be dedicated to CMS, but the border router (or gateway router) providing connection to an ISP can be shared with other data center customers.

CMS Technical Reference Architecture 19

Restricted Distribution Sensitive – For Official Use Only

2.5.4 47BMid-Tier Server Ports Each mid-tier server in the CMS Production Environments is provisioned with a minimum two

(2) physical Network Interface Cards (NIC). Five (5) interface ports are configured on the NIC cards and dedicated for connectivity to the Production, Backup, and Security and Management Networks. Two (2) interface ports are dedicated to Production Network connectivity and are not configured on the same NIC card. The only exception to this NIC configuration is that servers in the Management Zone do not require a dedicated port for Production connectivity. A sixth interface port can be configured on either NIC card for the purpose of “console” or “lights out” management by the Production Environment Contractors; however, the sixth interface port may not be necessary for those servers with dedicated DRAC/ALOM (Dell Remote Access Card/Advanced Lights Out Manager) interface cards.

2.6 Infrastructure Security Considerations

Any server operating systems, routers, switches, databases and other infrastructure components must be configured in accordance with the applicable National Security Agency (NSA) guidelines on vulnerabilities and guidelines provided by the CMS ARS and NIST Special Publications, including but not limited to NIST SP 800-7 and 800-26, as applicable.

All web servers or proprietary applications must be configured in accordance with NSA guidelines on secure website configurations. All web servers or proprietary applications must implement SSL 3.0 or Transport Layer Security (TLS) 1.0 with the approved cryptographic modules that ensure CMS is in compliance with, at a minimum, NIST SP 800-52 and Federal Information Processing Standards (FIPS) 140-2.

The CMS ARS and CMS TRA – Security Services Supplement provides current and comprehensive security guidance.

CMS Technical Reference Architecture 20

Restricted Distribution Sensitive – For Official Use Only

3. CMS Infrastructure Services Infrastructure Services are those core services that are used by applications in the CMS…