§170.210(f) Encryption and hashing of electronic health information. Any encryption and hashing algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the FIPS Publication 140-2 (incorporated by reference in § 170.299).This Encryption and Hashing requirement is important but not hard to meet. The important part is that proprietary encryption is unacceptable, old encryption algorithms are unacceptable. Modern encryption (AES and SHA) are acceptable. The use of FIPS Publication 140-2 allows HHS and CMS to benefit from the intelligence community assessment of cryptographic algorithms, thus moving up automatically when the intelligence community does. The use of Annex A rather than the core FIPS 140-2 specification allows for relaxed rules around certification, this doesn't change the technical aspect but it does greatly reduce the invasive code inspection requirements of actual FIPS certification. The Annex A is very short, 6 pages long.
The summary:
- Encryption AES or 3DES;
- Hashing SHA1, or higher;
- Authentication is totally missing in MU2, although RSA is included in FIPS.
- Direct – S/MIME authenticated using X.509 Certificates/Private Keys, Encrypted with AES128 or AES256, and Hashed with SHA1 or SHA256.
- Secure SOAP –secured with Mutual-Authenticated-TLS using X.509 Certificates/Private Keys, Encrypted with AES, and hashed with SHA1 (HMAC-SHA1). This specification also indicates that the user identity be provided using SAML assertions -- This is the same requirements that IHE has for XDR, XDS, XCA, etc... through IHE-ATNA and IHE-XUA profiles.
- Secure HL7 v2 – There is no mention in MU2 of this dirty little secret, but all of those HL7 v2 requirements in the regulation would also need to meet the Encryption and Hashing requirement. The solution here is to use the Mutual-Authenticated-TLS as is used in the Secure SOAP stack. Many toolkits support this, but not all of them. At IHE Connectathon we run into people who have forgotten to test this, they usually get going quickly. As indicated above the low bar is just 3DES and SHA1; IHE starts with AES and SHA1.
- Patient Engagement - Secure Messaging – There is no guidance on what Secure Messaging is, and I think this is the right solution. But whatever is used for Secure Messaging must also meet the § 170.210(f) requirements. Given that the requirements are just focused on Encryption and Hashing; this is easily met with a typical HTTPS web-portal. This will only be server authentication, but the user would be authenticated and thus it is up to the user to use a trustable machine. Typical HTTPS will also include encryption and hashing of sufficient strength -- 3DES and SHA1
- Data at Rest – End-user device encryption. -- Okay this isn't a transport, but whatever solution used to protect data at rest, it must also meet the Encryption and Hashing requirements. A good commercial solution or even the solutions built into operating systems cover this. What they don’t cover is KEY MANAGEMENT. If you don’t protect the key then it doesn't matter how well encrypted. Please leverage good solutions that were developed by specialists.
- Note that the best solution that is MU2 compliant is to NEVER save PHI onto the client workstation. This simply stops the risk at the root. This is not always easy, but is the best.
- The Operational environment should be able to leverage transparent hard-drive encryption.
- Secure SOAP – End-to-End security - This is not in MU2 – In IHE there is an option to use WS-Security end-to-end security, but this requires also an update of common SOAP stacks and is administratively harder to achieve. Risk Assessment needs to drive the cost benefit. This model also suffers from the same problem Direct has in that to send something you must discover the endpoints Digital Certificate before you start the conversation. Where as TLS does the discovery inline as part of the protocol negotiation.
- Moving to SHA256 with TLS requires an upgrade.
- Direct addresses- Trusted vs Trustable
- Identity - - Proofing
- Securing RESTful services
- Healthcare use of X.509 and PKI is trust worthy when managed
- SSL is not broken, Browser based PKI is
- Meaningful Use Stage 2 :: SHA-1 vs SHA-2
- Trusting e-Mail
- S/MIME vs TLS -- Two great solutions for different architectures
- Healthcare Provider Discoverability and building Trust
- Using both Document Encryption and Document Signature
- Document Encryption
I doubt that MU2 requirements are secure enough for healthcare. The problem of security is so important in healthcare that to my mind it is necessary to use more severe the requirements.
ReplyDeleteThere are likely multiple misunderstandings in this comment. First, the MU certification criteria are simply "Capabilities". Meaning that all that MU is doing is trying to make sure that the software that is an EHR comes with basic security capabilities. The alternative is that Healthcare Providers might focus purely on the clinical functionality and end up with a committment to software that lacked basic security capability. So no one should look at the MU security criteria as a guarantee that the EHR is secure.
DeleteWhich brings up the second misunderstanding. The MU criteria, being just capabilities, must be implemented in an operational environment. This is where HIPAA Privacy and Security rules already cover well. These regulations are focused on the operational environment providing security and privacy. Thus, the healthcare provider organization must still do a risk assessment that is holistic and mitigate the risks using physical controls, technical controls, and policies. The technical controls are often the EHR security capabilities, but also include firewalls and such.
This comment has been removed by a blog administrator.
ReplyDelete