RMH Chapter 16: System & Communications Protection

Introduction

The Risk Management Handbook Chapter 16: System and Communications Protection (SC) focuses on how the organization must: monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems; and employ architectural designs, software development techniques, and systems engineering principles that promote effective information security and privacy assurance within organizational information systems. Some of the controls discussed within this chapter include Application Partitioning, Security Function Isolation, Information Shared Resources, Denial of Service Protection, Boundary Protection, Transmission Confidentiality and Integrity, Cryptographic Protection, and Public Key Infrastructure Certificates. There are also procedures surrounding Mobile Code, Voice Over Internet Protocol (VOIP), Session Authenticity, Email and Website Usage.

System and Communications Protection (SC) Controls

Application Partitioning (SC-2)

The purpose of this control is to ensure separation of the user functionality from the information system management functionality by the information system either physically or logically. Enforcing the separation of information flows by type can enhance protection by ensuring that information is protected while in transit. Types of separable information include, for example, inbound and outbound communications traffic and service requests.

The CMS Technical Reference Architecture (TRA) provides the authoritative technical architecture approach and technical reference standards of CMS. Compliance with the TRA helps ensure that CMS information technology (IT) systems and infrastructure will support secure and high-quality delivery of healthcare services to beneficiaries, providers, and business partners, plus align CMS systems with the Federal Enterprise Architecture Framework (FEAF).

The CMS Target Life Cycle (TLC) replaces the CMS legacy Expedited Life Cycle (XLC) with a more business focused and flexible System Development Life Cycle (SDLC) process. The TLC replaces XLC point-in-time gate reviews with required artifacts, with “as needed” consultations via the Business Owner with the Office of Information Technology (OIT) Navigator, the EA team, Subject Matter Experts (SMEs), and/or Governance Review Teams (GRT). This flexible approach will provide for a more continuous evaluation, and situational reviews governance as needed to

better meet CMS program needs. The four phases of the TLC include: Intake, Develop, Operate and Retire. During the Develop Phase, detailed user stories or requirements are created, the solution is designed, built, deployed to a non-production environment, and tested for compliance with the requirements and CMS standards so that it is production ready. Requirements, user stories, design, development and testing must all be done in compliance with the CMS TRA and security, privacy and accessibility standards.

Guidance for systems processing, storing, or transmitting PII (to include PHI):

It is necessary to store sensitive information, such as PII, on separate logical partitions from applications and software that provide user functionality to restrict accidental or unintentional loss of, or access to, sensitive information by both unauthorized users and unauthorized applications.

CMS applications must be configured to prevent the operation of all system administrative functions except those that originate from the Management and Security Bands. 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 System Security and Privacy Plan (SSPP) and Information Security Risk Analysis (ISRA). CMS uses, for example, different computers, different central processing units, different network addresses or combinations of these to implement separation of system management-related functionality from user functionality.

Security Function Isolation (SC-3)

Security functions and non-security functions are separated by the information systems through an isolation boundary. Security functions, for example, include establishing system accounts and configuring access authorizations. At CMS, an isolation boundary provides access control and protects the reliability of the hardware, software, and firmware that perform security functions. Operating systems implement code separation (i.e., separation of security functions from nonsecurity functions) in a number of different ways.

At CMS, developers and implementers increase the assurance in security functions by employing well-defined security policy models; structured, disciplined, and rigorous hardware and software development techniques; and sound system/security engineering principles. Implementation may include isolation of memory space and libraries.

Each System Developer and Maintainer (SDM) is also responsible for maintaining appropriate security for all secure boundaries and for implementing the appropriate tools and technologies to meet CMS and federal requirements.

 Information in Shared Resources (SC-4)

Preventing unauthorized information transfers mitigates the risk of information from being available to any current users/roles (or current processes) that are granted access to shared system resources after those resources have been released back to information systems.

Guidance for systems processing, storing, or transmitting PII (to include PHI):

Following use of a shared system resource, ensure that shared system resource(s) is purged of personally identifiable information (PII) to prevent unintended users or processes from accessing PII.

CMS, in accordance with OMB Circular NO. A-130, implements information security programs and privacy programs with the flexibility to meet current and future information management needs and the sufficiency to comply with Federal requirements and manage risks.

Denial of Service Protection (SC-5)

The purpose of this control is to ensure the information system protects against or limits the effects of the types of denial of service attacks defined in federal guidelines.

Denial of Service (DoS) attacks are generally defined as any attack that can destabilize the network or systems’ ability to perform expected functions. In the case of a Distributed Denial of Service (DDoS) attack, the attacker uses multiple compromised or controlled sources to generate an attack. Protection against DoS attacks involves the use of a combination of attack detection, traffic classification and response tools, aiming to block traffic that they identify as illegitimate and allow traffic that they identify as legitimate.

The table below outlines the CMS organizationally defined parameters (ODPs) SC-5.

Table 1: CMS Defined Parameters – Control SC-5

CMS adheres to security safeguards listed in SANS Institute to reduce chances of DoS attacks, which include:

• Egress filtering to stop spoofed IP packets from leaving network.
  • Deny invalid source IP addresses
  • Deny private & reserved source IP addresses (not necessary if invalid source IP address is denied)
• Stopping network from being used as a broadcast amplification site.
  • Disable IP directed broadcast on all systems
  • Test your network to determine if it is an amplification site
  • Require that vendors disable IP directed broadcast by default

CMS also adheres to the Consensus Roadmap for Defeating Distributed Denial of Service Attacks outlined by the SANS institute, as amended.

CMS complies with NIST Special Publication 800-61 rev2 on Computer Security Incident Handling Guide, which provides guidelines for incident handling of DoS/DDoS attacks, particularly for analyzing incident-related data and determining the appropriate response to each incident.

Boundary Protection (SC-7)

This control ensures the monitoring and control of communications within the “external boundary” of the overall information systems landscape for purposes of preventing and detecting malicious, unauthorized communication via the use of numerous tools. More specifically, boundary protection differentiates boundaries between external, untrusted networks from those deemed trusted and secure. Boundary protection is yet another information security principle that aids in ensuring the confidentiality, integrity, and availability (CIA) of an organization’s critical system resources.

At CMS, communications and processing connections are controlled via an integrated system of firewalls, routers, and through the use of Intrusion Detection Systems (IDS) equipment. Traffic flow is controlled through managed routers and switches. The configuration of the firewall systems 

follows vendor recommendations. CMS utilizes firewall perimeter routers and IDS, configured to provide a defense-in-depth.

Access Points (SC-7(3))

The purpose of this control enhancement is to protect the information system by restricting access from external network connections. The number of access points to the information system must be restricted to allow for more wider-range of the monitoring of inbound and outbound communications and network traffic.

CMS access points consist of boundary protection devices arranged in accordance with it’s effective security architecture. Connections are consistent with the organizations enterprise technology and security architecture.

CMS complies with the Office of Management and Budget (OMB) Memorandum, Implementation of Trusted Internet Connections, M-08-056, November 20, 2007, which 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.

External Telecommunications Services (SC-7(4))

This purpose of this control enhancement is to ensure the organization implements a managed interface7 for each external telecommunication service, establishes a traffic flow policy for each managed interface and protects the confidentiality and integrity of the information being transmitted across each interface.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-7(4).

Table 1: CMS Defined Parameters – Control SC-7(4)

Firewalls provide protection to the mainframe and the rest of the infrastructure at CMS.

CMS has deployed firewalls at all internet access points and between shared support infrastructure and customer networks. Firewall and/or routing requests are necessary to facilitate new firewall rules and/or connectivity for user-to-system or system-to-system across the CMS Wide Area Network (WAN).

For information on CMS Firewall and Routing Request Form, contact the CMS IT Service Desk by calling (410) 786-2580 or (800) 562-1963; or by sending an email to cms_it_service_desk@cms.hhs.gov to open a ticket.

Deny by Default/Allow by Exception (SC-7(5))

The purpose of this control enhancement is to ensure only connections which are integral and vetted are allowed through inbound and outbound network communications traffic. The information system of organizations enlists a firewall configuration policy that forces the user to be registered at the site, authenticate their registration and authorize their registration prior to gaining access.

As CMS brings a lot of applications onto the Internet, it is imperative to ensure the security of the applications, and the integrity of the information transferred to and from them. For Machine-to- machine connections, not only must the system be physically secure, but incoming and outgoing data must be protected to prevent compromise of CMS information integrity. In order to establish that connection, each machine must ensure that it is connecting to a trusted machine on the other end. Failing to identify and prohibit unauthorized traffic leaves the enclave vulnerable to attack. The initial defense for the internal network is for protection measures to block any traffic at the perimeter that is attempting to make a connection (or otherwise establish a traffic flow) to a host in the internal network. Outbound traffic is allowed by default, and inbound traffic is blocked by default, which is accomplished by the CMS’s firewalls and load balancers. The firewalls deny all and permit by exception using CMS specific infrastructural rules

Prevent Split Tunneling for Remote Devices (SC-7(7))

The purpose of this control is to ensure the information system, in conjunction with a remote device, prevents a device from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks.

CMS enforces the use of VPNs, sufficiently provisioned with applicable security controls, to provide a means for allowing non-remote communications paths from remote devices.

In order to securely connect to the CMS Network remotely, a user must have:

• A CMS issued laptop (for example). This will contain the VPN software you need to access the VPN.
• An Authentication Device. This can be either your PIV Card (Personal Identity Verification), PIV PIN (Personal Identity Number), or RSA Token “fob.”. If you have been issued a PIV card, this should be the method of connecting to the VPN. The RSA Token should only be used if your PIV card has not been issued yet.
• High speed Internet access from a remote location (dial-up is not supported).

Additional information on connecting to the CMS Network using VPN can be found in Getting Started with Remote Access to the CMS Network.

​​​​​​​Route Traffic to Authenticated Proxy Servers (SC-7(8))

The purpose of this control enhancement is to ensure the information system routes all user- initiated internal communications traffic to untrusted external networks through authenticated proxy servers at managed interfaces. A proxy server is a server application or appliance that acts as an intermediary for requests from clients seeking resources from servers that provide those resources. A proxy server thus functions on behalf of the client when requesting service, potentially masking the true origin of the request to the resource server.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-7(8).

Table 3: CMS Defined Parameters – Control SC-7(8)

At CMS, the proxy server acts as a single point of contact serving client requests. The proxy server authenticates each request based on Client Exchange/Device ID and other parameters and forwards the request to the desired destination server. URL filter servers, a form of proxy server, can block access to unsafe websites. They also 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 System Developer and Maintainer (SDM) must collect and forward proxy/URL logs according to the organizational requirements.

​​​​​​​Fail Secure (SC-7(18))

The purpose of this control enhancement is to ensure that in the event of operational failures of boundary protection devices at managed interfaces, the information system fails securely.

CMS utilizes Network Firewalls to prevent loss of boundary protection and to meet the requirement for this control enhancement. Network firewalls guard the internal computer network against malicious access from the outside, such as malware-infested websites or vulnerable, open network ports.

Firewalls are implemented in redundant pairs to prevent loss of boundary protection.

Each Network Firewall in the CMS Processing Environments must be provisioned with separate interfaces dedicated to each network segment and band with which it connects. CMS Network Firewalls provide various functions and restrict the ability to perform certain functions to an authorized administrator.

​​​​​​​Isolation of Information System Components (SC-7(21))

Separating system components with boundary protection devices provides the capability for increased protection of individual components and to more effectively control information flows between those components. Isolation limits unauthorized information flows among system components and provides the opportunity to deploy greater levels of protection for selected components.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-7(21).

Table 4: CMS Defined Parameters – Control SC-7(21)

CMS employs firewalls and a Network-based Intrusion Detection System (NIDS) to meet the requirements for this control enhancement. A network-based intrusion detection system (NIDS) is used to monitor and analyze network traffic to protect a system from network-based threats. A 

NIDS reads all inbound packets and searches for any suspicious patterns. When threats are discovered, based on its severity, the system takes action such as notifying administrators, or barring the source IP address from accessing the network.

​​​​​​​Transmission Confidentiality and Integrity (SC-8)

The purpose of this control is to ensure the information system protects the confidentiality and integrity of data in transit.

In accordance with the HHS Standard for Encryption of Computing Devices and Information, CMS policy states that all sensitive information at rest (and in transit) must be encrypted using a Federal Information Processing Standard (FIPS) 140-2 validated solution to safeguard the confidentiality and integrity of information. CMS Data Encryption Standards mandates that it is the responsibility of all CMS personnel and business partners to protect CMS sensitive information while data is in transit (and at rest). When encryption is not technically feasible, CMS business owners must implement a specific set of compensating controls.  CMS enterprise data encryption standards can be reviewed by visiting the CMS CEDE page. 

Guidance for systems processing, storing, or transmitting PII (to include PHI):

Because of the sensitivity of personally identifiable information (PII) and protected health information (PHI), the confidentiality and integrity of such information in transit must be assured.

Sending an encrypted email using Office 365

Communication between CMS.Net and email-as-a-service (also known as Office 365) has automated encryption. CMS utilizes Office 365 Message Encryption (OME) within Microsoft Outlook to send sensitive and protected data securely to recipients outside of CMS. All Government-Furnished Equipment (GFE) has this feature.

CMS adheres to the mandatory Email Services procedures outlined in HHS Policy for Internet and Email Security, as amended, which establishes minimum requirements for securing the internet and email services throughout CMS in order to enhance integrity and confidentiality of internet-delivered data, minimize spam, unauthorized access, and misuse of information, and better protect users who might otherwise fall victim to attacks that appear to come from government-owned systems.

Sending an encrypted email using your PIV

CMS recommends the use of Personal Identity Verification (PIV) Card encryption to send documentations across the network. Email and any attachment that contains sensitive information when transmitted inside and outside of CMS premises shall be encrypted using the user’s PIV card when possible. If PIV encryption is not feasible, a FIPS 140-2 validated solution must be employed:

• Password protection of files is recommended to add an additional layer of data protection but shall not be used in lieu of encryption solutions.
• Password and/or encryption key shall not be included in the same email that contains sensitive information or in separate email.
• Password/encryption key shall be provided to the recipient separately via text message, verbally, or other out-of-band solution.

Sending an encrypted email to a third party through SecureZIP

All e-mails with CMS sensitive information must be encrypted through the use of CMS approved encryption software when outside of a controlled environment. The CMS approved software is SecureZIP (PK Zip). SecureZIP is an application for zipping files to save storage space as well as encrypting files with password control to protect information.

For the procedure on how to encrypt using SecureZIP, go to SecureZIP Instructions.

CMS also has specific encryption requirements for large file transfers. Additional information on large file transfers can be requested through the Infrastructure and User Services Group.

​​​​​​​Cryptographic or Alternate Physical Protection (SC-8(1))

The purpose of this control enhancement is to ensure the information system implements cryptographic mechanisms to prevent unauthorized disclosure of information and detect changes to information when data is in transit.

Cryptography is a branch of applied mathematics concerned with transformations of data for security. In cryptography, a sender transforms unprotected information (plaintext) into coded text (ciphertext). A receiver uses cryptography to either:

• transform the ciphertext back into plaintext
• verify the sender’s identity
• verify the data’s integrity, or some combination.

Guidance for systems processing, storing, or transmitting PII (to include PHI):

Because of the sensitivity of PII, the confidentiality and integrity of such information in transit must be assured with encryption techniques if assurance is not provided by other means.

Guidance for systems processing, storing, or transmitting PHI:

Under the HIPAA Security Rule, this is an addressable implementation specification. HIPAA covered entities must conduct an analysis as described at 45 C.F.R. § 164.306 (Security standards: General rules) part (d) (Implementation specifications) to determine how it must be applied within the organization. However, using cryptographic protection allows the organization to utilize the “Safe Harbor” provision under the Breach Notification Rule. If PHI is encrypted pursuant to the Guidance Specifying the Technologies and Methodologies that Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals (45 C.F.R. Part 164 Subpart D), then no breach notification is required following an impermissible use or disclosure of the information. Therefore, organizations should use cryptographic protections for PHI stored on electronic media.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-8(1).

Table 5: CMS Defined Parameters – Control SC-8(1)

At CMS, when cryptographic mechanisms are needed, the information system uses encryption products that have been validated under the Cryptographic Module Validation Program to confirm compliance with FIPS 140-2 in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

​​​​​​​Network Disconnect (SC-10)

The purpose of this control is to ensure the termination of both internal and external networks associated with a communications session at the end of the session. A session is an encounter between an end-user interface device (e.g., computer, terminal, process) and an application, including a network logon. A connection-based session is one that requires a connection to be established between hosts prior to an exchange of data.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-10.

Table 6: CMS Defined Parameters – Control SC-10

CMS information systems identify and terminate all inactive remote sessions (both user and information system sessions) automatically.

CMS applies the following Standard(s) in addition to the parameters listed in the table above:

• Configure systems to disable local access (i.e., lock the session) automatically after fifteen (15) minutes of inactivity. Require a password to restore local access.
• Configure the information system to automatically terminate all remote sessions (user and information system) after time stated in systems SSPP.
• Concurrent User ID network log-on sessions is 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 SSPP if it is more than one (1) concurrent session.

Cryptographic Key Establishment and Management (SC-12)

The purpose of this control is to ensure the organization establishes and manages cryptographic keys for required cryptography in accordance with applicable federal laws, executive orders, directives, regulations, policies, standards, and organizational guidance, when cryptography is required.

In cryptography, a key is a string of characters used within an encryption algorithm for altering data so that it appears random. Like a physical key, it locks (encrypts) data so that only someone with the right key can unlock (decrypt) it. The original data is known as the plaintext, and the data after the key encrypts it is known as the ciphertext. The formula:plaintext + key = ciphertext. Cryptographic techniques use cryptographic keys that are managed and protected throughout their lifecycles by a Cryptographic Key Management System (CKMS).

Guidance for systems processing, storing, or transmitting PII (to include PHI):

Because cryptography is desired to protect sensitive information such as personally identifiable information (PII) and protected health information (PHI), cryptographic key establishment and management must be performed in such a way that even the loss of keys will not permit access to the sensitive information.

See section 3.6.1 Cryptographic or Alternate Physical Protection SC-8(1) for Guidance for systems and processing, storing, or transmitting PHI.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-12.

Table 7: CMS Defined Parameters – Control SC-12

At CMS, when cryptographic mechanisms are needed, the information system uses encryption products that have been validated under the Cryptographic Module Validation Program to confirm compliance with FIPS 140-2 in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

CMS complies with the HHS Standard for Encryption of Computing Devices and Information, as amended, for cryptographic key establishment and management, when cryptography is required.

​​​​​​​Cryptographic Key Establishment and Management (Availability) (SC-12(1))

The purpose of this control is to ensure the organization maintains availability of information in the event of the loss of cryptographic keys by users.

At CMS, mechanisms are employed to:

• Prohibit the use of encryption keys that are not recoverable by authorized personnel
• Require senior management approval to authorize recovery of keys by someone other than the key owner
• Comply with approved cryptography standards mentioned in section 3.9 Cryptographic Protection (SC-13).

Cryptographic Protection (SC-13)

This control aims to ensure that the information system implements cryptographic devices in transit and at rest, as HHS Standard for Encryption of Computing Devices and Information mandates, and in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

Guidance for systems processing, storing, or transmitting PII (to include PHI):

FIPS-validated cryptographic modules are the government standard for encryption. When sensitive information such as PII requires encryption, the organization must comply with these standards.

See Crptographic or Alternate Physical Protection SC-8(1) for Guidance for systems and processing, storing, or transmitting PHI.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-13.

Table 8: CMS Defined Parameters – Control SC-13

At CMS, cryptographic protection applies to both portable storage devices (e.g., USB memory sticks, CDs, digital video disks, external/removable hard disk drives) and mobile devices with storage capability (e.g., smart phones, tablets, E-readers).

When cryptographic mechanisms are needed, the information system uses encryption products that have been validated under the Cryptographic Module Validation Program to confirm compliance with FIPS 140-2 in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

​​​​​​​Collaborative Computing Devices (SC-15)

At CMS, the use of collaborative computing devices such as white boards, cameras, and microphones are strictly prohibited, unless authorized, in writing, by the CMS CIO or his authorized representative. If collaborative computing mechanisms are authorized, the authorization must explicitly identify allowed devices, allowed purpose, and the information system upon which the devices can be used. CMS network users are prohibited from loading non- approved collaborative software such as chat programs onto their GFE.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-15.

Table 9: CMS Defined Parameters – Control SC-15

CMS offers employees a variety of CMS CIO-approved ways to collaborate and engage whether it be for meetings or projects. These tools allow users to collaborate on projects and share or annotate on one another's screen. Some collaborative tools allow users to schedule immediate meetings or recurring sessions.

CMS Collaborative tools users must follow the following video/audio conference call etiquette:

• Be on time.
• Introduce yourself at the beginning of the call (unless you’re late).
• Mute your phone when you’re not speaking.
• Identify yourself each time you speak.
• Say “over” or “I’m done” when you are finished speaking, to avoid talking over others.
• While you are speaking, keep background noise and movement to a minimum (e.g., don’t shuffle papers) so others can hear you.
• Use a handset or headset, rather than a speakerphone.
• If you need to leave a call early, let everyone know at the start of the call.
• Do not put the call on hold (on-hold music will play)
• Close out of collaborative sessions after use, and regularly power down your device each day
• Be mindful of phishing exploits associated with collaborative tools, especially those which have links for scheduled meetings.

For more information on all approved Collaborative computing devices, go to CMS Collaboration Tools on the CMS Intranet. 

Physical Disconnect (SC-15(1))

The purpose of this control enhancement is to ensure the information system provides physical disconnect of collaborative computing devices in a manner that supports ease of use and prevents the compromise of organizational information.

At the end of each meeting with a CMS collaborative tool which includes video conferencing, there’s an option to securely “leave meeting” on the screen or the meeting participants can wait for the host of the meeting to securely end the conference call.

​​​​​​​Public Key Infrastructure Certificates (SC-17)

The purpose of this control is to ensure the organization issues public key certificates under an appropriate certificate policy or obtains public key certificates from an approved service provider.

Public key infrastructure (PKI), as stated in NIST Special Publication 800-32: Introduction to Public Key Technology and the Federal PKI Infrastructure, is the combination of software, encryption technologies, and services that enables enterprises to protect the security of their communications and business transactions on networks21. PKI integrates digital certificates, public key cryptography, and certification authorities (CA) into a complete enterprise-wide network security architecture.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-17.

Table 10: CMS Defined Parameters – Control SC-17

All public key certificates used at CMS are issued in accordance with Federal PKI policy and validated to the Federal PKI trust anchor when being used for user signing, encrypting purposes, authentication, and authorization.

The Certification Authority (CA) is responsible for issuing a public key certificate for each identity, confirming that the identity has the appropriate credentials.

At CMS, various Certificate Authority requests are available and processed through the Infrastructure and User Services Group - Division of Operations Management (IUSG-DOM).

There are two ways to submit a CA request for a certificate:

• Requestor submits a request through the Agency Solutions for Customer Support (ASCS) System.

Note: Only users with a CMS USER ID who have access to or VPN to the CMS Network will be able to login to ASCS. If you do not have a CMS USER ID, see option #2 below to submit an email request.

• Requestor sends certificate request email to the CMS - DOMSSLCert mailbox at DOMSSLCert@cms.hhs.gov

For inquiries on the type of certificate to request, contact the CMS - DOMSSLCert mailbox at DOMSSLCert@cms.hhs.gov for assistance.

​​​​​​​Mobile Code (SC-18)

CMS establishes usage restrictions and implementation guidance which apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations within CMS information systems. The organization must document, monitor, and implement controls for the use of mobile code within the CMS information system. The CMS Technical Review Board (TRB) has the authority to permit or deny the use of mobile code.

CMS complies with the federal guidelines NIST Special Publication 800-28 v2 Guidelines on Active Content and Mobile Code, as amended.

Each form of mobile code has a different security model and Configuration Management process, increasing the complexity of securing mobile code hosts and the code itself. The Configuration Management process prevents the development, acquisition, or introduction of unacceptable mobile code within the information system.

​​​​​​​Voice Over Internet Protocol (SC-19)

CMS prohibits the use of Voice over Internet Protocol (VoIP) devices, unless explicitly authorized, in writing, by the CIO or his authorized representative. At CMS, Integrated VoIP is an audio feature that sends the audio from your WebEx meeting over the Internet, instead of through the telephone. VoIP applications and devices must be configured to meet CMS FIPS 140-2 validated module requirements and must also be on the approved FIPS 171 Validation List.

Integrated VoIP can be a convenient and cost-effective alternative to traditional teleconferencing or WebEx Audio. You may want to use this option when:

• There will be a large number of attendees (up to 500 in Meeting Center).
• Your meeting does not require much attendee participation, for example, a presentation rather than a discussion.
• You don’t have a toll-free number for attendees to call, or prefer not to incur the cost.

Note: There are some limitations with VoIP, such as the number of active microphones permitted and the number of participants who can speak simultaneously.

Additional information on Conducting VoIP meetings can be located in Cisco WebEx University Guide-to-Go.

​​​​​​​Secure Name/Address Resolution Service (Authoritative Source) (SC-20)

This control enables external clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Information systems that provide name and address resolution services include, for example, domain name system (DNS) servers and DNS Security (DNSSEC) digital signatures.

The Domain Name System (DNS) is a distributed computing system that enables access to Internet resources by user-friendly domain names rather than IP addresses, by translating domain names to IP addresses and back.

At CMS, the DNS infrastructure is made up of computing and communication entities called Name Servers. DNS Security (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. Domain Name Service Security (DNSSEC) provides security measures by introducing authentication and validation of sources for DNS responses and by ensuring that responses have not been altered.

A significant portion of NIST SP 800-81rev2 Secure Domain Name System (DNS) Deployment Guide addresses DNSSEC implementation and CMS relies on this guidance.

​​​​​​​Secure Name/Address Resolution Service (Recursive or Caching Resolver) (SC-21)

Each client of name resolution services either performs this validation on its own, or has authenticated channels to trusted validation providers. Information systems that provide name and 

address resolution services for local clients include, for example, recursive resolving or caching DNS servers.

Recursive queries are actions taken when a DNS server is needed to query on behalf of a DNS resolver. DNS name servers deployed within CMS’s Processing Environments are configured to disable recursive queries from the Internet. CMS also uses caching servers at the edge of the Internet to store responses to requests originating from the intranet and received from the Internet.

CMS adheres to the guidance in NIST SP 800-81rev2 Secure Domain Name System (DNS) Deployment Guide, as amended.

​​​​​​​Architecture and Provisioning for Name/Address Resolution Service (SC-22)

The purpose of this control is to ensure the information systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal/external role separation.

CMS’s DNS Architecture employs different types of authoritative name servers. To improve fault tolerance these servers are deployed in each CMS data center.

CMS data center contractors manage all DNS servers, configurations, and tools in accordance with CMS Change Management and Configuration Management processes. 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.

CMS has developed a DNS Business Rules to guide the development of the agency’s DNS architecture, design, and implementations.

CMS adheres to the guidance in NIST SP 800-81rev2 Secure Domain Name System (DNS) Deployment Guide, as amended.

​​​​​​​Session Authenticity (SC-23)

This control addresses communications protection at the session, versus packet level and establishes grounds for confidence at both ends of communications sessions in ongoing identities of other parties and in the validity of information transmitted. 

At CMS, session authenticity is protected through the use of user and device identification and authentication. VPN connections to the information system are re-authenticated periodically during connection.

Additional information on connecting to the VPN can be found in Getting Started with Remote Access to the CMS Network.

​​​​​​​Fail in Known State (SC-24)

Failure in a known state helps to avert the loss of confidentiality, integrity, or availability (CIA) of information as a result of failures of organizational information systems or system components.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-24.

Table 11: CMS Defined Parameters – Control SC-24

At CMS, each operating system fails to a known secure state for all types of failures. Differential system backups are performed on a daily basis, with full backups performed at the weekend. Tape backups allow for restoration of the system back to the previous evening. Backup tapes are stored in an off-site facility. The minimum retention period for tape backups is 90 days.

Protection of Information at Rest (SC-28)

The purpose of this control is to ensure the security of inactive data stored on any device or network.

Data at rest is data that is not actively moving from device to device or network to network such as data stored on a hard drive, laptop, flash drive, or archived/stored in some other way. Data protection at rest aims to secure inactive data stored on any device or network.

Guidance for systems processing, storing, or transmitting PII (to include PHI):

Because of the sensitivity of PII and protected health information (PHI), the confidentiality and integrity of such information must be assured for data at rest.

Guidance for systems processing, storing, or transmitting PHI:

Under the HIPAA Security Rule, this is an addressable implementation specification. HIPAA covered entities must conduct an analysis as described at 45 C.F.R. § 164.306 (Security standards: General rules) part (d) (Implementation specifications) to determine how it must be applied within the organization. However, using cryptographic protection allows the organization to utilize the “Safe Harbor” provision under the Breach Notification Rule. If PHI is encrypted pursuant to the Guidance Specifying the Technologies and Methodologies that Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals (74 FR 42740), then no breach notification is required following an impermissible use or disclosure of the information. Therefore, organizations should use cryptographic protections for PHI stored on electronic media.

The table below outlines the CMS organizationally defined parameters (ODPs) for SC-28.

Table 12: CMS Defined Parameters – Control SC-28

CMS complies with the HHS Policy (HHS Standard for Encryption of Computing Devices and Information), as amended, which mandates the use of the data encryption software on workstations that will automatically encrypt data on removable storage devices once they are inserted into the workstation.

Removable data storage devices allow users to move data from their CMS issued laptop to other computing devices.

CMS currently supports the following data storage devices:

• CMS issued or CMS approved USB Flash Drive.
• CD/DVDs.
• CMS approved External Hard Drives

For information on writing an encrypted file to CD/DVD, go to Storage Device and Encryption.

Sensitive data stored either on GFE or non-GFE (contractor owned) shall be safeguarded in accordance with NIST SP 800-111 Guide to Storage Encryption Technologies for End User Devices and the HHS Information Security and Privacy Policy (IS2P), as amended, including but not limited to:

• Folders/files containing sensitive Personally Identifiable Information (PII) or other sensitive data stored in shared drive shall be encrypted and the folders configured to restrict access on a need-to-know basis;
• Data backups shall be encrypted and securely transported/filed/archived.
• For high-impact systems, cryptographic mechanisms shall be employed to protect the integrity of audit information (e.g. log, and audit tools).

For highly sensitive information such as Sensitive PII (SPII), whole disk encryption alone is insufficient protection. Encryption at the file or folder level is required. Encryption within a database at the field/record/table level will also meet this enhanced standard.

The CMS Encryption of Sensitive Information Memorandum - Appendix A located in the ISP library contains additional information on the CMS Encryption Policy and security controls.

​​​​​​​Process Isolation (SC-39)

The purpose of this control is to ensure the information system maintains a separate execution domain for each executing process.

At CMS, each executing process has a distinct address space so that communication between processes is performed in a manner controlled through the security functions, and one process cannot change the executing code of another process. Relevant information is contained in the information system design documentation and the information system configuration settings in the SSPP of each system.

​​​​​​​Electronic Mail (SC-CMS-1)

Incorporated into SC-8.

​​​​​​​Website Usage (SC-CMS-2)

The CMS website and web services employ secure connections, such as Hypertext Transfer Protocol Secure (HTTPS). HTTPS is a combination of HTTP (Hypertext Transfer Protocol) and the network protocol Transport Layer Security (TLS), which establishes an encrypted connection to an authenticated peer over an untrusted network. CMS implements and configures TLS in accordance with NIST SP 800-52, as amended.

CMS complies with procedures outlined in the HHS Policy for Internet and Email Security, as amended, which include, but not limited to:

• Securing all public-facing websites and internet services and only providing services through a secure connection using Hypertext Transfer Protocol Secure HTTPS-only, with HTTP Strict Transport Security (HSTS)
• Monitoring all active websites periodically and randomly to ensure users adhere to HHS policies
• Using only third-party websites, applications, and services that are authorized and compliant with HHS security and privacy policies.

CMS also complies and operates within the conditions detailed in OMB directives M-10-22 "Guidance for Online Use of Web Measurement and Customization Technologies," M-10-23 "Guidance for Agency Use of Third-Party Websites and Applications” and M-15-13 "Policy to Require Secure Connections across Federal Websites and Web Services”