MEDICAL DATA IN THE CLOUD

DEAN WICKS

CONTENT

INTRODUCTION

IS THE CLOUD RIGHT FOR WHAT I AM DOING?

UNDERSTANDING WHERE YOUR DATA IS

UNDERSTANDING HOW YOUR DATA IS SECURED

UNDERSTANDING HOW YOUR DATA IS BACKED UP

IS THE WAY THAT MY DATA IS STORED LEGAL AND COMPLIANT?

ARCHIVING AND INTEGRATION

WHAT ABOUT OTHER APPLICATIONS AND SERVICES?

SOME MEDICAL ORGANISATIONS ALSO USE BESPOKE MEDICAL MESSAGING APPLICATIONS

ARE SOLUTIONS BUILT AND DEPLOYED IN LINE WITH BEST PRACTICE?

UNDERSTANDING HOW PEOPLE WILL INTERACT WITH MY CLOUD SERVICES

PROTECTIVE MONITORING

PATCHING AND SUPPORT

TESTING AND VALIDATION

SUMMARY

4

5

6

7

7

8

10

11

12

13

14

15

15

15

16

INTRODUCTION

The perceptions regarding the use of the cloud have changed dramatically in recent years. What was once seen as a high-risk area is now being embraced by all types of businesses and government organisations globally.

There is a massive shift from in house enterprise solutions and bespoke applications to the convenience and cost-effective solutions offered by cloud providers. The ability to let someone else with the resources of Amazon Web Services (AWS) or Microsoft to provide you a scalable, business resilient solution is appealing but can be fraught with complexity and pit falls to the uninitiated and non-technical. This can

be exacerbated when seeking to use the cloud for medical purposes with the extra legal and regulatory compliance required.

This short whitepaper aims to clarify some of the potential issues that any medical organisation will face when using the cloud for medical data storage and information processing.

4 |

The very first question you must ask and answer honestly is whether the cloud is right for you and your organisation. Yes, it is generally cheaper than running your own IT network and comes with scalability and business continuity benefits, but it isn’t for everyone and everything. The context of your medical organisation may mean that a cloud solution isn’t the

right option. Understanding the difference between public, private and hybrid clouds along with how different components could be deployed in different solutions, will help shape your decision making. For example, you could use the private cloud for all your enterprise services but have all archiving of medical records in a private cloud repository.

IS THE CLOUD RIGHT FOR WHAT I AM DOING?

5 |

UNDERSTANDING WHERE YOUR DATA IS

The basics of specifying where your data is stored from a geographical perspective will go some way to ensuring you meet any off-shoring legislation. It does not mean that your data will always be processed in that location though. Using Microsoft’s Office 365 as an example, if you were to specify an on-premises private cloud Office 365 tenant, some of the cloud applications are

not available for on-premises deployment. This means that whenever your staff use one of these applications, the processing is still taking place in data centres other than your own and often outside of your preferred geographical region. Understanding where your medical data is stored and processed is the key to securing it.

The cloud, contrary to myth, is not an unmanaged and unquantifiable space. It can be defined and can be carefully specified and built to give you full control of exactly where and how your data is stored.

6 |

Once you know where all your data is and where it is being processed, you can begin the process of securing it. Basic encryption offered within AWS S3 Buckets and Azure Blob storage should be seen as the starting point but not the complete solution. It should be bolstered by service encryption and customer managed keys.

Encryption can be a minefield of terminology, but generally ensuring compliance with FIPS140-2 and being 256 bit as a minimum is a good starting point. As any cyber security expert will tell you, encryption and technical controls are only one piece of the puzzle. People and processes

have to be also be considered. The traditional information security concepts remain as valid as ever when using the cloud.

Some medical organisations have used the process of making patient data pseudonymous before storing it in the cloud. This is a way of obfuscating the identity of the subject of the physiological data by removing their patient identifiable information (name, date of birth, etc.) and replacing it with a serial number or barcode that can be used to recover the data at a later point. This supports both the security of the patient data and supports legal and regulatory compliance.

Understanding where your data is backed up, is as important as understanding your primary storage location. By default, both AWS and Azure will carry out backups by region unless specified and managed otherwise. This can mean that for an EMEA instance, the data could be backed up in data centres anywhere in Europe, the Middle

East or Africa. That’s a large area and would require some off-shoring risk to be accepted for medical and special category data. In the case of special category data, this off shoring may lead to non-compliance with medical legal and regulatory governance which may be a show stopper.

UNDERSTANDING HOW YOUR DATA IS SECURED

UNDERSTANDING HOW YOUR DATA IS BACKED UP

7 |

IS THE WAY THAT MY DATA IS STORED LEGAL AND COMPLIANT?

In the medical profession there are more layers of governance and regulatory compliance than in most other sectors. The usual data protection rules determined by the Data Protection Act (DPA) and General Data Protection Regulation (GDPR) apply. Special category data will no doubt be included in medical data sets adding further compliance needs.

This is all without considering the medical specific rules such as the Caldicott Principles and patient confidentiality requirements. The Caldicott Principles clearly state

that access to medical information is to be on a strict need to know basis. This applies to information in digital form, stored in the cloud as much as does to any other patient record. Ensuring that the principle of least privilege is applied to cloud medical data is the ideal starting point to demonstrating legal and regulatory compliance.

Medical organisations not only need to consider the laws and regulations for the country of origin of the medical data, but also those of the country where the data is being stored and processed.

8 |

An often misunderstood element of legal and regulatory compliance is the notion that both AWS and Azure are compliant, therefore so am I. This is not the case. Both AWS and Azure document how they are compliant with a great number of certifications including many medical related ones such as ISO27018 (Personal Data Protection), HIPAA (Protected Health Information), HITRUST (Health Information Trust Alliance Common Security Framework) and more. The key is that they are compliant, not you. However, both AWS and Azure

have done the groundwork to allow your organisation to be compliant with these and many other information security standards. It all hinges on ensuring your solution is deployed in the right way to inherit this compliance by meeting your customer obligations. Some of these obligations are related to securely designed solutions, other relate to the need for documented policies and processes that must be adopted across your organisation. Again, using the cloud does not negate the need for good information security fundamentals.

A Cloud Access Security Broker (CASB) can help and advise on how to secure your cloud services. They may also offer a service that deploys your cloud instance for you and in some cases, manages it for you. Be wary of CASBs though. There are

a lot on non-reputable ones that simply deploy services for you but don’t bespoke those deployments for an organisation’s specific security needs. Do your research before employing a CASB.

9 |

Any new cloud solution that generates information that will contribute to a patient’s medical record must either have its own archiving system (not to be confused with data backups) or integration into an existing one. If local policy dictates that only the existing repository is to be the single archiving service, then integration to

that archiving service must be considered during the development of the cloud solution, leaving it until after you’ve deployed your cloud service could lead to costly re-workings. The responsibility for that integration cannot be passed to the cloud service provider and must be resourced by the medical organisation.

ARCHIVING AND INTEGRATION

It’s very likely that most medical organisations will have an existing archiving system for medical records. If this is typical of the industry, it will be a large on premises data centre with a historic archive of hard copy files in a traditional library.

10 |

WHAT ABOUT OTHER APPLICATIONS AND SERVICES?

11 |

Most of what has been written in this paper relates to the storage of medical data, but there are many other services that must be considered. Where medical modalities used to be dumb devices capable of only one primary use, they now come with enhanced functionality and networking.

As an example, should your organisation be in the market for a new Ultrasound (or any medical device), you will be acutely aware that most now come with data storage for images, exportable imagery, USB ports, networking through Wi-Fi, Bluetooth and Ethernet cable plus much more. Dumb devices just don’t exist anymore. Some also come with the ability to transmit Digital Imaging and Communication in Medicine (DICOM) format data to a specified PACS server over

multiple networking options and bearers. Others bring their own bespoke cloud service and associated applications - both web applications and on client applications. While this enhanced functionality brings significant medical benefits, it also brings data and cloud security to the forefront. Your organisation is responsible for the data generated on these devices, its protection in transit, its storage in the cloud and its retention, archiving and deletion. Just because you don’t provide the service, doesn’t mean you are not responsible.

Integration with your other services and existing cloud solutions is vital (along with, of course, your existing archiving service). This will all need to be resolved in a secure, legal and regulatory compliant way.

SOME MEDICAL ORGANISATIONS ALSO USE BESPOKE MEDICAL MESSAGING APPLICATIONS

These are a great leap forward from the dark days of hospitals communicating in a non-legal way using apps such as WhatsApp. These bespoke medical messaging applications are often cloud based and accessed through a personal device. Considerations must be made for how data is stored and protected in these cloud applications as much as it must in a medical enterprise network. If a discussion is had on the medical messaging

application that leads to a clinical decision being made, there must be a way of archiving that decision and the information leading up to it. If relating to a clinical decision it will need to go into the existing medical record archiving system. Again, early integration consideration is the key to success and not finding all your clinical decisions are stuck in an application without a method of archiving them.

12 |

There are many standards and documented methodologies for how to deploy a cloud solution. As in any industry, some are better than others. Following a best practice solution relating to your chosen cloud service provider is a good starting point, such as the AWS Well Architected Framework or equivalent from Microsoft and

Google. This should only be a starting point though and should be bolstered by wider best practice (NCSC Cloud Security Principles, Cloud Security Alliance, etc.) and if available, industry specific guidance such as HIPAA or HITRUST. Simply doing it in house as a best effort will not be good enough for a medical organisation.

ARE SOLUTIONS BUILT AND DEPLOYED IN LINE WITH BEST PRACTICE?

13 |

UNDERSTANDING HOW PEOPLE WILL INTERACT WITH MY CLOUD SERVICES

14 |

A balance needs to be made between the medical needs of users and the security of the system. For medical devices that have a cloud service associated, it may be necessary to access the device without logging on in order to provide emergency time critical treatment. In the case of these devices, it should be possible to configure them to disable the cloud service for emergency unlogged on use. Whenever being used in cloud connected state, a normal log on must be applied. Some systems incorporate a way of anonymising patient data. They allow users to conduct medical monitoring but will not allow the inputting of patient identifiable information without the user being logged on. Replicating this technology for restricting access to cloud services is easily achievable.

An understanding is required of how routine users will connect to the cloud for all their services, and the necessary bandwidth and connectivity options be put

in place. For example, will users access the cloud service via the internet or through a corporate provided network access? The scale and bandwidth of corporate network access will need to be proportionate to the extra network utilisation of a cloud service. Some medical facilities will have areas that restrict the use of Radio Frequency (RF) emitting devices. This will need to be considered if you intend users to access cloud services over Wi-Fi, 3G or LTE.

The secure cloud deployment will easily be compromised by bad practices from users. All the technical controls in the world cannot protect the system from a user sticking their password to their device. Robust but proportionate policies and procedures that are effectively communicated to staff will still help here, as well training and educating staff in both basic cloud technology but also in basic cyber security.

PROTECTIVE MONITORINGWho is doing it? All the major cloud service providers offer well established protective monitoring solutions. Whether AWS’ CloudWatch, WatchGuard, MACIE or Microsoft’s MCAS, MIP, Office ATP and Azure ATP, these are all mature and high-quality products. They are however reliant on some human interaction to react to events and alerts. An organisation

cannot simply turn this functionality on and expect their cloud services to be protected. There is a need to have dedicated staff who are appropriately trained in the protective monitoring systems and with some medical background or knowledge, to be able to prioritise and manage responses appropriately without increasing a risk to life.

PATCHING AND SUPPORT

TESTING AND VALIDATION

Depending on whether you have specified Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) will determine who is responsible for patching and support. For a larger scale enterprise, it is not uncommon for SaaS, PaaS and IaaS to all be used on different elements of the enterprise. Just because

patching is carried out by your cloud vendor doesn’t negate the need for compatibility and assurance testing with your other applications and services. Understanding the state of the entire enterprise is still your responsibility although the large cloud providers offer tools that make attaining this information far easier.

15 |

Another misconception is that cloud deployments cannot be penetration tested as per a normal enterprise. This is not the case. Both AWS and Azure have processes in place to support penetration testing of individual

deployments. They do require notice and you must request the correct permission before conducting testing, but both recognise that penetration testing and validation is a key security tool.

SUMMARY

16 |

Using the cloud for medical data storage and processing offers significant benefits to any medical organisation. It allows for medical personnel to access and collaborate on information in ways not previously possible and is improving healthcare delivery globally. From simplistic cloud hosted virtual consultations to AI and machine learning analysing big data in ways humans simple cannot, the cloud is being ever more successfully exploited by the medical industry.

It is not without its pitfalls though and as stated within this paper, the first steps are understanding where your medical data assets are being stored and processed, along with understanding your legal and regulatory compliance requirements. Once these hurdles are scoped and fully understood can medical organisations get on with the process of building and deploying in the cloud just like any other industry.

SA Group is a Cyber Security, P3M and Technical consultancy working in vital and highly complex Public Sector and Commercial markets. We specialise in helping clients in technical and digital environments scope and deliver against their complex challenges.

| 03333 583340| info@sa-group.com| www.sa-group.com

ABOUT THE AUTHOR

Dean Wicks is a cloud security practitioner who has supported the deployment of multiple medical systems into public cloud hosting. Dean has advised and supported both HMG and commercial service providers on how best to deploy, manage and support their medical cloud solutions. Prior to specialising in this field, Dean brings a wealth of knowledge from a 20+ year career in information security, assurance, cyber and communication planning.

17 |