GA4GH 2020 Gap Analysis

Data Security Team

Useful Links

Overall Themes

  • Alignment with external standards
  • Increased GA4GH-wide interoperability
  • Practical implementations
  • Reduce barriers to participation

Data Security Specific Points

  • GA4GH needs to help broker a set of rules that everyone can adopt around policy, security, and technology alignment
  • Organizations considering adoption of the Data Privacy and Security Policy (DSIP) need:
  • clarity on the minimum requirements versus best practices;
  • a transparency checklist or self-assessment tool;
  • a list of companies/organizations meeting the DSIP requirements *Too add
  • associated costs for implementing components of the DSIP *Too add
  • Eventually asymmetric encryption will need to be replaced by more advanced quantum computer resistant cryptography. However, we cannot go faster than the needs of the community
  • Issue is future decryption of copied data
  • Need to keep in mind for the future
  • There is uncertainty over data sharing agreements, given the rapidly evolving patient privacy standards
  • REWS is exploring a strategy for data licencing inc ownership, downstream IP, credit.
  • Cross WS project
  • JP: diversity of patient consent.  Machine readable, systematic consent would help.
  • Adrian: Regulatory frameworks.  Machine readable consent initiative has begun which aligns with DUO.  Not prescriptive around consent model.  Consent harmonization group.
  • David: a lot of regulatory frameworks which mostly align, but with important differences.  Should be compared and make a stance statement
  • Edward: there is more similarity than not.  The trouble is moving from principles to standards.
  • David: Crosswalks as a potential method for this.
  • GA4GH needs to provide better implementation support, particularly in the area of security audit
  • JP: Agree!  Can be time consuming and complicated done by a team of specialists.  GA4GH does not have the resources to provide this.  Instead, we provide feedback on standards.
  • Craig: Is it possible to have a framework where the expectations/recs would indicate what level of audit would be appropriate based on the types of activities?
  • JP: finding vulnerabilities in implementations could be very time consuming.  Would have to be case by case
  • David: https://developers.facebook.com/docs/workplace/third-party-apps/security-review/ facebook’s version of this.  Trying to get an FTE from a U24 grant.  Already listed in the roadmap.  Milestone one is to give people self assessment tools, step 3 is to have something in place to do it.
  • The Cloud Work Stream is not fully aware of how TRS would apply the GA4GH Passports and standard OIDC protocols. It is unclear where responsibilities for integration and interoperability lie
  • Brian: TRS was intended to be a public registry but people want to share private workflows.  It hasn’t required the ability to lock things down.  How to leverage passports with all of our APIs.  What FASP is down now is how to use passports with DRS and WES.  Maybe this is not really a gap.
  • Craig: As we get further into FASP and talk more about how passports can be used for auth, need more understanding of how to use passports securely.  Need security requirements as auth is layered into the system.
  • Get Data Security more involved in FASP.
  • There is a lack of Driver Project participation in DSWS; we need to identify data security experts within DPs and generate excitement
  • Email melissa.konopko@ga4gh.org to sign up!
  • Create starter packs to get teams involved
  • David: NHLBI/ NHGRI have been interested and may need some outreach
  • Ian Fore: of NCI, we have people on our team who should be knowledgeable about this.  Will contact them to have them get more involved.
  • Jordi: EGA: interested as a DP.  ELIXIR Beacon: also interested in this.  Beacon API spec: planning to get more involved in Beacon and include more security by design
  • Kurt: NCBI would like to contribute