IT security of the MELLODDY platform
This blog article has been written by Arne Dieckmann and Andreas H. Göller from Bayer AG
Two types of attacks and risks
Whenever you share your personal data with a platform or service (e.g. Facebook), there are at least two risks regarding data loss or exposure:
An attacker could explore and exploit technical vulnerabilities of the platform, gain access to your personal data, and steal it.
An attacker could explore and exploit publicly shared data to gain insights into your life.
In the MELLODDY project, we have very similar risks. Pharma companies upload highly sensitive data to a platform hosted in the cloud in order to train machine learning models on combined, yet not shared, data sets. Two kinds of attacks seem feasible:
An attacker could explore and exploit technical vulnerabilities of the MELLODDY platform, gain access to the pharma companies' data, and steal intellectual property.
An attacker could exploit mechanistic flaws in the way machine learning models are trained or the way data is exchanged between partners to gain insights into other companies's intellectual property or poison machine learning models.
In the first scenario, risks arise from technical flaws. In the second scenario, risks result from an unforeseen exploitation of flaws in the federated modelling approach. In the MELLODDY project, we address both types of risks. This blog post will provide some insights into preventive security measures for technical vulnerabilities. An earlier blog written by the BME Crysys Lab already considered measures to safeguard data privacy and is complementary.
Audit approach
In order to ensure IT security of the MELLODDY platform and reduce the risk of outside attacks to a minimum, we chose to have the platform audited before each yearly productive use. Our independent auditor is cirosec GmbH. The consortium works with them only for the purpose of the audit and they have no vested interest in the platform or the data. Bayer AG manages the relationship with the auditor and facilitates the coordination, planning, and information flows for each audit on behalf of the consortium.
The audit entails a conceptual review of the platform architecture, reviews of processes and code, and penetration tests. The infrastructure, application and machine learning layers are inspected, and findings are reported confidentially to the project team combined with a severity assessment. We have found that compressing the audit into a challenging two-weeks-window, followed by two weeks of bug fixing, and another week of retesting is the most efficient approach for us. Stretching the audit over a couple of months not only makes it harder to track the status quo, but it also reduces the time software engineers and scientists can change code and work on features.
Once we have received the first findings, the public partners provide some context that will help the pharma partners understand the reported risks. As the pharma partner's data and intellectual property are at stake, they will always make the final call on whether to fix a finding or not. All fixes will be subject to a retest and only if these retests are passed, the platform can be used productively. A standalone decision required to initiate a MELLODDY federated run is taken at the Stage Gate. Informed by the finalized audit reports, the pharma business leads consider the advice from their own Information Security Risk Management (ISRM) team, or equivalent, and subsequently independently vote on participation in the imminent federated run. At least six out of the ten pharma partners need to cast a favorable vote to initiate the run procedures. Having been through two productive runs, we succeeded to align all ten pharma partners their ISRM teams twice already. An accomplishment in its own right! To know more about our latest run achievement, read our year two announcement.
Last minute changes
In the first two years of the project, we found functional problems after the audit that required code changes to be fixed. Such are expected in innovative and highly experimental projects with relatively short development windows. While they are unfortunate given the preceding audit procedure, these last minute changes are needed to continue the productive use of the platform and need to happen swiftly in order to keep project timelines. To deal with such code changes, a project-internal review procedure has been put in place. Experts recruited from the pharma companies involved in the project then perform a review of the changes and sign them off if no risk is associated with them. Of course, all changes and sign offs are documented and a minimum number of reviewers and sign offs is required for the collective acceptance of the change. We think this approach is acceptable as long as the changes are small and comprehensible.
Looking forward
With the MELLODDY project coming to an end in 2022, we only have the third and last audit left. In recent discussions, we decided to keep the “crunch-time” approach as it worked well before. It seems fair to say that we are more relaxed now than in the first year of the project since we all know what to expect and how to handle the results, even if we still keep a close eye on it and security is at the heart of the MELLODDY consortium. We are also more than happy with the good working relationship with our auditor cirosec GmbH which is key in a project with shifting timelines and unexpected developments.