INFSO-RI Enabling Grids for E-sciencE Security needs in the Medical Data Manager EGEE MWSG, March 7-8 th, 2006 Ákos Frohner on behalf of Johan Montagnat

MWSG, March 7-8 th, Security in the Medical Data Manager 2 Enabling Grids for E-sciencE INFSO-RI Medical Data Security Content –Medical images (data, confidential) –Patient folder (attached metadata, very sensitive) Requirements –Patient privacy  Needs fine access control (ACLs on all data and metadata)  Needs metadata contention (metadata databases administrated by accredited staff) –Data protection  Needs data encryption (even grid sites administrators are not accredited to access the data) How important it is? –The medical community will just not use a system in which they are trustful (both a technical and a human problem).

MWSG, March 7-8 th, Security in the Medical Data Manager 3 Enabling Grids for E-sciencE INFSO-RI Medical Data Manager Objectives –Expose an standard grid interface (SRM) for medical image servers (DICOM) –Fulfill application security requirements without interfering with clinical practice DICOM server gLiteIO server SRM-DICOM interface Fireman AMGA Metadata User Interface Worker Node Hydra Key store The MDM components DICOM clients

MWSG, March 7-8 th, Security in the Medical Data Manager 4 Enabling Grids for E-sciencE INFSO-RI Features This is a “read only” kind of storage –Data are written from the hospital imagers, internally –An (authorized) grid user can only read medical data through the SRM interface –DICOM data are not stored in a raw file format: data are transformed before being sent out Privacy –Fireman provide file level ACLs –gLiteIO provide transparent access control –AMGA provides metadata secured communication and ACLs –SRM-DICOM provides on-the-fly data anonimization  It is based on the dCache implementation (SRM v1.1) Data protection –Hydra provides encryption/decryption transparently

MWSG, March 7-8 th, Security in the Medical Data Manager 5 Enabling Grids for E-sciencE INFSO-RI Medical Data Registration DICOM server Fireman AMGA Metadata Hydra Key store gLiteIO server 1. Image is acquired 2. Image is stored in DICOM server 3. glite-eds-put 3a. Image is registered (a GUID is associated) 3b. Image key is produced and registered 4. image metadata are registered

MWSG, March 7-8 th, Security in the Medical Data Manager 6 Enabling Grids for E-sciencE INFSO-RI Medical Data Retrieval DICOM server SRM-DICOM interface Fireman AMGA Metadata User Interfac e Worker Node Hydra Key store gLiteIO client 2. glite-eds- get 3. get SURL from GUID 4. request file 5. get file key 6. on-the-fly encryption and anonimyzation return encrypted file 7. get file key and decrypt file locally File ACL control Metadata ACL control Key ACL control Anonimization & encryption In-memory decryption 1. get GUID from metadata gLiteIO server

MWSG, March 7-8 th, Security in the Medical Data Manager 7 Enabling Grids for E-sciencE INFSO-RI Data replication and retrieval usecase gLiteIO server DICOM server SRM-DICOM interface Fireman User Interface Worker Node Hydra Key store gLiteIO client gLiteIO client Any SE SRM interface An y file 1. Request replication 6. Request file 2. Get SURL 3. Get file 8. Get file 4. Get file key 5. (encrypted) File replication 7. Get SURL 9. Return (encrypted) file File ACL control gLiteIO server

MWSG, March 7-8 th, Security in the Medical Data Manager 8 Enabling Grids for E-sciencE INFSO-RI The DPM + LFC based proposal LFC –As a replacement to FiReMAN. –Not interfaced with any key store: to be interfaced with hydra or Perroquet. DPM –SRM v2 implementation, will provide ACLs –ACLs are only controlling one physical replica on local site Modifications to do –Interface GFAL with encryption  The interface with hydra is planed. Timeline? –Interface the DICOM server with DPM instead of dCache  Jean-Philippe and Daniel started discussing to check how feasible it is. –Provide a coherent file-level ACL control (not just replica-level)  gLiteIO+Fireman does it. What about using gLiteIO+Fireman?

MWSG, March 7-8 th, Security in the Medical Data Manager 9 Enabling Grids for E-sciencE INFSO-RI Data replication and retrieval with DPM DICOM server DPM-based SRM-DICOM LFC (DPNS) User Interface Worker Node Key store GFAL client GFAL client Any SE DPM An y file 1. Get SURL 2. Get file 6. Get file 3. Get file key? 4. (encrypted) File replication 5. Get SURL 7. Return (encrypted) file Replica ACL control LFC (DPNS) Replica ACL control Coherency?

MWSG, March 7-8 th, Security in the Medical Data Manager 10 Enabling Grids for E-sciencE INFSO-RI Conclusions Why we would move to DPM / LFC: –Apparently DPM is more modular than dCache. In a long term we should move to such an SRM implementation. –DPM is interesting for “any biomed storage”  MDM is just an example of one particular case (DICOM servers)  Other biomed data needs encryption/access control (e.g. some bioinformatics databases). Why we would not move to DPM / LFC: –A coherent grid file-level ACL control mechanism is mandatory –Need to rework on the MDM –No interface with encryption today Questions –We try to minimize effort in the migration. Is “providing minimal support to gLiteIO/Fireman/Hydra” until GFAL/DPM/... fulfill the same functionality than what exists today a really good strategy? –What about the other way round?