Stream: Security and Privacy
Topic: Safety Checklist
Grahame Grieve (Dec 06 2018 at 14:23):
@John Moehrke @Alexander Mense I'm working on the safety check list . I have several issues with it
Grahame Grieve (Dec 06 2018 at 14:24):
with the security proposals...
Grahame Grieve (Dec 06 2018 at 14:24):
My system sends an Accounting of Disclosure to the consenter as requested when permitted actions on resources are performed using a FHIR AuditEvent or Provenance Resource
Grahame Grieve (Dec 06 2018 at 14:24):
why both (or either)? What's an accounting of disclosure, and where do we describe it?
Grahame Grieve (Dec 06 2018 at 14:24):
My system follows Privacy by Design Principles sufficient to support compliance with the privacy policies in which it is implemented
Grahame Grieve (Dec 06 2018 at 14:24):
this is not good grammar, and meaningless too. why say it?
Grahame Grieve (Dec 06 2018 at 14:26):
My system appropriately protects any authenticators/authenticator mechanisms, and carefully select the type of credential/strength of authenticator required, based on the use case and risk management.
Grahame Grieve (Dec 06 2018 at 14:26):
what is this a reference to?
Grahame Grieve (Dec 06 2018 at 14:27):
My system follows Privacy by Design Principles sufficient to support compliance with the privacy policies in which it is implemented
Grahame Grieve (Dec 06 2018 at 14:27):
more motherhood that brings no value
John Moehrke (Dec 06 2018 at 15:39):
Much of your observations are why we have provided this only as a proposal. The proposal does need a broader perspective, and a developer perspective, before the items are clear and actionable.
John Moehrke (Dec 06 2018 at 15:41):
Accounting of Disclosures -- This is is described http://build.fhir.org/secpriv-module.html#AoD This would leverage AuditEvent. I don't see a role for Provenance here.
John Moehrke (Dec 06 2018 at 15:43):
PbD -- seems there are multiple mentions of Privacy by Design... We need only one. Privacy-by-Design (PbD) is now required by GDPR, and is emerging in other places too. It is not something that one can test for, as it is a design process time effort. We mention it http://build.fhir.org/secpriv-module.html#privacy
John Moehrke (Dec 06 2018 at 15:46):
authenticator strength -- this is basic security. I am sure you follow it without even thinking about it. Those that forcefully think of it are security centric people, who don't really need to be told this... The specifics are that one needs to have a policy for how strongly authenticated and how strongly proofed an identity is. Once this policy is clear, one must design (or purchace) systems that meet that policy. The risk is using poorly managed user account system to access highly sensitive healthcare information (essentially what most "breach of user database" problems stem from) We reference this http://build.fhir.org/security.html#authentication
Grahame Grieve (Dec 06 2018 at 23:16):
ok, I reconciled the rest of the pages, and the outcome is here: http://build.fhir.org/safety.html
Grahame Grieve (Dec 06 2018 at 23:16):
comments welcome
Michele Mottini (Dec 06 2018 at 23:44):
I started reading it, and it seems to me that is based on a very restrictive view of what a system implementing FHIR is or could be
Michele Mottini (Dec 06 2018 at 23:45):
Our system aggregates clinical data from multiple source, and then make them accessible via FHIR (among other things)
Michele Mottini (Dec 06 2018 at 23:46):
So ' my system handles the full Life cycle ' cannot apply for example
Michele Mottini (Dec 06 2018 at 23:46):
Another example: 'My system will display warnings returned by the server to the user' seems very bad design for a patient-facing app
Michele Mottini (Dec 06 2018 at 23:49):
'My system sends an Accounting of Disclosure to the consenter' - patient agreed to share their data in the original EHR, data got transferred to our system, we publish it via FHIR...and then we should send and AuditEvent to the original patient ??
Grahame Grieve (Dec 07 2018 at 00:38):
I think we expect that the answer to many of these might be 'not applicable', and that this is ok
Grahame Grieve (Dec 07 2018 at 00:38):
'My system will display warnings returned by the server to the user' seems very bad design for a patient-facing app
But no, we add this for a specific reason in a particular place
Grahame Grieve (Dec 07 2018 at 00:40):
As for
my system handles the full Life cycle
I absolutely think that patient facing apps should be able to handle displaying status correctly, knowing when information is considered no longer valid / relevant.
Grahame Grieve (Dec 07 2018 at 06:16):
@John Moehrke @Alexander Mense I am processing the updated safety check list as part of finalising R4, and I have some questions at the proposed list from https://gforge.hl7.org/gf/project/security/docman/FHIR%20Security/
Grahame Grieve (May 23 2019 at 04:04):
There's an entry in the safety check list I am not responsible for, which says:
My system uses security methods for an API to authenticate where Domain Name System (DNS) responses are coming from and ensure that they are valid
Grahame Grieve (May 23 2019 at 04:04):
wow. I have no idea how you'd do that. Any ideas?
John Moehrke (May 23 2019 at 12:38):
SecureDNS. I don't know of anyone that does it... but I lost the vote.
John Moehrke (May 23 2019 at 12:45):
A close to real version of this is recommended in BCP195, that is to do domain name confirmation. That is you look into the Certificate returned during the TLS at the registered domain names, and confirm that the domain name you wanted to go to is in that list. So you are confirming that where you wanted to go, is declared and asserted (signed) inside the certificate. (https://tools.ietf.org/html/bcp195#section-3.6 )
given that we have a checklist item for BCP195, it should not be called out as another checklist item
Luis Maas (May 25 2019 at 01:23):
I didn't write this check list item but I understand this from a practical level to mean: You should use DNS recursors that support DNSSEC and validate DNS responses from authoritative DNS servers that use DNSSEC. Perhaps in the future this item could also refer to DNS over HTTPS, DNS over TLS, or DNS over DTLS, DNS over Blockchain, or the next shiny secure DNS manifestation :)
Grahame Grieve (May 25 2019 at 01:25):
so I'm just a hack programmer, but I don't know how to do this:
validate DNS responses from authoritative DNS servers that use DNSSEC
from a client
David Pyke (May 25 2019 at 01:27):
These are nice to haves for extreme privacy advocates but don't protect data.
Grahame Grieve (May 25 2019 at 01:27):
why did we add it then?
Grahame Grieve (May 25 2019 at 01:28):
I don't know of any http client that supports dns-sec. So I don't know how it can be practical
David Pyke (May 25 2019 at 01:28):
Because they're nice to haves.
Grahame Grieve (May 25 2019 at 01:28):
yeah but they're also can't-have
David Pyke (May 25 2019 at 01:29):
No, it would all be server level security, not client level
Grahame Grieve (May 25 2019 at 01:30):
um. I don't even understand it all then. What does the server do with dns-sec?
Grahame Grieve (May 25 2019 at 01:31):
in http, it's not the server that does dns, it's the client. And as I said, I know of no client framework that does dns-sec. And I bet I'm the only one here that wrote an http client from scratch on a TCP library
Luis Maas (May 25 2019 at 02:09):
The http client itself wouldn't normally support DNSSEC directly -- their DNS recursor would and this would be completely transparent to the http client. Somewhere in the device or server that your client runs on, you have configured statically or possibly given via DHCP the IP address of one or more DNS servers. When the http client invokes a DNS lookup, say by trying to connect to a host by name, the client is actually making a DNS query to one of those servers (called recursors because those servers then start probing recursively around the Internet to get the IP address you need to make your connection from the host name you provide). It's rarely (maybe never) a good idea to include a full-fledged recursor in a client app.
At a high level, DNSSEC is a way that the servers that actually hold the authoritative data about which IP address goes with which host name can digitally sign the responses they send back in a way that the DNS recursor can then validate its authenticity. This protects you from some types of DNS hijacking where your client can be tricked into connecting to an attacker's system even though you've entered the right hostname, as well as some DNS-based DOS attacks. Again, usually the client apps using that recursor cannot tell whether or not the recursor is using DNSSEC. Generally, if you're running your own DNS infrastructure, your DNS engineers should have the expertise to set this up correctly, both for your own recursors (so you don't get misdirected when looking up others), and also for your own authoritative servers (so others looking you up don't get misdirected).
Grahame Grieve (May 25 2019 at 02:38):
their DNS recursor would and this would be completely transparent to the http client
well, ok. I'm not seeing any evidence that this is a testable statement for any app or user of an app?
Grahame Grieve (May 25 2019 at 02:39):
@John Moehrke if I'm wrong, you'd score a lot of points by blogging how a user or an app can check that they are running secure DNS on
- mobile phone (iOS/Android)
- OSX
- windows
- linux
Luis Maas (May 25 2019 at 03:04):
You can do a lookup against a domain where you know DNSSEC is not configured correctly, and see whether you get a response back or an error back. There are a few of these available on the web.
For example, if you can open http://www.dnssec-failed.org/ with your browser, then the recursor you are using is not checking DNSSEC. If you cannot open that page, then your recursor is checking.
Grahame Grieve (May 25 2019 at 03:06):
I get some comcast advertising... so I guess I'm not running dns-sec.. :worried:
Luis Maas (May 25 2019 at 03:09):
This one is somewhat amusing: http://www.dnssec-or-not.com
Grahame Grieve (May 25 2019 at 03:12):
is there a way for a server to find out whether a client is running dns-sec?
Grahame Grieve (May 25 2019 at 03:14):
presumably you just run different end-points
Luis Maas (May 25 2019 at 03:23):
right, that's one way
Josh Mandel (May 27 2019 at 11:23):
in http, it's not the server that does dns, it's the client.
Still, there at plenty of places where we expect a FHIR server to act as a DNS client (e.g., following references, looking up canonical content in a registry, delivering on subscriptions, etc)
Grahame Grieve (May 27 2019 at 11:43):
Sure but it’s still an http client on that stuff
John Moehrke (May 28 2019 at 18:02):
windows from 2012 (Windows 7) on has support for DNSsec.. but it isn't easy... https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831411(v%3Dws.11)
John Moehrke (May 28 2019 at 18:03):
as I said way above... I don't think it should be included as it is very unlikely to be understood except by those in the deep security space, and they don't need to be told this as they already know about dnssec and have likely already forced it.
Jenni Syed (May 28 2019 at 18:31):
that really only works for OS's and workflows from the clinical env or locked down devices. Wouldn't work at all for consumer apps or workflows where each person sets up their own device
Julie Maas (May 28 2019 at 22:44):
Related question that I wonder about: are we validating the OAuth server? I don't mean only checking the server's TLS certificate but also making sure sure a client app is presenting you at the sign in page for the intended healthcare organization and not a phony OAuth server maliciously referenced by a bad or compromised FHIR endpoint, say. phishing that is possibly abusing SMART app launch. Good directories can play a role here; certificates tied to the managing organization and not just the endpoint's hostname may also help. Additional thoughts on this in the middle part of this post.
Grahame Grieve (May 28 2019 at 22:46):
the right solution is to have a few trusted identity providers, and just use them. In most countries, that will mean a national identity server
John Moehrke (May 29 2019 at 13:51):
there are many ways to mess up security... there are many good guidance on how to do it right. We try to itemize these guidance written by security experts as recommendations. Any guidance that we should point at can be added with a CR
Josh Mandel (May 29 2019 at 22:36):
are we validating the OAuth server?
In the SMART launch, this is accomplished through discovery (i.e., if you trust/validate the FHIR resource server, you learn about the OAuth server from that).
(And in the other direction, we sanity-check links through the aud parameter -- i.e., if some phony FHIR server claims to be associated with a legitimate authorization server, the client closes the loop by petting the authz server know which FHIR server it's trying to connect to.)
Last updated: Apr 12 2022 at 19:14 UTC
