GA4GH Data Security Work Stream
Minutes and Actions 2021-2022

These are the minutes for the GA4GH Data Security Work Stream. For further information, please visit the GA4GH Work Stream page (will link to the page on the website when it is ready) at ga4gh.org.

2017-2018 Minutes

2019-2020 Minutes

Table of Contents:

GA4GH Data Security Work Stream
Minutes and Actions 2021-2022

2017-2018 Minutes

2019-2020 Minutes

Meeting Protocols

Sub-Group Minutes and Actions Documents

List of Meetings

2021-04-16: Federated Analytics and Cloud Security

2021-02-03: DSWS @ Connect

2021-02-19: CWS APIs for supporting next generation secure workflows

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards of Professional Conduct
• Meetings may be recorded for note-taking purposes. Recordings will be deleted within three months of the meeting taking place.

Sub-Group Minutes and Actions Documents

This Work Stream has meetings for the following sub groups.

List of Meetings

2021-04-16: Federated Analytics and Cloud Security

Co-Chairs: Jean-Pierre Hubaux, David Bernick, Francesco Marino

Attendees “Name (Affiliation)”: Lindsay Smith (GA4HG), Jeremy Adams (GA4GH), Angela Page (GA4GH), Neerjah Skantharajah (GA4GH), Jaime Delgado (UPC), Shu Hui Chen (NHLBI), David Glazer (Verily), Heidi Sofia (NIH, NHGRI), Maureen Falvella, Alexander Kanitz (ELIXIR), Brian O’Connor, Xiaoqian Jiang, Denis Loginov, Jean-Pierre Hubaux, Francesco Marino, Ian Fore (NCI, NIH), Hoon Cho, Susheel Varma (HDR UK), David Bernick (Broad), Denis Yuen (OICR - Dockstore), Christina Yung (OICR + ARGO)

References:

• D. Froelicher et al. (2021).Truly Privacy-Preserving Federated Analytics for Precision Medicine with Multiparty Homomorphic Encryption;  https://www.biorxiv.org/content/10.1101/2021.02.24.432489v1.full
•  Compliance with GDPR:

J. Scheibner et al. (2021). Revolutionizing Medical Data Sharing Using Advanced Privacy-Enhancing Technologies: Technical, Legal, and Ethical Synthesis

https://www.jmir.org/2021/2/e25120/

• MedCo Roadmap: https://medco.epfl.ch/roadmap/

Minutes:

JPH: Discussed this topic in previous meetings, so won’t repeat here but quickly go over the slides. Emphasis on a more precise threat model. Bulk of the discussion can be summarized on the tree slide. Would like to hear from the WS and DPs on their position.

Essentially, when there is a willingness to carry out decentralized analytics, there can be hardware- or software-based solutions. Hardware solutions are vendor locked-in and are vulnerable to side channel attacks. Not the best approach. Software base solutions include vanilla federated learning, processing data locally and providing/sending the partial results to a central point unprotected. Considered to be insecure. The protection of the partial aggregates can be either realized by adding some noise to fulfill the constraints or protecting the partial aggregates by appropriate cryptographic methods. Noise results in precision loss. Solution based on crypto can go through HE (scalability issues) or SMC (communication overhead). Most promising option is HE + SMC. Both HE and SMC are well-known techniques, but only recently have they become useful and operational. Would be nice to hear from attendees on the call how they position themselves with respect to this tree, and to what extent they share this analysis.

IF: How does https map to the three crypto methods shown.

DB: Software-based solution.

JPH: TLS protocol that provides end-to-end protection from a eavesdropped. Does not protect data while being processed, only in transit.

IF: What’s in the partial aggregate that needs protection?

JPH: If we assume everyone to be honest, then we don’t need data security. The purpose is to address the fact of assuming that people won’t misuse aggregates.

AK: This HE, does this rely on software, the software just needs to rely on this and it works. My understanding is that the software has to decrypt the data.

JPH: HE, it is possible to carry out actions while the data is encrypted.

AK: I don’t need to use special software? Just use regular software as if the data was not encrypted.

JPH: Yes, but it’s a little more complicated than just plugging it in. Non-trivial effort to convert a logistic regression and make it under encryption.

AK: From an user this is an important point, can I still use all of my software.

JPH: Would be happy to discuss this with you in detail and take a closer look at the options you want to do. Researchers seem to be happy with the relatively simple operations at the start. If sophisticated computations have to happen, might still make sense in some cases to  centralize the data, but more the exception than the rule.

AK: Scalability issues?

JPH: We took the same data, was done with all data in clear text, centralized (from linked paper). It is possible to find almost the same results, with realy minor differences, by making the same computations. Arbitrarily split the data in three chunks, shown it is possible to get the same results. Enormous progress has been made with speed and optimization.

IF: How does the GWAS done in this compare with the GWAS done as part of the FASP. In that situation, that whole package of data was sent to the 4 nodes.

BOC: GWAS was open data, 1k genomes data.

JPH: Not familiar enough with that work

BOC: I will dig it up and follow up with you offline.

        https://github.com/DNAstack/plenary-resources-2020 is the workflow we used…

AK: From ELIXIR, would like to go the other way around and take the workflow you have and run on our federated infrastructure. We have WES and TES in place. We could stand up across ELIXIR different compute backends to run this data or deploy backends where the data are already. Run on GA4GH cloud infrastructure.

JPH: Happy to help with this.

AK: Who to reach out to about the workflow? Will have more questions on this.

JPH: Write to me and I can make the connections.

DG: This paper shows impressive progress in running a GWAS, do you have any sense of the next analyses, 2, 3, 4?

JPH: This is a survival curve, in the same paper. GWAS is number 2. An exciting exercise to characterize the families and see the cost. Things are moving quickly. What is missing is the ability to access the data. GA4GH should try to leverage all of this work done in CS and integrate it in an appropriate way. Just a matter of identifying places where this is going to be the least painful and where there is the most motivation. Suggest  spending some time reading the papers and experiment with software.

BOC: If you’re an algorithm developer, are there libraries you can use to abstract these, or do you have to be familiar with HE to adopt. How much abstraction is there for the implementer?

JPH: Wish is to have compilers for automation, but this is in its infancy so cannot rely too much on this. Not going to happen soon. Going to be more in the identification of families for which references will be provided, adapted to things with the same nature. Would also expect some companies will provide this service.

DG: Haven’t seen data sharing as the issue in the pandemic, the collection was messy. Zooming out one step and thinking about where GA4GH can best invest. Building on Heidi’s chat comment about trade offs in investing in more trust. You get to say how much you trust the people, the data and the tools. People - How hard to you make it for people to get access, training, etc. Data - trust the things in your tree, de identification. Tools - includes everything here, also things like barrier around data, monitoring what people are doing. All of these have tradeoffs. Makes sense for us wherever we see a return, provide a framework to think about all of this. Many people don’t know enough to think about opening up the silos. 5 SAFEs framework seems to be in the right direction. In that framework, pushing for the crypto-based viable tools is good thing to push on, but can’t be the only thing we push on.

JPH: Crypto won’t solve all of the problems, governance is crucial. If it were the case that people knew about the infrastructure to make data sharing smooth, I think this would tremendous progress. Willingness to have this awareness of availability of tools will allow more accurate data collection.

IF: Some of the implications if we’re thinking about the Cloud standards. How does a WES server resolve a DRS id. In the examples, have to find out where the data is and send your compute. We need to understand these things at a strategic level. How will WES use passports to access DRS data. Are the things here so fundamental that they will drive what's important at the tactical level.

JPH: GA4GH is an alliance, aims at facilitating data sharing in a way that is compliant and respectful of legislations, including those that are the most stringent. Legislation is becoming tighter. This brought on the GDPR, which is becoming an international standard beyond the EU boundaries. Technology makes it possible to respond to these things.

DG: It’s a question of where it fits in the portfolio of efforts and who does what. Roughly, its the tipping point between R and D. In the past, this was a research project. In the future, will be a critical piece of operational technology. At the tipping point, no one is quite sure if we’re talking 1 or 10 year time frame. How do we deal with the uncertainty of how quickly it will become worth the investment.

DB: The VA in the US will not let anyone see their data or share it but want people to compute against it. SMC enables this. Hospitals have the same issue.

DG: That focus on the data owners, they are a key stakeholder in moving forward. They have the keys. Working with particular data owners who have valuable datasets and ask them how we can make their silo less of a silo.

JPH: One has to convince people of the approach, it’s relatively new. Phase of evangelization that needs to take place. Be pragmatic with a small example that matters to GA4GH. Investigate how to port existing computations to decentralized and encrypted. Need 2-3 examples from DPs. Will talk with Alexander and ELIXIR.

XJ: From biomedical perspective, it’s a big challenge. If we can break the hurdle of data security and allow encryption and computation on the fly, we will be much more nimble. Would like to integrate solutions in to a platform. I like the tree structure a lot. Issue I’m seeing is different assumptions in security standards.

JPH: Tell us about the IRB.

XJ: Cross institutional IRB can take a very long time. Multiple institutions involved, waiting until things get approved.

Comment in message from Brian O (Cloud): "I have to drop early but one question I have here is what changes are needed to Cloud APIs to accommodate?  Is that too early (perhaps?). Or are there blockers there?"

JPH: What we are talking about should be more or less transparent to cloud APIs. Run underneath. Haven’t done a thorough analysis so it may be a bit too early. Not a big deal at this stage.

IF [in chat]: Brian and Heidi - what I’m hearing, and I’m extrapolating from David’s comments, is that we can continue to some extent as at present, but with a weather eye on developments. I don’t think we have the right sense (metric ;-) of how close to the tipping point.

HS [in chat]: Tipping point could be soon.

2021-02-03: DSWS @ Connect

Please find meeting material from GA4GH Virtual Connect here.

2021-02-19: CWS APIs for supporting next generation secure workflows

Co-Chairs: Jean-Pierre Hubaux , David Bernick 

Attendees “Name (Affiliation)”: Francesco Marino, Lindsay Smith (GA4HG), Jeremy Adams (GA4GH), Anders Leung (GA4GH), Kyle Ellrott, Alexander Senf, Justin Clark-Casey (EMBL-EBI), Jordi Rambla (EGA+Beacon), Denis Yuen (OICR - Dockstore), Ania Niewielska (EMBL-EBI), Kyle Vernest (Broad), José Mª Fernández (BSC / ELIXIR-ES), Dmitry Repchevsky (BSC / ELIXIR-ES), Michael Lukowski (U Chicago), Jiaqi Liu (UChicago), Jaime Delgado (UPC), Anne Deslattes Mays (Science and Technology Consulting LLC), David Glazer (Verily), Binam Bajracharya(UChicago), Brian O'Connor (Broad), Dina Mikdadi (Deloitte), Heidi Sofia (NIH, NHGRI), Christina Yung (OICR + ARGO), Alexandru Lepsa (OICR + ARGO), Susheel Varma (HDR UK), Shaikh Rashid (CanDIG - UHN), Thomas Schaffter (Sage Bionetworks), Bruce Hoff (Sage Bionetworks), Ben Busby (DNAnexus), Pierre-Olivier, Jonathan Tedds, Ruchi Munshi, Jordi Rambla (CRG), Eric Perlman, Aaron Kemp, Randy Olinger, Andre Paredes, Laia Codó, Michael Crusoe

Minutes:

FM: Last plenary had a meeting between CWS and DSWS to support APIs for next gen workflows.

How things are done now - researcher wants to run a workflow and asks an execution service. Execution platforms need access to data, which may be sensitive. Mapping to GA4GH - TRS, WES and DRS, sensitive data is still exposed. Can impact quality of workflow results. There are many potential datasets that the researcher cannot access.

How things will be done next - all components are distributed, including the platform, tools and datasets. Will be able to run workflow on a larger amount of datasets. Workflows will be strictly coupled. Do not need access to data in clear.

TRS - Will have to change to deal with distributed tools, will have to provide information on how to deploy tools on a node and how data should be formatted/encrypted/stored for workflow to work correctly

WES - will have to deal with new federation. WES servers will organize themselves in multiple overlapping federation to constitute just as many distributed execution platforms. Each WES server will manage a portion of data contained in the platform and may serve as entrypoint to run workflows on the whole platform. This will require APIs to manage federation (enroll, leave, user permission, etc.)

DRS - Won’t be enough to provide URL. DRS will provide information about data repository that, while not being directly accessible, can still be queried and analyzed aby the user.

How things will be done with CWS APIs - researcher chooses tool with TRS. DRS says it is possible to run the tool on the three datasets. Researcher can trigger a process of enrollment using information from DRS about the tool. By using the new WES federation APIs, can join the distributed platform. Can jointly run and return a meaningful result.

JP: Talking about privacy-conscious decentralized analytics. One solution is to go for hardware based approaches. Most prominent is Intel SGX, trusting the hardware to provide enclaves in which computation takes place. Drawbacks are the vendor lock in and side channel attacks. So, many people are trying to come up with a solution that is software-based. Two options, one is vanilla federated learning (insecure) and the other is protection of partial aggregates - Results are aggregated, and hope is that this does not leak to much information. Partial aggregates need to be protected. Could add noise, but drawback leads to precision loss. Other option is to protect by crypto (HE + SMC), but this leads to scalability issues. Could combine all of these for the most promising solution.

We have explored some of the tools based on a certain number of criteria for privacy preserving data analytics [see table on slides].

Conclusions: Moving to decentralized architecture that is highly relevant to both work streams. We believe the API can and should evolve to follow this trend. Encourage collaboration to continue.

Q/ What is the threat model?

JP: There is no single answer to this, vary from one case to next. Essentially two things: 1) Make sure that the data themselves are protected, and 2) attacks against partial aggregates are going to fail. Cap the amount of info that can be extracted by a researcher. One has to make a non-collusion assumption.

KR: Seem to be attempting to address side channel attacks, assumption that all legitimate user are cooperative and security conscious.

DB: While we want people to share data, a solution for very sensitive data is that two parties don’t actually want to share but want to compute against each other’s data, so how do you do that. Two enclaves that want to stay enclaves, and being able to collaborate in a way that doesn’t open up enclaves. Premier use of this kind of stuff.

KR: Premise that needs to be established

JP: Assumption have to made that there isn’t a deliberate willingness to pollute outcomes, ie. doctored data leading to inappropriate results.

Q/ How many driver projects are running into this scenario of sharing distributed compute?

JP: Potentially all of them if within GDPR framework. Pilot with SPHN. Kind of model they want to work with. When we talk with US colleagues, consider this to be overkill.

DB: Even if we are using US cloud that we trust, this kind of stuff will allow us to use with EU entities.

BOC: Makes sense for a small number of datasets, but sounds like it will be widely used. Makes an argument for it being as streamlined as possible. Potential resistance to docker everything, register it, burden of having it endorsed and cryptographically signed. How to make this streamlined as possible.

DB: National level biobanks are going to become more common. Each country will have its own privacy rules. Make a blanket statement that says “use the protocols”, that could be a win.

BOC: What is helpful is taking those examples from drivers and having a clear use case written up.

DB: Addressing Susheel’s point, must protect the data with certain kinds of encryption even if pseudo-anonymous.

SV: We have researchers trying to do this at scale. We want to roll out tech as new legislation, but we need to get data to researchers as quickly as possible. There is mileage with this, but what can we do today. Phased approach.

JP: We have to see where the impetus will come from. This is part of the agenda of the DSWS. Purpose of this meeting is to see what the implications are for other WSs.

SV: Explicitly state that full anonymization isn’t possible. Trying to minimize risk, and that residual risk is what we need to understand and manage. Appetite for risk with change based on projects and data. Next actions - expand out what the threat models are, what the maturity is, and see how this can be connected with other GA4GH standards.

BOC: It would be helpful on CWS side if we had 1-3 DP use cases written. That would be the immediate next step from my perspective. Why needed and how it would work at a high level. Who is driving it. If we take back the high-level design and implement I don’t think we will be as successful as a joint pull request.

JP: Who would be the most motivated DPs?

BOC: TopMed and Biodata Catalyst (the platform), have the same use case. Sensitive dataset and want to sign and approve workflows.

Other Drivers? ICGC-ARGO.

CY: Need multiple data processing centers across regions. Some data cannot leave that region. Use same workflows across all centers. In other cases the data can move around for processing, so will need a strict registry to tell us where data can move to and where it can’t.

Other scenario is with germline data hosted in specific jurisdiction. We want users to query but not at the individual level.

BOC: Sounds like the second one brings together Search/Discovery aspects.

CY: Can be solved by data shield at the moment, but haven’t implemented.

JP: Data shield leverages adding noise of partial aggregates. Either you don’t put noise and have no protection, or accept noise and losing precision.

JP: The tree captures the story, and position solutions on one of the leaves.

JR: If someone could go to federated EGA meetings and explain the differences and reasoning, we can see the sensitivity of the nodes to have this implemented. Related to the network you mentioned, understanding the requirements of the network will be helpful for the Discovery work steam. This level of deep understanding needs to go to potential users.

JP: Not an easy topic and goes across disciplines. By seeing how difficult it was to communicate, we produced this paper (https://arxiv.org/abs/2010.14445) to help bioinformaticians, geneticists and lawyers to understand. More than willing to be on calls with groups you mentioned.

BOC: When do these required that all API implementations support these, and are supported by implementations that require this functionality. The more complexity we add, potentially we’re making it harder for people to use APIs for data sources or platforms that don’t require the extra level of trust. How to serve both communities.

JP: Remin pragmatic. Avoid security layers where not needed. There has been a push in EU for legislation around data protection, especially in medical field. At some point, the question is what can be done. There is so much reliance in medical field on legal agreements. We are reaching the tipping point of the techniques mentioned, becoming more usable. Have to be cautious to not be a burden on researchers. Set up a proof of concept and experiment. Iterative process.

Chat Transcript:

00:18:35        David Glazer:        I have no SHORT questions :)

00:21:52        Kurt W. Rodarmer:        I may have missed it, but what is the threat model here?

00:24:14        Heidi Sofia:        In the taxonomy maybe there could be another branch for synthetic data for exploration by those with less privileged access. Researchers do not like differential privacy because it takes something away but synthetic data allows them to get access they otherwise would not have

00:24:30        Susheel Varma:        Isn’t there a simpler approach to have TRS API have signed attestations that have been verified to do the right thing (including dependency chains) within an environment? Yes it is hard to scale, but easy to get started while we wait for PET technology maturity

00:25:23        Anne Deslattes Mays:        Very nice presentation - thank you!   I will need to sign off but I will pass on these details with the parties I am working with.   I think this hits a very important topic.

00:28:55        David Glazer:        @Heidi -- I agree synthetic data is part of the taxonomy. It probably has very similar power/protection tradeoffs to fuzzing the data, but agree the optics are very different.

00:30:22        David Glazer:        Yes please to listing the problems we want to solve -- I think what DB described is a real one; there are other adjacent ones.

00:30:47        David Glazer:        (And some of them are much more solvable than others, which will lead to a phased approach.)

00:31:39        Jonathan Tedds:        Datashield is designed specifically with David B's scenario in mind

00:33:19        Jonathan Tedds:        http://www.datashield.ac.uk/

00:35:12        David Glazer:        I have to drop off -- I suggest the next step is identifying a handful of different use cases, capturing the driver project need (how many how soon) for it, and breaking the possible solutions done by use case.

00:35:15        Susheel Varma:        UK Biobank and others combine weak anonymity with access control, whether requiring the researcher to visit a secure site or requiring licensing incorporating a nondisclosure agreement plus access and use controls that forbid any attempt at identifying subjects.

00:36:03        David Bernick:        https://github.com/hhcho/secure-gwas is the (old) open source code for broad’s SMC-gwas

00:36:23        Susheel Varma:        Regardless of technology, what is important is be able to apply inference control using statistical disclosure control issues

00:40:59        Heidi Sofia:        Of course the risk of impeding biomedical research without serious slowing the bad people is another risk to balance

00:45:42        Heidi Sofia:        There are other NIH groups that have built VA relationships but these are not currently GA4GH Driver projects

00:50:20        Susheel Varma:        HDR UK does have an interest in this Cloud + Security space and are actively monitoring it. We have built up capabilities across all four nations in the UK. Our acute need is cohort discovery which combines Discovery + Cloud APIs and the ability to apply inference control on aggregate data at least as the first step to make a data access request

00:51:56        Brian O (desktop):        Ya, I agree to what you’re saying here Heidi.  It’s been difficult to get WES, TRS, DRS setup and people using them.  So we have to be careful to not require additional layers of trust unless it’s required for the dataset/platform.  Otherwise I’m concerned that it would slow adoption further.

00:54:56        Heidi Sofia:        We should look for low hanging fruit that improves access and present as a benefit to the community.

00:55:20        Susheel Varma:        @Jordi - DataShield is great if you analysis is limited to summary statistics using verified R functions - Great for epidemiologists. They do have more advanced approaches but the data and compute needs to be right shape. Not just throw a docker container on a dataset and pray :)

00:56:10        David Bernick:        strong aree heidi!

00:56:12        David Bernick:        agree

00:58:35        Susheel Varma:        @Heidi - Agree. Is there also a public and patient angle here. It may be important to make sure they understand that all research will have residual risk and it is important how we articulate how we as infrastructure developers and researchers manage this risk using a combination of people, process and not just technology <— Not a silver bullet

01:00:12        Heidi Sofia:        Just to be clear I am enthusiastic about these technologies and their potential. This is in the growing realm of “sociotechnical” which really requires deep integration across domains

01:01:11        Heidi Sofia:        Yes, work to be done!

01:02:26        Susheel Varma:        Thanks Jean-Pierre and team!!

01:02:38        Susheel Varma:        This is exactly the discussions we need to have

01:02:40        Brian O (desktop):        Sounds great!  Looking forward to diving into this more during Connect!

01:02:57        Thomas Schaffter:        Thanks!