Stream: Security and Privacy
Topic: Information blocking and denial of service
Grahame Grieve (Oct 19 2021 at 18:40):
http://community.fhir.org/t/standardized-api-patient-and-population-services-throttling/3185
Cooper Thompson (Oct 20 2021 at 13:34):
We've seen this problem (or related problems) in the wild. A moderate number of organizations deploy WAF (web application firewalls) in front of all their public endpoints, including FHIR APIs. Those WAFs sometimes use fancy heuristics to detect and block "bad" traffic patterns (including looking at volumes of requests). We've had cases where legit traffic gets blocked too. In the case where an organization "knows" about an app, they can add that to an allowlist. But for the wide-open patient access apps, if the app doesn't have a relationship with the healthcare org, there is just always going to be some fudging and risk of getting block by what are reasonable (and probably best practice) network protections.
Cooper Thompson (Oct 20 2021 at 13:36):
But sorry, I'm probably shifting the topic a bit. But to generalize, I think the basic question here is: what reasonable network protections (including throttling) are appropriate in the context of Info Blocking?
David Pyke (Oct 20 2021 at 13:36):
For Info Blocking, an organization is going to have to show that they're making best efforts to allow traffic. So, if their WAF or throttling blocks a legitimate app, and they're informed of it, they need to make best effort to allow that app in a reasonable amount of time.
Lloyd McKenzie (Oct 20 2021 at 14:07):
I suspect there'd also be an expectation that patient-initiated traffic isn't penalized or treated differently than other requests. So patient apps and provider apps should have the same chance of being blocked, and efforts should be made to 'recognize' patient apps without the app authors having to jump through onerous hoops.
Cooper Thompson (Oct 20 2021 at 16:32):
Most WAFs that I'm aware of aren't really FHIR aware. I.e. they don't know anything about patient apps vs. provider apps vs backend. They just know IP ranges, URL patterns, and traffic patterns. On the one hand, that is good, as it makes it hard to discriminate negatively against patient apps. On the other hand that is bad, as you can't discriminate positively against patient apps.
David Pyke (Oct 20 2021 at 16:35):
And you should discriminate positively or negatively for patient apps, they should have the same access rights as any other query source. There just needs a way to whitelist sources by OAuth client ID (or other identifier)
Cooper Thompson (Oct 20 2021 at 17:04):
I agree in principle, but I'm a little skeptical that WAFs will want to become OAuth client ID-aware. Maybe the WAF vendors are up for that, we'll see. If so, then we'll need to build a whole new infrastructure to communicate valid client IDs and associated metadata to the WAFs. And we'd need for give them a way to determine what traffic is associated with a client (e.g. by using JWTs for access tokens and letting them decode and verify). So we'd probably need work in the SMART on FHIR space to make that happen.
John Moehrke (Oct 25 2021 at 17:56):
Forbes article on this topic, leveraging Alissa report -- https://www.forbes.com/sites/danmunro/2021/10/25/millions-of-patient-health-records-now-at-risk-through-unregulated-apis/?sh=ab4d8321812a
Last updated: Apr 12 2022 at 19:14 UTC
