To guide EFT within the CMS Processing Environments, CMS developed the following business rules.
BR-EFT-1: (Deprecated after TRA 2018R1): File Naming Conventions Must Be Obeyed
BR-EFT-2: Limited Protocols Are Permitted in the CMS EFT System
Table Permissible File Transfer Protocols lists the only protocols permitted in the CMS EFT system.
New users are encouraged to use S/FTP as the preferred EFT protocol.
Rationale:
The CMS EFT system only supports the listed protocols.
BR-EFT-3: Use Mailboxes between Business Partners Only
CMS allows EFT mailboxes to store collections of files transferred between external business partners and CMS. CMS prohibits using mailboxes as work areas or as a communication facility between internal CMS applications. Pushing files to the partner with SFTP is preferred.
Rationale:
The EFT mailboxes consume resources and are not designed as work areas. Once information is transferred, the mailboxes must release storage resources.
BR-EFT-4: Registration Is Required When Using the CMS EFT System
If using the CMS EFT system, each new file must be registered with the CMS EFT system authority to ensure that the routing tables are modified correctly and that the correct jobs will execute upon file identification.
Rationale:
The EFT infrastructure requires pre-registration of the files to be transferred to ensure proper routing.
BR-EFT-5: Internal Integrity Validation Is an Application Responsibility
The CMS EFT infrastructure guarantees proper transfer of files using permitted protocols. Validating the internal integrity of a file is the responsibility of the receiving application. The EFT infrastructure does not inspect the internal contents of a file to determine data integrity.
Rationale:
The CMS EFT infrastructure has no knowledge of the internal data schemas for files transferred. Thus, it cannot identify schema problems. It only guarantees that the same bytes of information are transferred.
BR-EFT-6: File Encryption Is an Application Responsibility
The CMS EFT infrastructure encrypts the transport mechanism (typically TLS), but does not encrypt (or decrypt) the data files individually. Encrypting data files must be done by application owners themselves and must, on an ongoing basis, be consistent with current CMS ARS requirements and relevant federal law, regulations, and executive orders. (Please refer to BR-EFT-11.)
Rationale:
This rule removes the burden of performing file-level encryption from the EFT infrastructure. It also ensures that EFT infrastructure does not manage file transfer encryption keys.
BR-EFT-7: Secured Transmission Is Required
Files must be transmitted over a CMS ARS-approved secure protocol, as determined by the current version of the CMS ARS at the time of transmission, such as TLS v1.2 (or later). Unsecured protocols such as FTP or telnet must not be used unless tunneled over a secure protocol, as permitted by the CMS ARS.
Rationale:
File transfer software must be configured to ensure secure file transmission to prevent inspection by unauthorized parties.
BR-EFT-8: IP-Based File Transfer Protocols Only
IP-based file transfer protocols are now mandatory. All currently approved protocols are IP based.
Rationale:
CMS infrastructure no longer supports non-IP based network protocols.
BR-EFT-9: (Deprecated,replaced By RP-EFT-1 after TRA 2018R1): Transfer Large Files Using Check-pointing Protocols
BR-EFT-10: Encrypt Files Residing in EFT Mailboxes
Files sent to or received from mailboxes must be encrypted by the application (not the EFT infrastructure) in accordance with the current CMS ARS-approved cryptography rules and stored in encrypted form while residing in any EFT mailbox.
Rationale:
Because external parties can access these files, the files must be encrypted at REST while residing in the EFT mailboxes.
BR-EFT-11: CMS Data Files May Only Be Transferred to the Data Zone
CMS data can only persist in a zone within the multi-zone architecture which has been appropriately secured to house sensitive data. Within CMS Data Centers, CMS data cannot be transferred using EFT to a system’s Application or Presentation Zone because these zones are not allowed to host persistent sensitive data. In the cloud environment, where explicit zones are not as clearly defined, the implementer must ensure the appropriate security mechanisms have been applied. These mechanisms include authentication, authorization, security certificates, routing rules, and filtering as discussed in CMS Services Framework Mediation Principles.
Rationale:
This is an extension of CMS TRA rules about storage of persistent data outside of the Data Zone. Sensitive data may only persist in an appropriately secured zone (data zone). Sensitive data may exist temporarily outside the data zone for processing, such as data validation, prior to persistent storage. If longer duration processing is required, consider placing the processing system in the Data Zone (CMS data center) or a zone appropriately secured for sensitive data.
BR-EFT-12: CMS Data in ATO’d Environments May Not Be Transferred to Non-ATO’d Environments
EFT cannot be used to move CMS data from an environment with an ATO to an environment that does not have an ATO unless that data has been de-identified.
Rationale:
This rule is intended to prevent data movement to lower environments. Only ATO’d environments have been formally verified to meet stringent CMS security controls. Projects or applications should not be seeking to move data from an ATO’d environment to a non-ATO’d environment without first consulting the CMS TRA and CMS ARS rules.
BR-EFT-13: CMS Data May Not Be Transferred Outside of CMS Processing Environments without a Prior Agreement
CMS data may only be transferred under a Data Use Agreement, Memorandum of Understanding, or similar agreement that establishes how third parties may use data.
Related CMS ARS Security Controls include: CA-3 - Information Exchange, CA-3(6) - Supplemental: Transfer Authorizations.
Rationale:
CMS data may only be shared with third parties under agreement unless the data has been identified as public data.
RP-EFT-1: Transfer Files Using Check-Pointing Protocols When Performance Impacts Are a Concern [Formerly BR-EFT-9]
In some circumstances, file transfers may be susceptible to failures and require resending. Repeated retransmissions may impact system or network performance. When such impacts pose a significant concern, an engineering and risk-based decision may be made to use check-pointing protocols to transfer files. Check-pointing protocols allow for interrupted transfers to be restarted from the last confirmed checkpoint rather than from the beginning of the file. This reduces the burden on CMS networks and systems and helps ensure a successful transfer.
Rationale:
A check-pointing protocol ensures much more efficient file transfer for both sender and receiver. It also reduces the burden on CMS networks and systems. Check-pointing works if supported and permitted by both the client and the server.