In my last post, I talked a bit about the cybersecurity challenges around medical devices.
In this post, I want to tell you a bit about the process of device cybersecurity analysis, with a look first into the mindset involved in inspecting a device, and then the process of the assessment itself.
First and foremost, the assessment mindset revolves around finding and accounting for anything that can be circumvented or exploited. For example, could the device leak information unknowingly? Which components are susceptible?
Keep in mind there are numerous physical and software components to check, from the UI and OS to the boards, the ports, the applications, and so forth.
That doesn’t mean that all of these components *will* be exploited, but understanding the complete risk profile will help you understand if you need to make any modifications or build alternate controls to secure the device.
The amount and depth of information provided by the client determines the classification of the analysis. Each level of information provided can lead to a different set of insights and recommendations.
For example, if the client provides all the relevant information: schematics, code, debug tools, the different bills of material (BOM), that’s known as a “white box” analysis. If the client provides nothing (or there isn’t any client) – it’s known as a “black box” analysis.
In our specific case, we went online to find what documentation we could on the patient monitor. We found some repair manuals, some other relevant information from an account on the manufacturer’s customer portal, and device software. So perhaps given the partial information we got, this could be considered more of a “grey box” analysis, somewhere between white box and black box.
Physical – Once the background information is gathered and reviewed, the actual analysis starts with examining the physical characteristics of the device, looking for features, ports, assembly insights.
Software – Then the device is turned on and booted up to check the UI, how the software and applications work, check any menus for commands, and what can be done with or without authentication. At this stage, the analyst will typically try getting root access to the system, see if they can trip up the software, see whether security controls can be circumvented.
Communications – The next step is to check the data communications of the device, inspecting any radio signals (such as WiFi or Bluetooth), or the data coming out of or into the ports. What are the protocols? What is the payload? How does the device respond to malformed data or manipulated/fake instructions?
Hardware – Once the risk profile of the software and communications are understood, the device can be opened up to inspect the hardware. With the hardware open, the analyst can break down the internal communications, validate the provenance and security of the components, and inspect the firmware or data on each of the processors or memory.
Report – The last step is to write up a detailed report with insights and any recommended actions.
In our next posts, we’ll actually crack open a real medical device and do a sample analysis.
Until next time.