System and Communication Protection (SC)

What is System and Communications Protection (SC)?  

A system is a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. It includes hardware, software, information, data, applications, communications, and people/users.    

Communication is the active process of exchanging information through verbal and non-verbal means. It encompasses all categories of ubiquitous technology used for gathering, storing, transmitting, retrieving, displaying, representing, presenting, organizing, managing, securing, transferring, and interchanging data and information.  

As part of the overall NIST SP 800-53 Rev 5 security controls, the SC control family provides the necessary safeguards to guide and protect the Information System and Communication program of the Centers for Medicare & Medicaid (CMS).  

SC defines and controls CMS connections for network segmentation and boundary protection. It establishes the necessary rules for cryptographic protection, including the use of encryption to secure data. These SC safeguards protect CMS communications at the external and internal network boundaries. Security and privacy assurances are integrated into both the system architecture and each phase of software development to ensure ongoing protection. 

How SC works at CMS 

Protecting and securing the communication of CMS’s information systems helps to ensure the confidentiality, integrity and availability (CIA) of CMS data, which is critical in support of its mission and business functions.    

The Health and Human Services (HHS) Policy for Information Security and Privacy Protection (IS2P), CMS Information Systems Security and Privacy Policy (IS2P2) and CMS Acceptable Risk Safeguards (ARS), requires CMS to implement advanced system and communications protection measures that is essential for maintaining the CIA of Controlled Unclassified Information (CUI) while ensuring operational resilience against cyber threats. CMS Technical Reference Architecture (TRA) implements business rules mandating that all CMS projects and applications comply with these security requirements, unless an exception is approved by the Technical Review Board (TRB). These rules apply across all CMS environments: physical, virtual, cloud, and hybrid.   

All CMS systems that store or process data, including those for Disaster Recovery (DR) and archival storage, must have a CMS Authorization to Operate (ATO). The CMS Information Security and Privacy Group (ISPG) oversees this process, establishing security policies and managing risk to protect critical resources and sensitive information across the agency. This ensures consistent security, enabling CMS to track and manage risk effectively at both the individual system and agency levels. 

Key security measures

The key security measures for the SC program are:

Separation of system and user functionality 

To maintain security, CMS requires a logical or physical separation between user and administrative functions within its IT systems. The CMS TRA provides mandatory technical standards to ensure all systems and infrastructure align with the Federal Enterprise Architecture Framework (FEAF).  

All system development, whether following the flexible Target Life Cycle (TLC) or other methodologies, must comply with the TRA's standards for security, privacy, and accessibility. The TLC uses a continuous governance approach throughout its four phases: Intake, Develop, Operate, and Retire. 

The following documents CMS guidance for systems processing, storing, or transmitting Personally Identifiable Information (PII) (to include Protected Health Information (PHI)): 

To prevent unauthorized access and protect sensitive information such as PII, CMS stores it on separate logical partitions from user applications. This is achieved by using distinct systems, networks, and role-based access controls.  

Specifically, CMS applications are configured to restrict administrative functions to only the secure Management and Security Bands. If application administrative access is required from the user-facing Application Zone, it must be granted through defined roles and documented with compensating controls in the System Security and Privacy Plan (SSPP) and Information Security Risk Analysis within the Information Security Risk Assessment (ISRA). 

Security function isolation  

At CMS, security-related functions are isolated from non-security functions within an isolation boundary to prevent unauthorized access and tampering. This process involves the following:  

• Using techniques like code separation, isolated memory, and strict access controls. 
• Following NIST guidelines for system security engineering. 
• Protecting the integrity of critical security components, such as those that establish user accounts and access authorizations.  

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

Information in Shared System Resources  

To prevent the unauthorized transfer of information, CMS purges shared system resources of sensitive data, such as PII and PHI, after use. This ensures the information is not inadvertently exposed to other users or processes.  

In line with OMB Circular No. A-130, CMS manages information strategically by implementing robust security and privacy programs. CMS uses various data-sharing policies and agreements, such as Data Sharing Agreements and the Medicare-Medicaid Data Sharing Program, to manage and protect shared information. 

Denial-of-service protection 

CMS implements denial-of-service (DoS) and distributed denial-of-service (DDoS) protection measures by: 

• Utilizing traffic analysis and detection tools to identify and block illegitimate traffic. 
• Employing technical controls such as egress filtering and disabling broadcast amplification to prevent network exploitation. 
• Following incident handling guidelines from NIST Special Publication 800-61 to effectively respond to attacks.  

This layered strategy ensures operational resilience and helps CMS mitigate the impact of DoS and DDoS attacks. 

Boundary protection  

CMS implements boundary protection to monitor and control communications at the external and internal boundaries of its information systems. This is achieved using firewalls, routers, and Intrusion Detection Systems (IDS) configured for a defense-in-depth strategy.  

• Communication control: Traffic is managed through controlled routers, switches, and firewalls that follow vendor recommendations. 
• Defense-in-depth: Firewalls and IDS are deployed to create multiple layers of security. 
• Data sharing: Sensitive data remains within defined security boundaries. External data sharing is strictly controlled through agreements such as Data Use Agreements (DUAs) and Interconnection Security Agreements (ISAs). 

Access points 

CMS enhances security by restricting and monitoring access from external network connections, adhering to OMB's Trusted Internet Connections (TIC) requirements (M-19-26).  

All CMS access points and connections use boundary protection devices consistent with CMS's enterprise security architecture, which allows for more effective oversight of inbound and outbound network traffic. 

External telecommunications services 

CMS ensures the security of its external telecommunication services by implementing managed interfaces and traffic flow policies. This provides confidentiality and integrity for all transmitted information.  

To secure external telecommunication services, CMS actively manages network traffic and access by: 

• Deploying firewalls at all internet access points and network perimeters. 
• Requiring formal submissions for all new firewall rules and connectivity requests to ensure proper management of the Wide Area Network (WAN). 
• Mandating that all policy exceptions are supported by formal documentation, a business justification, and a periodic review process that occurs within a three- hundred-sixty-five (365) day cycle. 

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. 

Deny by default/allow by exception 

CMS employs a deny by default/allow by exception firewall policy to control network traffic. This policy is enforced through the following measures:  

• Blocking Inbound Traffic: All network traffic attempting to enter the CMS network is blocked by default. Only explicitly authorized traffic is permitted, which reduces the attack surface and vulnerability to unauthorized access.  
• Permitting Outbound Traffic: Traffic originating from within the CMS network is configured to “deny-all, permit-by-exception." See the CMS Firewall Administration guidelines for additional information.  
• Vetting Trusted Connections: All connections, including machine-to-machine, must be vetted and authorized to protect data integrity. 
• Securing Users and Applications: This policy requires users to register, authenticate, and receive authorization before gaining network access. For applications connecting to external systems, data is protected to prevent compromise. 

Prevent split tunneling for remote devices 

CMS blocks split tunneling to prevent remote access risks. This ensures that CMS systems and external networks cannot be accessed simultaneously from a remote device, which could otherwise expose the system to cyberattacks or data exfiltration.  

CMS enforces this by: 

• Requiring a CMS-issued laptop with pre-installed VPN software. 
• Mandating strong, multi-factor authentication, preferably using a PIV card with a PIN. 
• Restricting remote access to high-speed internet connections, as dial-up is not supported.   

This process channels all network traffic through a secure VPN tunnel, protecting CMS's network integrity. 

Additional information on connecting to the CMS Network using an approved CMS VPN service can be found in the Remote Access Support. Additional information for CMS Federal Employees or contractors using CMS VDI can be found at CMS Employees and Contractors How-To-Guide VDI. 

Route traffic to authenticated proxy servers 

CMS routes internal communication to external networks through authenticated proxy servers at managed interfaces (routers, firewall, and application gateways). For example, CMS Presentation Zone receives requests from external sources and proxies the requests to the Application Zone for processing. 

 This approach helps secure communications by: 

• Acting as an intermediary between users and the internet to control access to resources and protect internal web services. 
• Employing authenticated proxy servers that verify each request before forwarding it. 
• Using URL filter servers to block unsafe websites and track suspicious activity. 
• Implementing XML security gateways to protect internal resources from DoS attacks.  

This security measure ensures that only validated connections are allowed, protecting against attackers and maintaining the integrity of CMS information.  

Fail secure 

CMS employs a fail-safe strategy using redundant network firewalls to ensure that system failures do not compromise security by:  

• Preventing unauthorized access: Firewalls guard the CMS network against malicious external access, such as malware or exploitation through open network ports. 
• Ensuring continuity: Redundant firewall pairs prevent the loss of boundary protection and maintain security even if a single device fails. 
• Segregating network traffic: Each firewall is provisioned with separate interfaces for different network segments, restricting functionality to authorized CMS administrators. 

Isolation of information system components 

CMS employs boundary protection to isolate system components that support different business functions. This is achieved using firewalls and a Network-based Intrusion Detection System (NIDS) to: 

• Isolate and protect components using boundary protection devices that separate system components, thereby increasing protection for individual parts and controlling information flow between them. 
• Monitor for threats using a NIDS to continuously monitor inbound network traffic for malicious patterns. 
• Respond to threats detected by the NIDS by taking actions, such as notifying administrators or blocking the source IP address, based on the severity of the threat. 

Personally Identifiable Information (PII) 

PII is any information used to identify an individual directly on its own, such as a name, social security number, or biometric records, or any information indirectly linked to other information to identify an individual, such as PHI, educational information, financial information, or employment information.  

CMS applies specific processing and monitoring rules for PII at all system entry points and internal boundaries. This is achieved through a comprehensive set of policies and procedures aligned with the Health Insurance Portability and Accountability Act (HIPAA), the Privacy Act, and NIST guidelines.  

CMS PII practices include: 

• User Consent: Explicit user authorization is required for collecting and using PII. 
• System and Data Isolation: Sensitive data is stored on separate logical partitions, and third-party vendors must meet all CMS security standards. 
• Monitoring and Auditing: CMS actively audits and monitors system activity to detect breaches and suspicious behavior. 
• Processing Rules: Specific rules are applied to all PII data elements, and any exceptions are documented, reviewed, and removed as they expire. 
• Vendor Oversight: CMS ensures that third-party vendors processing PII adhere to the same security standards through contractual agreements. 

Transmission confidentiality and integrity 

This security requirement mandates that data transmitted across the CMS network maintains confidentiality (privacy) and integrity (accuracy). This is achieved through security practices such as encryption, digital signatures, secure protocols, hashing, and other data integrity techniques.  

To protect sensitive data like PII and PHI, CMS mandates encryption for all such information, both in transit and at rest. 

This policy, which aligns with the HHS Standard for Encryption of Computing Devices and Information, requires all CMS personnel and business partners to use validated encryption solutions. When encryption is not technically feasible, a specific set of compensating controls must be implemented.  

For additional information, see the CMS Enterprise Data Encryption (CEDE) standards.  

Sending an encrypted email using Office 365 at CMS  

CMS automatically encrypts email communications between its network and services like Office 365. All CMS-provided equipment uses Office 365 Message Encryption (OME) to protect sensitive data sent to external recipients.  

This practice adheres to HHS Policy for Internet and Email Security for enhancing data integrity and minimizing security risks, such as unauthorized access or phishing.   

For additional information, see the CMS Email Encryption Requirements. 

Sending an encrypted email using your PIV at CMS  

For secure data transmission, CMS prioritizes PIV card encryption for emails and attachments containing sensitive information. If PIV encryption is not technically feasible, CMS mandates using a Federal Information Processing Standards Publication (FIPS) 140-3 validated encryption solution.  

In addition, CMS requires specific handling for passwords: 

• Passwords must not replace encryption but can be used as an extra layer of protection. 
• Passwords or encryption keys must be transmitted separately from the sensitive data, using a secure, out-of-band channel like a text message or phone call. 

Sending an encrypted email to a third party through SecureZIP at CMS  

All e-mails with CMS sensitive information must be encrypted using 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 (IUSG).   

Cryptographic protection  

CMS employs cryptographic protection to prevent unauthorized disclosure and detect modifications of data in transit. This is achieved by: 

• FIPS 140-3 Compliance: Using encryption products validated under the Cryptographic Module Validation Program to meet federal standards. 
• Cryptographic Agility: Including the ability to quickly and efficiently change encryption keys, algorithms, and libraries to adapt to evolving threats and vulnerabilities. 
• Standardized Mechanisms: Utilizing cryptographic standards recommended by NIST, such as Transport Layer Security (TLS) and Internet Protocol Security (IPSec), to protect data integrity and confidentiality during transmission. 

Network disconnect 

CMS information systems are designed to automatically identify and terminate all inactive remote sessions (both user and information system sessions) or at the end of a session.  

This applies to both internal and external network connections and is a standard practice for maintaining the confidentiality and integrity of CMS systems. 

CMS applies the following Standard(s) for Network Disconnect. 

• 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 the time stated in the SSPP. 
• Concurrent User ID network log-on sessions are limited to one (1). However, the number of concurrent application/process sessions is limited to what is expressly required for the performance of job duties and must be documented in the SSPP if it is more than 1 concurrent session. 
• Configure systems to document procedures for managing accounts, including creating, disabling, and removing them. 

Cryptographic key establishment and management 

CMS manages and protects the entire lifecycle of its cryptographic keys through a Cryptographic Key Management System (CKMS). When encryption is necessary, CMS systems use keys managed by the CKMS and encryption products validated under the Cryptographic Module Validation Program to ensure compliance with FIPS 140-3. 

This key management system addresses all stages of a cryptographic key's life to maintain security. 

The key management lifecycle at CMS includes four phases: 

• Pre-operational: Keys are generated and established in a secure environment. 
• Operational: Keys are actively used by authorized personnel and systems for cryptographic operations. 
• Post-operational: Keys are retired from active use but may be retained under strict controls for specific purposes. 
• Destroyed: Keys are securely and irrevocably deleted when they are no longer needed. 

This controlled approach to cryptographic key management ensures the ongoing security of sensitive information and aligns with the highest government standards. 

For additional guidance, visit the key management section of the CMS Key Management Handbook and NIST SP 800-57 Recommendations for Key Management (Part 1, Revision 5), updated guideline for general cryptographic key Management.  

Availability 

Availability is ensuring the timely and reliable access to and use of information. It requires the organization to maintain the availability of information in the event of the loss of cryptographic keys by users. 

In CMS, availability for cryptographic keys is ensured by: 

• Prohibiting the use of keys that cannot be recovered by authorized personnel. 
• Requiring senior management approval for key recovery by anyone other than the key owner. 
• Complying with approved cryptography standards for data in transit and at rest, as defined in the HHS Standard for Encryption of Computing Devices and Information, and in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. 

Cryptographic protection 

CMS requires that all sensitive data, including PII and PHI, when transmitted to non-CMS environments, like personal email, must be encrypted using FIPS 140-3 (or a higher standard) compliant encryption solutions.   

At CMS, Application Development Organizations (ADOs) are required to document their key management methods and are encouraged to utilize approved key management systems, in accordance with the CMS Key Management Handbook. In addition, CMS web services applications must use TLS at the highest available level to ensure secure information exchange. 

Collaborative computing devices 

Collaborative computing devices, such as cameras and microphones, must not be remotely activated without explicit, on-site user notification. This provides a safeguard against unauthorized use. 

CMS-specific implementation: 

• CMS prohibits the use of collaborative devices and applications unless specifically authorized by the Chief Information Officer (CIO) in writing. 
• CMS employees are not permitted to install non-approved collaborative software, such as chat programs, on Government Furnished Equipment (GFE). 
• To enable secure collaboration, CMS provides a suite of CIO-approved collaboration tools that allow employees to securely share information, annotate documents, and schedule meetings. 

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 that have links for scheduled meetings. 

Public key infrastructure certificates 

Public Key Infrastructure (PKI) is a security framework that manages digital certificates to verify identities and enable secure data exchange. It relies on a Certificate Authority (CA) to issue, maintain, and revoke certificates for users, devices, or services.  

CMS uses the Federal PKI framework, meaning its public key certificates are issued according to federal policy and are rooted in the "Federal Common Policy CA" for validation. This ensures that all public key certificates within CMS adhere to a consistent, government-wide standard.  

Key functions of CMS's PKI implementation include: 

• Authentication: Verifying the identity of users and devices for network access. 
• Non-repudiation: Ensuring the integrity of digital signatures. 
• Key Establishment: Securely managing the keys used for encryption 

At CMS, Certificate Authority (CA) requests are handled by the IUSG-Division of Operations Management (IUSG-DOM).  

For assistance in determining the appropriate type of certificate, users can contact the CMS DOMSSLCert@cms.hhs.gov. 

Mobile code 

CMS strictly controls the use of mobile code, which is software from a remote system that runs on a local device without formal installation. The policy governs mobile code on both servers and individual workstations, establishing specific usage restrictions and implementation guidelines.  

Key Aspects of the CMS Mobile Code Policy: 

• Approval Authority: The CMS TRB is responsible for approving or denying the use of any mobile code, ensuring compliance with federal guidelines like NIST SP 800-28 v2 Guidelines on Active Content and Mobile Code. 
• Security Control: The Configuration Management process is utilized to manage the risks associated with different types of mobile code, thereby preventing the introduction of unacceptable code into CMS systems. 
• Federal Compliance: All mobile code decisions are made in adherence to federal guidelines, which helps safeguard against vulnerabilities and ensures a consistent security posture.  

Secure name/address resolution service

Authoritative source

CMS uses Domain Name System Security Extensions (DNSSEC) to ensure the security of its domain name resolution. This technology adds digital signatures and cryptographic keys to Domain Name System (DNS) records, which guarantees the authenticity and integrity of data received from DNS servers. 

CMS's implementation of this includes: 

• A distributed architecture: This features multiple authoritative name servers located in different data centers, which enhances redundancy and fault tolerance. 
• Prevention of spoofing: The use of DNSSEC prevents attacks like DNS poisoning and DNS spoofing by verifying digital signatures on all domain records. 
• Strong access controls and monitoring: To manage DNS records, CMS employs strict access controls and monitors for suspicious activity, logging all DNS queries to detect potential attacks. 

This approach ensures that domain name lookups are authenticated, trusted, and protected against manipulation. 

Recursive or caching resolver 

A secure name/address resolution service ensures that organizational systems, such as DNS servers, not only translate domain names to IP addresses but also verify the origin and integrity of the information they receive. This process helps protect against spoofing and tampering attacks. 

The recursive and caching DNS resolvers act as intermediaries for internal users. They translate human-readable domain names into machine-readable IP addresses by querying authoritative DNS servers and storing the results to speed up future requests.  

To secure these processes, CMS implements specific security measures. This includes disabling public access to internal recursive DNS queries, which protects against external threats. 

The goal of this security requirement is to add a critical layer of authentication and integrity checking to the foundational process of name resolution, ensuring that users are not maliciously redirected to fraudulent websites. 

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

Architecture and provisioning

A name/address resolution service, such as a DNS, translates domain names into IP addresses. To ensure this service is reliable and secure, it is designed to be both fault-tolerant and separated by roles. 

• Fault-tolerance is achieved through redundancy, with multiple DNS servers (primary and secondary) to ensure continuous operation even if one fails. 
• Internal/external role separation enhances security by using different DNS servers to handle requests from inside the network versus those from the public internet. This segregation, along with access controls, prevents internal network information from being exposed externally. 

CMS’s DNS Architecture employs different types of authoritative name servers. Including developing DNS Business Rules to guide the development of its DNS architecture, design, and implementations. To improve fault tolerance, once these servers are deployed in each CMS data center.  

The CMS data center contractors are responsible for managing all DNS servers, configurations, and tools in accordance with CMS Change Management and Configuration Management processes. The CMS Production Environment contractors currently provide an 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. 

Session authenticity 

Session Authenticity per NIST refers to the protection of communications sessions from attacks such as session hijacking, man-in-the-middle attacks, and the insertion of false information.  

This requires organizations to implement mechanisms that protect communication session authenticity by addressing protection at the session level, rather than the packet level. This establishes confidence for both parties at either end of the communication session in the ongoing identities of other parties and the validity of information transmitted.   

At CMS, session authenticity is protected by authenticating both the user and the device. For all VPN connections to the information system are re-authenticated periodically during connection. 

For additional information on connecting to the VPN, please see Remote Access Support to the CMS Network. 

Fail in known state 

When systems or components within CMS's IT infrastructure experience failures, they are designed to transition automatically to a predefined secure state. This "fail in known state" principle minimizes disruption, prevents unauthorized access or data loss, and enables controlled recovery. It ensures the CIA of information is protected, even during system outages. 

CMS's approach includes: 

• Secure system configuration: All CMS operating systems are configured to revert to a known secure state upon failure. 
• Data backups for recovery: CMS employs a backup strategy involving daily differential backups and weekend full backups, which are stored off-site for a minimum of ninety (90) days. These backups facilitate system restoration. 
• Protection during outages: If a CMS web application experiences a server failure, it will redirect users to a login page or a static information page rather than exposing sensitive data. 

This strategy ensures CMS maintains security and minimizes the impact of potential system failures, aligning with the organization's mission and business needs. 

Protection of information at rest 

CMS safeguards all information at rest, whether on GFE or contractor-owned devices, using comprehensive encryption that aligns with NIST guidelines and the HHS IS2P. This applies to data on workstations, removable storage, and approved external hard drives. 

CMS’s security practices include: 

• Mandatory encryption: All sensitive data, including Sensitive Personally Identifiable Information (SPII), must be encrypted both at rest and in transit. The CMS ARS defines encryption requirements, and for highly sensitive data, encryption must be applied at the file, folder, or database field level. 
• Highly restricted external storage: Due to security risks, the use of external storage devices (CMS-issued or personal) is heavily restricted. 
• Secure alternatives: Employees must use CMS-approved, cloud-based solutions like Box or SharePoint for transferring files. 
• Encrypted backups: Data backups are encrypted to protect them during transport and archival. 
• GitHub Secret Scanning: This automated process continuously scans code repositories to detect sensitive information, reinforcing zero-trust principles and preventing credential leaks. 
• Audit integrity: For high-impact systems, cryptographic mechanisms are used to protect the integrity of log and audit information. 
• Device control: Workstation software automatically encrypts removable storage devices when they are inserted. Authorized personnel must adhere to specific device specifications outlined in their system's SSPP. 

For additional information, see the CMS CIO Memo for CMS Enterprise Data Encryption (CEDE).

Process isolation 

CMS uses Process Isolation to protect its information systems from unauthorized access and data leakage. This is a security technique that separates different systems or components, with each process operating in its own execution domain.  

CMS implements process isolation through several methods: 

• Virtualization: CMS employs virtual machines to create separate environments for different applications, which prevents them from interacting directly. 
• Network segmentation: The network is divided into distinct zones with access restricted between them. 
• Access controls: The ARS defines authentication and authorization mechanisms that limit user access based on roles and permissions. 
• Distinct address spaces: Each CMS process has a separate memory address space. Security functions control all communication between processes, preventing one process from modifying the code of another.  

Information about these process isolation controls is documented in CMS's system design documentation and the SSPP for each system. 

CMS practices for website usage 

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