Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

HITSCReviewSpreadsheet_V1_.xlsx - Direct Project

VIEWS: 1 PAGES: 43

									SECURITY CONSENSUS REQUIREMENTS - APPLICABLE TO ALL IMPLEMENTATIONS

Security Requirement
Use of X.509 Certificates




Certificate Anchor Configuration




Certificate Granularity




Revocation




Sender Identification




Encryption
Ease of Use




Integrity
US REQUIREMENTS - APPLICABLE TO ALL IMPLEMENTATIONS

         Requirement Text
         The NHIN Direct protocol relies on agreement that possession of the private key of an x.509
         certificate with a particular subject assures compliance of the bearer with a set of arbitrary
         policies as defined by the issuing authority of the certificate. For example, Verisign assures that
         bearers of their "extended validation" certificates have been validated according to their official
         "Certification Practice Statement." Certificates can be used in many ways, but NHIN Direct relies
         on the embedded subject and issuing chain as indicated in the following points. Specific
         implementations may choose to go beyond these basic requirements.


         Implementations must allow configuration of one or more public certificates representing
         "anchors" that implement agreed-to message handing policies. Implementations should allow
         anchors for sending messages to be distinct from those for receiving messages.




         Implementations should allow these configurations to be unique per-address in addition to per-
         health-domain. This will ease integration for participants with an existing PKI infrastructure, and
         provides a path to more fine-grained assurance for future use cases. Implementations must be
         able to accept messages identified per-address or per-health-domain per [Sender Identification
         requirement below].

         When possible, implementations must frequently check the validity of configured or cached
         certificates through standard means. The definition of "frequently" should be defined by
         external policy.

         NHIN Direct messages must be reliably linked to the public certificates possessed by the sender,
         through standard digital signatures or other means that match the certificate subject to the
         sender's address or health domain. Implementations must reject messages that are not linked
         to valid, non-expired, non-revoked public certificates inheriting up to a configured Anchor
         certificate per [Certificate Anchor Configuration requirement above].


         NHIN Direct messages sent over unsecured channels must be protected by standard encryption
         techniques using key material from the recipient's valid, non-expired, non-revoked public
         certificate inheriting up to a configured Anchor certificate per [Certificate Anchor Configuration
         requirement above]. Normally this will mean symmetric encryption with key exchange
         encrypted with PKI. Implementations must also be able to ensure that source and destination
         endpoint addresses used for routing purposes are not disclosed in transit.
Implementations should attempt to ease the complexity of certificate management for end
users and organizations. While this is not a hard protocol requirement, it is important to be
aware that many systems leveraging certificate technology have failed to achieve adoption due
to complexity of PKI management, so efforts here will be a key driver of success or failure for
NHIN Direct. If possible implementations should enable NHIN Direct users to think in terms of
"who do I trust" rather than "what certificates to I import". Implementations should also ensure
that users can leverage existing credential management programs; for example, ICAM in the
federal space (see related links).


NHIN Direct messages must be protected using standard hashing techniques acceptable in
current regulation.
Implied Policy
A digital certificate may be used to authenticate the identity of an
entity involved in an NHIN Direct exchange.




Certificate Authorities ("anchors") for certificates used in NHIN
Direct exchanges must agree to, and implement, a set of
established message-handling policies.
Authentication of end points must include validation of end-point
certificates with their respective Certificate Authorities.
NHIN Direct senders and receivers are not required to use the same
Certificate Authority.

A sender or receiver may be either an individual or an
organizational entity.




NHIN Direct senders and receivers must periodically check the
validity of digital certificates, but are not required to always check.


Messages exchanged using NHIN Direct must be reliably
attributable to their sender.
Digital signatures may be used to reliably attribute messages to
senders; however, other less relable means, such as sender's email
address or domain, are also acceptable.


Messages sent over exposed communication channels must be
encrypted.
Most commonly, symmetric encryption using a secret key
exchanged using public-key certificates will be used, though policy
allows other encryption schemes.
Source and destination endpoint addresses used for internal routing
must be protected in transit.
Certificate management should be as simple as possible for end
users and their organizations.
Implementations should be driven by end users' need for trust, with
complex detail abstracted from the user experience.
Where possible, implementations should enable the use of existing
credential management programs.




The integrity of message content should be protected using a
secure hashing function.
Comments & Questions
Certificates can be assigned to organizations (health domains) and
to people (health endpoints). The implementations vary w.r.t. the
entities to which certificates are issued.




Who establishes these "message handling policies?"




Note that frequency is left open.




Depending upon the nature of the communication, email address or
domain may not be sufficiently reliable.




"Unsecured channels" needs to be defined, including both wired
and wireless.
The Standards & Certification Criteria IFR requires the use of of AES
for symmetric encryption.
I believe I have interpreted the final statement correctly, though it's
somewhat ambiguous.
Existing credential management programs should be required to
meet the same minimal "message handling policies" referenced in
the Certificate Anchor Configuration requirement above.




The Standards & Certification Criteria IFR requires the use of of a
SHA1 hash function for integrity protection.
IHE Implementation: Allows flexibility (e.g., REST, SMTP, XMPP) for sending information from source system to H
secure channel using a SOAP IHE XDR message to the destination HISP, again allowing flexibility in transport from




Technical Implementation




Source HISP generates and adds XDS-compliant metadata to
document before forwarding on to destination HISP.


X.509 certificates used to authenticate the source system (for
source-to-HISP connection) and to mutually authenticate source
and destination HISPs.




Support for self-signed certificates that are pre-coordinated and
configured into a trust-store
Typical configuration is to use certificates to secure the service-
endpoints of the communications


IHE does not mandate a revocation checking protocol as the use of
CRL and PKCS are both mature and widely available.

When intermediaries are required for step-up or step-down, the
intermediaries are included in the trust fabric once they have been
appropriately onboarded through validation of business process,
technology, and procedures.


TLS channels are encrypted using an encryption algorithm
negotiated between end points; IHE profiles require at least AES
(Advanced Encryption Standard).
TLS channels are integrity protected using a hashing algorithm
negotiated between end points; IHE profiles require at least SHA1.
SMTP, XMPP) for sending information from source system to Health Information Service Provider (HISP), where XDR metada
he destination HISP, again allowing flexibility in transport from the HISP to the destination system.




           Stated Policy




           This solution supports but does not require that the source or
           destination pre-coordinate the certificates as long as the resulting
           certificates can be chain-validated to an Anchor.
           All Certificates must be validated when they are used to assure
           their signature validates, that their time boundaries are valid, and
           that they have not been revoked.
IHE profiles require that production systems are at least able to
utilize AES.

IHE profiles require that production systems are at least able to
utilize SHA1.
Health Information Service Provider (HISP), where XDR metadata are generated. The document and metadata are then sent
 the HISP to the destination system.




           Implied Policy




           The HISP may provide value-added services that require disclosure
           of PHI and generation of metadata.


           A source system must authenticate itself to a HISP before using it to
           exchange health information.
           A destination system must authenticate itself to a HISP before
           receiving information from the HISP.
           Source and destination HISPs must be mutually authenticated
           before exchanging health information between them.

           Certificates are not required to be signed by an independent
           certificate authority.
Certificates may be used to authenticate end points (source and
destination systems), as well as HISPs involved in the exchange.


Either CRL (Certificate Revocation List) or PKCS (Public Key
Cryptography Standard #10 - Certification Request Syntax) may be
used to validate certificates.
Transport from source system to XDR backbone, and from
backbone to destination system may involve intermediaries.
Trustworthiness of intermediaries must be validated.




Data exchanged must be encrypted using at least AES encryption
algorithm.

Hashing algorithm must be at least a SHA1 hashing function.
ta are generated. The document and metadata are then sent over a




          Comments & Questions
          Note: The only transport from the source system to the Source
          HISP, and from the Destination HISP to the destination system is
          the XDR Provide and Register Document Set-b transaction. Others
          are shown as options that could be implemented.
          XDR was designed as a reliable, point-to-point messaging system
          for exchanging documents relating to a specific patient, in the
          absence of an XDS document-sharing infrastructure. XDR reuses
          the metadata and messages defined by the XDS (Cross-Enterprise
          Document Sharing) Integration Profile.


          This model subjects PHI to unnecessary exposure. There's no
          compelling business reason why the data being exchanged over the
          NHIN needs to be manipulated by the HISP in order to be
          transported from point A to point B.
Who defines the validation criteria?
REST Implementation: End-to-end Transport Layer Security (TLS) protection between source and destination, pl
Service Providers (HISPs).




Technical Implementation




Message integrity and non-repudiation are achieved
through a message-based S/MIME signature using the
private key of the Source (often times executed by the
Source HISP).
Verification of the signature at the Destination HISP (or
possibly the Destination) requires the X.509 public
certificate corresponding to the private key used to
generate the signature.
Message privacy is achieved through asymmetric
encryption using the public X.509 certificate (public key)
of the Destination.




Decryption of the message is only possible using the
private key of the Destination HISP thus guaranteeing
privacy in transit and at rest.




S/MIME expresses the X.509-based privacy and integrity
features described above in standard multipart MIME
types and headers.
All X.509 public certificates are obtained through the
Certificates REST resource. Certificates may be issued at
the organization or individual level.
The HISP-to-HISP transactions use TLS primarily to
mitigate against on-the-wire snooping of metadata
(such as To and From addresses) that could be
considered Protected Health Information (PHI).


TLS used to protect transmissions between
source/destination end users and source/destination
HISPs.
sport Layer Security (TLS) protection between source and destination, plus S/MIME message integrity, confidentiality, and n




           Stated Policy
Certificates may be issued at the organization or individual level.
tion, plus S/MIME message integrity, confidentiality, and non-repudiation (digital signature) protection between Health Info




           Implied Policy




           The integrity of message content must be protected between
           HISPs.
           Messages sent between HISPs must be digitally signed by the
           source HISP.
The digital signature of the source HISP must be verified by the
destination HISP.
X.509 certificates may be used to authenticate source and
destination servers.
Message content must be public-key encrypted, using the public
key of the destination server.




Messages passed between HISPs must remain encrypted in transit
and at rest, until they are explicitly decrypted by the destination
HISP server.




Communications between HISPs must be authenticated, integrity
protected, and encrypted.
Sensitive data used to describe (e.g., metadata) and route (e.g.,
end-user email addresses) the information being exchanged must
be protected.

Communications between source/destination end users and
source/destination HISPs must be encrypted.
-repudiation (digital signature) protection between Health Information




          Comments & Questions
          Note that this model provides S/MIME integrity, confidentiality,
          and non-repudiation (digital signature) only between two HISPs
          involved in the exchange. These services are not provided
          between the user and the HISP unless the local client chooses to
          provide them. However, all transmissions from the user (client)
          to the final destination are protected using TLS, which provides
          end-point authentication, integrity, and confidentiality
          protection.
A policy requiring that content be encrypted only using asymmetric
(public-key) encryption may not be reasonable or practical.
Symmetric encryption (with the secret key exchanged using a
public-key protocol) should be an option, particularly for high-
bandwidth content (e.g., images).

Note that this is a key difference between a TLS approach and an
S/MIME approach. TLS transmissions are encrypted as they are
sent and decrypted upon arrival at the end point; if that end point
is in front of a firewall, there is an opportunity for exposure.
S/MIME messages remain encrypted while "at rest" in send and
receive queues and are decrypted only when opened at the
destination. However, S/MIME is used only between the source
HISP and destination HISP. The only security provided between
tthe source/destination end users and the source/destination
HISPs is TLS -- unless provided by local client or server.




Unclear whether TLS between end users and HISPs is mutually
authenticated or singly authenticated (end user or HISP). Also,
does not provide any details re integrity protection or encryption
on these links.
SMTP Implementation: Provides users with traditional email accounts to NHIN Direct that can be used with the
transparently adds S/MIME digital signatures and encryption using certificates bound to the source and destinat




Full Service: All functionality is wrapped into a service provided by an organization. Email clients connect to their servers ove
existing email protocols.
Mail Client Plug-In with ISP: Single user (e.g., provider) installs NHIN Direct plug-in into their email client and uses with existi
3rd-party email and DNS services.


Technical Implementation




Adds S/MIME signatures and encryption using
certificates bound to the source and destination
endpoints.
NHIN Direct Agent supports the use of x.509 certificates.

This implementation supports certificate granularity
required; whether organization or individual certificates
or both are used is a matter of configuration.

Uses online re-fetch of certificates to manage
revocation.
Attempts an individual subject match, then an
organization match before rejecting a message.
Encrypts all messages using a public key of the recipient.




Management of certificates can be handled by a HISP on
behalf of an organization, or directly by the organization
itself, resulting in 3 levels of ease-of-use:
1) At the highest "ease-of-use" level, certificate
management can be delegated to the HISP.
2) An organization can obtain one certificate per trusted
CA.
3) An organization can take complete control of
certificate management.
with traditional email accounts to NHIN Direct that can be used with their normal (client or web-based) email applications o
 ures and encryption using certificates bound to the source and destination endpoints. Certificates can be handled by a HIS




a service provided by an organization. Email clients connect to their servers over
provider) installs NHIN Direct plug-in into their email client and uses with existing




           Stated Policy
ith their normal (client or web-based) email applications or with email integrated with EHR products. Adds a security “plug
estination endpoints. Certificates can be handled by a HISP on behalf of an organization, or directly by the organization its




           Existing ISP and Gateway: Organization uses existing ISP-based email and DNS services, and inserts a gateway in their organiz
           handle NHIN Direct agent duties.
Implied Policy




The integrity of email messages must be protected between
sender and receiver.
Email messages must be digitally signed by the sender.
X.509 certificates can be used to authenticate end points in NHIN
Direct exchanges.
Certificates used to authenticate senders and receivers can be
associated with organizations or individuals.




Message content must be public-key encrypted, using the public
key of the destination server.




Certificate management is left up to the individual organization.
with email integrated with EHR products. Adds a security “plug in” that
on behalf of an organization, or directly by the organization itself.




 -based email and DNS services, and inserts a gateway in their organization to
Comments & Questions
Note: In this model, policy enforcement is left up to the
discretion of the user, who must decide when to use their NHIN
Account and what email needs to be sent through the "NHIN
agent." Also, email clients typically allow one to turn off
encryption and digital signature.




A policy requiring that content be encrypted only using asymmetric
(public-key) encryption may not be reasonable or practical.
Symmetric encryption (with the secret key exchanged using a
public-key protocol) should be an option, particularly for high-
bandwidth content (e.g., images, video).
XMPP (Extensible Messaging and Presence Protocol) Implementation: Communication between clients and serv
networking applications, such as Facebook, Google Wave, and instant messaging. Implementation includes a Ja
applications can be implemented using other software-development languages, and can be created such that the




Technical Implementation


Communication between client and server encrypted
using TLS.

Clients authenticate themselves to the HISP using SASL
(Simple Authentication and Security Layer) mechanism.




Server to Server communication encrypted using TLS.


Server to Server authentication will be performed using
SASL External mechanism.

XMPP implementation is testing signing and encrypting
payloads using PKI infrastructure -- not yet part of
implementation.
Server white-listing capability (The capability provides
an easy mechanism for HISP's to determine the other
HISP's that they would like to communicate with). This
feature may or may not be used in the real world but
allows organizations to block organizations or spams.

Endpoint/User level blocking: All end points or users
have the capability to maintain rosters (buddy lists) of
other endpoints/users that they wish to communicate
with. A basic agreement to communicate is established
initially upon mutual consent for communication.
ce Protocol) Implementation: Communication between clients and servers, and between HISPs, are performed using the XM
ok, Google Wave, and instant messaging. Implementation includes a Java "XMPP client" application and a Java "XMPP serv
 ther software-development languages, and can be created such that they only use a web browser.




          Stated Policy
nd servers, and between HISPs, are performed using the XMPP protocol and its extensions; i.e., protocol commonly used by
es a Java "XMPP client" application and a Java "XMPP server" application, both constructed using open-source software. C
hat they only use a web browser.




          Implied Policy


          The transport channel between a source or destination client and
          an HISP must be encrypted.

          Clients must authenticate themselves to the HISP using a challenge-
          reponse authentication scheme.




          Communications between HISPs must be protected using an
          authenticated and encrypted channel between HISPs.

          Authentication between HISPs does not require X.509 certificates,
          but can be context-based challenge-response.
 P protocol and its extensions; i.e., protocol commonly used by social
" application, both constructed using open-source software. Client




           Comments & Questions
           NOTE: This implementation does not meet the consensus
           requirements.




           SASL is an IETF proposed standard, originally developed by
           Carnegie-Mellon. SASL decouples authentication from other
           services to enable secure connections (e.g., TLS connections) to be
           established using a broad range of challenge-response
           authentication mechanisms ranging from "External" (implicit based
           on context) to Microsoft GateKeeper.

           Unclear whether mutual authentication is required.


           This mechanism does not meet the consensus requirement for
           X.509-based authentication.
Implementation     Compliance with Consensus Requirements
                   Note: These two columns assume that the consensus requirements represent valid policy
                   underpinnings. As Arien Malec has noted, the NHIN Direct project got "technology and policy a bit
                   backwards." The HITPC Tiger teamwill be providing policy guidance and direction to the NHIN Direct
                   project.

IHE                Compliant




REST               Compliant




SMTP               Compliant


XMPP               Non-compliant




Recommendations
1. We recommend further development and piloting of the REST implementation, with SMTP email provided by the HISP as a
2. We recommend that no implementation move forward to a pilot until the policy framework, and associated security requ
              Security
at the consensus requirements represent valid policy
oted, the NHIN Direct project got "technology and policy a bit
ill be providing policy guidance and direction to the NHIN Direct


            SOAP WS-Security from HISP to HISP; and between
            HISP and source/destination if the XDR is used for the
            on-ramp.
            Information sent to HISP is used to generate XDS-
            compliant metadata.




            End-to-end TLS for trusted communication path;
            S/MIME for document authentication, confidentiality,
            and digital signature between source and destination
            HISPs.


            End-to-end email security, enforced by individual user.


            Uses an arbitrary set of authentication schemes, none
            of which use X.509 certificates.




he REST implementation, with SMTP email provided by the HISP as an option.
d to a pilot until the policy framework, and associated security requirements, being developed by the Privacy and Security Tiger Team are
            Simplicity




            May be overly complex as "simple" interoperability.




            Simple




            May be too "simple."


            Not well enough defined to be complex or simple.




he HISP as an option.
curity requirements, being developed by the Privacy and Security Tiger Team are in place.
            Other




            XDR designed for point-to-point exchange of patient-
            specific XDS documents; not well suited for exchanges
            of MU quality reports.
            Minimizing disclosure of PHI should be a fundamental
            policy.
            Also, unnecessarily exposes and manipulates PHI,
            presenting both confidentiality and integrity risks.

             Establishment of TLS link between source/destination
            end users and source/destination HISPs is not well
            defined.
            Accommodates asymmetric encryption only; symmetric
            encryption may be needed for high-bandwidth
            exchanges.
            I believe this implementation leaves too much to the
            discretion of the individual user.
            Difficult to integrate with NHIN Exchange.
            Eliminate from further consideration.




ecurity Tiger Team are in place.

								
To top