-
Cyber risks of digitizing legacy systems in healthcare environments
- 2021/09/06
- 再生時間： 4 分
- ポッドキャスト
-
サマリー
あらすじ・解説
The news is full of reports of vulnerabilities discovered in medical devices. Many of them are quite terrifying. Who can forget the first time they heard that a pacemaker could be hacked — or of the data breaches resulting from these vulnerabilities or misconfigurations. Similarly, all processes involving healthcare data digitization are currently in play. Because the hospital is the playing field on which many of these processes come together, it’s the best place to start looking at some of the security implications for our secure medical data. Some of the more prevalent considerations follow. Processes that generate PHI data Many types of hospital processes generate a large amount of Protected Health Information, or PHI, data. The largest sources that generate and process PHI are Radiology, Patient Monitoring, Medication Management, Surgery, Diagnostics and (Electronic) Medical Records. Each process itself has many steps resulting in different outcomes depending on where the output of one process is used in the one that follows. Let’s look at this in a security-minded way. Mapping the flow of information between these processes can help us structure the network into compartments, noting the data handover points needed in between, such as IP addresses, ports and protocols. This will help to mitigate an attack propagated across different network sections. It also identifies the needed flows and makes sure that any further attacks can be shut down and prohibited. Assets and steps within the individual processes Here’s an example: Radiology uses a few different assets to generate medical images: Ultrasound, X-ray or MRT, and then uses a Picture Archiving and Communication System (PACS) server to store that imagery. Configuration of PACS servers is often the first trap to fall for from a security perspective. That’s because a full and secure configuration is not achieved when the asset is operating according to process requirements! Security is only achieved when all other configuration elements are checked and appropriately secured. One might think that using the PACS server to allow patients access to their medical imagery via web interface might sound like a good idea and a value-add for patients wanting to see their medical info personally. But when a PACS server connects directly to the public internet without any further configuration checks, the consequences can be severe, as recent cases have shown! In the same way, integrating an Electronic Medical Record (EMR) into self-service kiosks or websites in which patients input their data prior to a hospital visit often includes many details that are unrelated to the main operation. Also, the EMR system needs to be checked for vulnerabilities and updates regularly! An EMR can be seen as the central element of all data flows in a hospital, whether the internal flow between PACS and EMR, EMR and Medication Management or the external flow, used for insurance and billing purposes. Any and all of these connections need planning, scrutiny, and intensive monitoring. Putting things together to build a secure structure The promised benefits of digitization might benefit a single asset, a process or the hospital as a whole. Still, that promise also comes with an obligation to think through the implications of digitizing and storing health data and consider the entire security strategy and its contingencies. At the same time, we must remember the possible side effects and not stop thinking of these things when the first signs of “mission accomplished” are in sight. Even though the digitizing process works, that does not necessarily mean it is secured. Mapping out the data flow as well as checking and securing the settings of a device is a vitally important process around any mass digitization effort aimed at securing private and personal medical data. Augmenting that process with the tools needed to further tighten security will build a more secure structure able to be resilient agains...