Stream: Security and Privacy
Topic: HL7 v2 MITM
Grahame Grieve (Apr 28 2020 at 10:11):
I've been asked to review a paper for JIMR that describes a MITM attack on the v2 LLP. It's super-trivial, really - they wrote an ARP agent to redirect IP packets from a blood gas matchine, captured the insecure traffic, altered it, and forwarded it to the EHR after alterations.
Grahame Grieve (Apr 28 2020 at 10:13):
In the mitigations section, the mention LAN segmentation as a possible defense - well, duh! But that made me wonder - can anyone here comment on the operation use of LAN segmentation for things like blood gas analysers? Is it a no-brainer, would always be done correctly, or is that not the case? It seems to me that it would require some additional network hardening to avoid physical changing of the network cables, which might be easy to do in a busy hospital ward
Grahame Grieve (Apr 28 2020 at 10:14):
Do we have any numbers on this
John Moehrke (Apr 28 2020 at 14:10):
There are some use of VLAN to virtually create a LAN that just hosts the medical devices. There are other configurations that place a VPN router between the devices and the servers they talk to (X-Ray device and the PACS). I have no statistics on this, NEMA might. @Elliot Silver @Jonathan Whitby ?
The NEMA imaging workgroup still regularly meets and addresses various things like this that come up in the market https://www.nema.org/Standards/Pages/Cybersecurity-for-Medical-Imaging.aspx
Of course, better is that all endpoints use mutually-authenticate-TLS using managed certificates with revocation checking -- ala ATNA.
Elliot Silver (Apr 28 2020 at 14:36):
No I don't have any statistics for this, but network segmentation is typical for imaging. Generally it is for bandwidth management, rather than security though.
Grahame Grieve (Apr 28 2020 at 19:46):
all endpoints use mutually-authenticate-TLS using managed certificates with revocation checking
That's kind of rather theoretical. No one is going to be able to do with a PoC testing device using MLLP
John Moehrke (Apr 28 2020 at 20:25):
I would agree that mutual-auth-TLS is far more realistic when both ends are within the management of one organization.
John Moehrke (Apr 28 2020 at 20:26):
but it is also very usable where two endpoints are within organizations managed by an organization --- CommonWell ADT for example. (someone check my assertion as I am not 100% sure)
John Moehrke (Apr 28 2020 at 20:27):
if you had indicated the problem was FHIR apps, then I would have not called upon mutual-auth-TLS.. but rather server auth https with OAuth... This accomplishes the same function (when done right).
John Moehrke (Apr 28 2020 at 20:30):
Note that ATNA secure communications transaction has flavors for all these kinds of communications.. Including using S/MIME to secure email (similar to Direct Project), and WS-I async SOAP. (soon an AS4 option, won't that be fun).
John Moehrke (Apr 28 2020 at 20:31):
that is to say that ATNA is not just mutual-auth-TLS... much to the surprise of many who believe that
Vassil Peytchev (Apr 28 2020 at 22:31):
I think Graham is pointing out that a Point of Care device (like a blood gas machine) is unlikely to properly manage the certificates needed for TLS (whether it's MLLP or HTTPS).
Grahame Grieve (Apr 28 2020 at 22:41):
does anyone even use MLLP using mutual TLS?
Lloyd McKenzie (Apr 28 2020 at 22:42):
We did almost 20 years ago - though we also used v2.xml, so we were a bit weird... :)
Grahame Grieve (Apr 29 2020 at 22:32):
@Lloyd McKenzie are the specs for this still around?
Lloyd McKenzie (Apr 29 2020 at 23:37):
I doubt it. Don't believe they were public even then.
Vassil Peytchev (Apr 30 2020 at 02:42):
@Grahame Grieve which part are you referencing - v2.xml, or TLS for MLLP?
Grahame Grieve (Apr 30 2020 at 02:52):
TLS for MLLP.
Vassil Peytchev (Apr 30 2020 at 03:50):
Wouldn't that be just referencing BCP 195?
AFAIK, DICOM and the IHE ATNA profile do just that.
Grahame Grieve (Apr 30 2020 at 04:22):
I'm not sure whether we need to say more about :
- graceful initiation or fall back (security issues, I know but how do we make this practical?)
- mutual TLS?
- a certificate management protocol?
Vassil Peytchev (Apr 30 2020 at 05:01):
I may have more informed opinions in a month or three, but right now I don't see managing TLS for MLLP significantly different from managing HTTPS, and in one small way, they might be easier to manage - if two systems using MLLP are both senders and receivers of HL7 messages, trusting one side's server certificate means the same side's client certificate will also be trusted (assuming the same issuer)
Grahame Grieve (Apr 30 2020 at 05:02):
right. but PoC devices... not much of a UI.... how to manage certs?
Vassil Peytchev (Apr 30 2020 at 05:11):
Pure speculation, but I assume that even PoC devices need to have a method of updating their software. Since common solutions like OpenSSL look for certificates in specific files, these files can be updated like the rest of the software...
John Moehrke (Apr 30 2020 at 12:50):
Certificate management on a PoC device is really not that hard. The mechanics behind "Lets Encrypt" have been standardized in RFC8555 and can be used by PoC devices with no user impact. These result in a certificate being issued to the device that can then be used for either side of TLS. The thing that ACME does not do is create a trust relationship to a specific user or use-case; this would be part of the setup procedure. That setup procedure is typical for any PoC in that it asks for a few things using browser UI.
Grahame Grieve (Apr 30 2020 at 12:50):
I think you're assuming that it has a general purpose OS with a full functional UI attached so that letsencrypt can be used
John Moehrke (Apr 30 2020 at 12:51):
im not
John Moehrke (Apr 30 2020 at 12:51):
the UI comes from a browser session on the users phone, tablet, or computer
John Moehrke (Apr 30 2020 at 12:51):
I just did one of these with a web camera. The web camera has no UI.
Tom Jones (May 01 2020 at 17:15):
Check out this book - Dan is security for IoT at Amazon - full disclosure - he is a long time friend of mine - https://www.amazon.com/Cloud-Security-Control-2nd-Griffin/dp/1494966247/ref=dp_ob_image_bk
Tom Jones (May 01 2020 at 17:19):
or you can look at a presentation he gave 2 years ago https://www.amazon.com/Cloud-Security-Control-2nd-Griffin/dp/1494966247/ref=dp_ob_image_bk
Grahame Grieve (May 01 2020 at 20:41):
@John Moehrke so I don't think that PoC devices come with that kind of functionality - or am I wrong?
John Moehrke (May 01 2020 at 22:52):
@Grahame Grieve if you are asking if a consumer can ADD security that is not designed into an PoC??? No. But a PoC manufacture can design security into the product. They can also design Privacy into the product.
Grahame Grieve (May 01 2020 at 23:03):
but do they? do we know?
John Moehrke (May 02 2020 at 18:49):
well, that is the rub... it is next to impossible for a common consumer to be able to tell if the product they have purchased/chosen is safe, secure, and privacy protecting. That impossibility tends to be a good reason for regulation to step in. Example is the regulated safety requirements for automobiles. The drawback is that this adds overhead in terms of delayed releases, expensive procedures, expensive labs, etc..
John Moehrke (May 02 2020 at 18:49):
note that a consumer can't tell that their Firewall and VPN are working right either... so that is not really a solution
John Moehrke (May 02 2020 at 19:20):
intermediate solution is to have authorities inspect and declare -- Consumer Reports Labs, or even smart-person-I-know says so.
Grahame Grieve (May 03 2020 at 20:48):
seems to me that we or IHE should host a connectathon around MLLP over TLS (as opposed to an IPSec tunnel), and also someone should post a open end point on the net somewhere to serve as a reference test case
John Moehrke (May 03 2020 at 23:42):
I suspect that is already done with Gazelle, and thus available today. Ill check into it.
John Moehrke (May 04 2020 at 00:09):
It would surely have been tested with XDS testing, which requires ATNA, and also requires PIX or PDQ (both HL7 v2)...
Grahame Grieve (May 04 2020 at 00:10):
hmm I had not paid attention to this. PIX and PDQ require secure transport? And ATNA is not in scope for PoC testing devices?
John Moehrke (May 04 2020 at 00:11):
right, XDS is not really a PoC use-case... yet.
John Moehrke (May 04 2020 at 00:11):
but, yes XDS mandated ATNA... when ATNA is mandated it is mandated for the whole system... which means the PIX or PDQ one uses to do patient lookup must be (able to be) secured by mutual-auth-TLS
John Moehrke (May 04 2020 at 00:12):
In theory.. that ATNA (virus) spreads to all communications in/out of your system... but that is likely not tested beyond the PIX/PDQ use with XDS.
Grahame Grieve (May 04 2020 at 00:13):
ok good. That's not quite an answer to my question about ATNA though - ATNA itself is not in scope for PoC testing devices? (I know XDS is not)
John Moehrke (May 04 2020 at 00:14):
I would need to get someone from the devices domain to speak authoratively on that. I don't know all the domain specifications that have mandated, or recommended ATNA... or more specifcally tested it is fact vs theory
Grahame Grieve (May 04 2020 at 00:14):
it would seem that IHE is closer to this - I would encourage IHE to unbundle secure v2 comms out of the XDS use case and make it available for testing in it's own right, to increase accessibility
John Moehrke (May 04 2020 at 00:14):
it is available for ALL profiles
John Moehrke (May 04 2020 at 00:15):
grouping with ATNA is available for any use-case
Grahame Grieve (May 04 2020 at 00:15):
i'll ask my question differently: is there any functional or business benefit to a PoC device in implementing ATNA ?
John Moehrke (May 04 2020 at 00:15):
security
John Moehrke (May 04 2020 at 00:16):
I get the feeling that you see a drawback
John Moehrke (May 04 2020 at 00:17):
note that ATNA now has FHIR R4 AuditEvent as an alternative for auditing rather than SYSLOG/DICOM/RFC3881
John Moehrke (May 04 2020 at 00:19):
and of course, audit logging is allowed to be turned off or locally stored... so it is a low bar.
Grahame Grieve (May 04 2020 at 00:19):
I'm just looking at from the pov of the buyers and sellers of the devices - what is the least expensive route to get an IHE approval that is meaningful? looking at ATNA, I feel as though it includes some thing that will cost manufacturers - and therefore buyers - real dollars without delivering any actual benefit. If those things can be moved out of the bundle, then it will cost less $$ to get secure and certified by IHE. Which will improve actual security
John Moehrke (May 04 2020 at 00:20):
would welcome a constructive recommendation on making it easier. I don't think it is as hard as you guess.
John Moehrke (May 04 2020 at 00:21):
Especially if the PoC implements ACME for certificate issuing. (which I think is what Gazelle test service supports for the IHE Connectathon)
John Moehrke (May 04 2020 at 00:24):
note I do have a rant against ACME, as it totally lacks any Identity Proofing... but that Proofing could be added by a human workflow, like I did with my web-camera... Once specifically proofed, it is added to a whitelist. So cert is used for security, and existance on the whitelist authorizes use.
Grahame Grieve (May 04 2020 at 00:24):
so according to https://wiki.ihe.net/index.php/Audit_Trail_and_Node_Authentication, requirements:
- limit access to authorized users - I sure hope that they are doing this, but is it allowed to say that anyone who has physical possession of the device is an authorised user?
- requires the use of bi-directional certificate-based node authentication for connections to and from each node - does it need to be bi-directional for a PoC device?
- Audit Trail - it appears that the profile requires that there be an audit trail. I'm dubious as to the business value of this in a device
John Moehrke (May 04 2020 at 00:25):
see previous comments on audit logging
John Moehrke (May 04 2020 at 00:25):
on access control, that is a functional requirement that is fully in the control of the PoC system... so this is a non issue
John Moehrke (May 04 2020 at 00:25):
yes, bi-directional is important
John Moehrke (May 04 2020 at 00:26):
unless you are going to use OAuth for client.. which is a fine alternative.... but if you are going to just have server side http, then what is the value add?
Grahame Grieve (May 04 2020 at 00:26):
see previous comments on audit logging
"audit logging is allowed to be turned off or locally stored" - but it still must be implemented. So I think that's the thing I think should be unbundled for PoC devices.
Grahame Grieve (May 04 2020 at 00:28):
just have server side http, then what is the value add?
We're worried about MITM right? So if you write a client that authenticates the server, and follows a revocation list, that sorts out MITM, no? Or we do we assume that the revocation list part is too fragile?
John Moehrke (May 04 2020 at 15:16):
Client can do good validation which would include revocation checking , expiration checking , and server name validation (all things covered in BCP195). But this does not address malicious clients reading, creating, or updating data. This is what the client auth is for.
John Moehrke (May 04 2020 at 15:17):
client auth can be by TLS client cert, or by OAuth, or by some other method... These are all recognized in ATNA. So there is nothing burdensome identified yet.
Grahame Grieve (May 04 2020 at 19:38):
auditing must be implemented.
John Moehrke (May 06 2020 at 15:49):
IHE Gazelle has a Security Suite that was developed by the Kereval team in Europe. Its capabilities have evolved over time. It includes:
- Issuing digital certificates. I don’t know what software underlies their PKI.
- TLS simulators for client & server, including support for the new ATNA options for various flavors of TLS compliance.
- validator for ATNA audit records, syslog format, including transaction-specific contraints
- Audit Record Repository actor simulator (syslog only). I have requested FHIR AuditEvent support.
- XUA SAML STS. Requested support for IUA OAuth
User documentation is here: https://gazelle.ihe.net/gazelle-documentation/Gazelle-Security-Suite/user.html
Testing the HL7 v2 is done independent, with the presumption that grouping is just logical assembly of the HL7 v2 messaging within a TLS tunnel.
Last updated: Apr 12 2022 at 19:14 UTC
