Please secure your #FHIR API and Apps

 Just updated the FHIR core spec Security and Privacy Module with a simple message, yellow highlight for the new text:

6.0.3 Security 

FHIR is focused on the data access methods and encoding leveraging existing Security solutions. Security in FHIR needs to focus on the set of considerations required to ensure that data can be discovered, accessed, or altered only in accordance with expectations and policies. Implementation should leverage existing security standards and implementations to ensure that:

• All communications can be encrypted to prevent unauthorized access.
• No information leaks when errors occur
• No active script content can be injected into narrative resources
• Full audit trails can be constructed and used to detect anomalous access patterns

For general security considerations and principles, see Security. Please leverage mature Security Frameworks covering device security, cloud security, big-data security, service-to-service security, etc. See NIST Mobile Device Security  and OWASP . These security frameworks include prioritized lists of most important concerns.

Recent evidence indicates lack of implementer attention to addressing common security vulnerabilities emphasized by OWASP top 10 API . Reviewing the OWASP Top Ten and OWASP mobile top 10  and ensuring those vulnerabilities are mitigated is important for good security.

The Security Checklist also added two new items

12 When using OAuth  - Consider the draft Best-Current-Practice for OAuth 

13. Security / Privacy Event Reporting  - Consider legal obligations and ethical obligations to provide a means for Security and/or Privacy Event Reporting such as security vulnerability, or breach.

---------------------------------  Revised to add these notes ----------------------------- 

Not on the FHIR standard, because it is a bit too prescriptive for HL7. These are the highest takeaways from the past month:

1. Bad API security
1. Take initiative, hack your own API before someone else does.
2. Resource-Server MUST enforce authorization tickets, don't just trust that a valid ticket is authorizing the request being made -- 
1. OWASP -API5:2019 Broken Function Level Authorization
2. OWASP -API1:2019 Broken Object Level Authorization
3. Don't assume any level of trust, always check tokens on EVERY transaction 
4. Don't allow hardcoded API keys
5. And my personal favorite, log events AND audit the logs - OWASP -API10:2019 Insufficient Logging & Monitoring
6. Look to CyberSecurity experts, there are many. There are many tools. 
1. HITRUST.org - they do have a useful cross-reference, and are risk based.
2. Security / Privacy Event Reporting 
1. One method of advertising HOW to contact your security people -- https://securitytxt.org/
2. An alternative using DNS -- https://dnssecuritytxt.org/
3. Great community effort, including policy templates, somewhat more oriented towards researchers:   https://disclose.io/
4. Guidance from CERT on Coordinated Vulnerability Disclosure  
5. Guidance from USA Department of Homeland Security-
6. First.org guidance on MultiParty vulnerability coordination
7. ISO 27000 compliance ISO 29147/2018 and  ISO 30111/2019
8. A commercial product (Luta) maturity model for vulnerabilities  https://www.lutasecurity.com/vcmm
9. a bit on bug bounties, which can be a very useful technique, but one must have a mature baseline in place:   https://bugbountycoi.org/framework/
3. OAuth Best Practice
1. OAuth 2.0 Security Best Current Practice
2. OAuth 2.0 - Security Considerations
3. TLS Best Current Practice