What is an XML standard that allows secure web domains to exchange user authentication and authorization data in an SOA?

SOAP- and REST-based services have very different security infrastructures. SOAP security models follow W3, OASIS, and other XML-based standards. REST security follows the technologies of the Web with no reliance on XML or OASIS standards. This section describes CMS’s adopted SOAP and REST standards for securing Web Services.

HTTP/S for External SOAP and REST Web Services

The most frequently used (and only common method between both SOAP- and REST-based web services) is HTTP/S. HTTP/S is HTTP protocol over Transport Layer Security connections. TLS protects the connection between client and server against risk of interception by encrypting the data and authenticating endpoints. TLS is capable of server-only or mutual authentication where both the client and server are authenticated cryptographically.

There are a few exceptions: please refer to the Security Services section for specific details.

Protect PII, PHI, and Sensitive Information

The CMS ARS contains a broad set of CMS security controls based on NIST requirements. CMS mandates compliance with the following security specifications:

Protect Sensitive Information in Transit

• All Personally Identifiable Information, Protected Health Information, or other sensitive data entering, exiting, or in transit within the data center (withing or across zones) must be encrypted and secured according to the guidance in the CMS ARS. Applications must use Transport Layer Security (TLS) at the highest available level to exchange information securely. When possible, applications should use mutual authentication to ensure the identity of both parties in an information exchange. If encrypting sensitive information is not technically feasible or demonstrably affects the ability to support mission operations, compensatory controls must be implemented as part of a CIO approved risk acceptance plan.

Related CMS ARS Security Controls include: CA-3 - Information Exchange, CA-3(6) - Supplemental: Transfer Authorizations, CP-9 - System Backup, CP-9(8) - Cryptographic Protection, PT-7 - Specific Categories of Personally Identifiable Information, MP-5 - Media Transport, SC-7(24) - Personally Identifiable Information, SC-8 - Transmission Confidentiality and Integrity, SC-12 - Cryptographic Key Establishment and Management, SC-13 - Cryptographic Protection, AC-2 - Account Management, AC-3 - Access Enforcement, AC-5 - Separation of Duties, AC-6 - Least Privilege, SI-4 - System Monitoring, SI-5 - Security Alerts, Advisories, and Directives, SI-7 - Software, Firmware, and Information Integrity, SI-10 - Information Input Validation, and AC-21 - Information Sharing.

Protect Sensitive Information at Rest

• The application must protect the confidentiality and integrity of all sensitive data (including all PHI or PII).

• The application must protect the confidentiality and integrity of all sensitive information (including all PHI or PII) according to the guidance in the CMS ARS. This includes using encryption that meets or exceeds the FIPS 140-2 encryption standard. The implemented level of encryption must be aligned to the sensitivity of the information. If encrypting sensitive information is not technically feasible or demonstrably affects the ability to support mission operations, compensatory controls must be implemented as part of a CIO approved risk acceptance plan.

Related CMS ARS Security Controls include: MP-4 - Media Storage, SC-12 - Cryptographic Key Establishment and Management, SC-13 - Cryptographic Protection, AC-2 - Account Management, AC-3 - Access Enforcement, AC-5 - Separation of Duties, AC-6 - Least Privilege, SI-4 - System Monitoring, SI-5 - Security Alerts, Advisories, and Directives, SI-7 - Software, Firmware, and Information Integrity, SI-10 - Information Input Validation, SC-1 - Policy and Procedure, and SC-28 - Protection of Information at Rest.

SOAP-Specific Web Services Security

An essential reason to use Web Services is to enable software integration that crosses boundaries and leads to organizational integration. When legacy systems are involved, integration requires one application to extend its architecture to communicate with another application with which it did not previously communicate. Integration may also mean reusing existing services for new purposes.

As CMS’s Web Services evolve, interoperability should encompass communication standards that allow distinct systems to cooperate—an especially important capability when those communications must be secure.

Implement XML Filtering

CMS requires implementation of XML filtering of Web Service transactions before they propagate into the enterprise. Toward that end, XML documents must be:

• Well-formed (syntactically correct according to the XML 1.0 specification)

• Schema conformant to the referenced schemas

• Semantically correct (contains valid data)

Typically, XSLT-based rule sets, executed using dedicated XML gateways, perform XML filtering.

All requests that fail to pass validation, must be logged for further analysis, and prevented from entering the CMS Processing Environment.

Anticipate and Protect against XML Denial-of-Service Attacks

CMS seeks to enable access to resources while simultaneously using XML filtering rules to control entry into the CMS Processing Environment. By providing a hardened intermediary, the XML security gateway protects the internal web service resources from denial-of-service attacks. Using an XML security gateway as a proxy, network managers can configure simple settings on message size, frequency, and connection duration.

Consider Digitally Signing Messages

Message-level security is the key building block for end-to-end security. It provides additional security beyond that supplied by transport, and offers message integrity, message authentication, non-repudiation, and confidentiality. Message integrity with signatures ensures detection of message tampering.

WS-Security specifies mechanisms for message integrity. WS-Security elements describe how to represent and associate a cryptographic signature with specific parts of a SOAP message. This approach allows arbitrary, well-formed fragments of the message to have separate signatures.

Web Service messages that contain sensitive data should be signed by the sender and include creation of a secure audit trail by logging each message with a signature that can be verified post transaction. Because each log entry is signed, its contents cannot be modified or altered, and the receiver gains non-repudiation protection. One may mitigate the processing-intensive nature of signing and verifying every incoming and outgoing message by using a hardware appliance rather than a software-based solution.

Encrypt Message Fields

WS-Security specifies mechanisms for encryption of SOAP messages. Encryption of message fields is rarely done in practice; however, in some instances, encrypting message fields should be considered when XML messages undergo some number of anticipated transformations prior to use.

XML Encryption (and decryption) requires fully parsing the XML transaction and then, for select message section(s), performing a set of processing-intensive XML and cryptographic encryption (decryption) operations. The advantage of using field-level encryption is that the message as a whole may be transformed without requiring re-encryption if transformations do not affect the encrypted fields. This may offer significant performance benefits. The principal disadvantage of XML encryption is its additional complexity and potential performance impact.

XML Encryption and XML digital signatures are resource intensive. Deploying both can significantly affect the performance of high-transaction applications. CMS advises mitigating this approach by using hardware (an appliance, for example) rather than a software-based solution.

Encryption of message fields must follow encryption guidance detailed in the Security Services section.

Time-Stamp Messages

CMS recommends using a Network Time Protocol (NTP) facility to synchronize network nodes to a single, authoritative time-source reference within the CMS enterprise and with CMS stakeholders. An NTP facility augments non-repudiation capabilities when used with XML Digital Signatures.

Consider SOAP Web Services Security

Web Services Security (WSS) is an extension to SOAP to enable declarative security. WSS identifies agreed-upon specifications and policies for message integrity, authentication, confidentiality, and non-repudiation. Because WSS supports message-level security, it can provide end-to-end security that is not possible by using TLS. TLS can only support point-to-point security.

The general Web Services Security model supports such security modes as identity-based authorization, access control lists, and capabilities-based authorization. This model for security tokens allows use of existing technologies, including:

• X.509 public key certificates (recommended practice at CMS)

• SAML Assertions (recommended practice at CMS)

• Kerberos shared-secret tickets

• Password digests or hashes (generally discouraged at CMS)

Various approaches may be used to create security tokens. A Web Service may use a security token from local information, or a security token may be retrieved from specialized services such as an X.509 certificate authority or a Kerberos domain controller. The preferred methodology is using SAML, an XML-based framework for exchanging security information expressed in the form of assertions about subjects, where a subject is an entity (either human or computer) that has an identity in some security domain.

REST-Specific Web Service Security

REST leverages the security infrastructure of the Web, which means relying on HTTPS and TLS for transport-level security. Typically, message-level encryption is not used. If required, the service provider must document the steps to encrypt and decrypt messages using available technologies. At the time of this publication, there are no interoperable standards for JSON messages.

CMS has adopted the National Security Agency (NSA) Security Recommendations for REST,1 including:

1. Use PKI and HTTPS (HTTP with TLS).

2. Sensitive data should never be cached or put into a visible URI.

3. Use an authorization service.

4. Code as if protecting the application.

Like SOAP Web Services, REST-based services must validate the syntax and semantics of every service request.

Other security-related best practices (some of which are repeated from the REST best practices section) include:

1. Use HTTP error codes but be cautious about revealing internal structures. Do not send stack traces back as part of error and exception handling. (please refer to CMS ARS Security Control SI-11 – “Error Handling”)

2. Use JSON web tokens (or equivalent).

3. Support Single Sign-On.

4. Consider using API Keys.

5. API endpoints use HTTP Accept Headers to determine response media type.

6. Use CORS for security, not JSON with Padding.

7. Provide mechanism to throttle API.