By Andrew Aiken and Connor Walsh, CISSP
For anyone driving a car manufactured in the last five years, you are probably familiar with new technologies like radar cruise control, front/rear collision avoidance, lane departure warnings and more. Similarly, commercial off-the-shelf operating systems have become more robust to enrich the user experience. While great for the mass market, these features become a detriment when designing for a focused purpose such as industrial controls, flight systems and, yes, medical applications. Enter a breed of operating systems known as Real Time Operating Systems (RTOS). Like a race car, any bloat is trimmed for the task when microseconds matter between input, calculation and output.
What makes these operating systems different? As the name implies, a time constraint. Consider the need in everything from infusion pumps and physiological monitors to a surgical robot with multiple arms and servos performing a delicate vascular surgery. So, what could go wrong from a device security perspective? Like many IoT, OT and IoMT devices, security often takes a back seat, or to continue the metaphor, little initial thought is given to installing theft deterrence on a race car.
Nearly two years ago, we learned of a critical threat to these systems known as “Urgent 11” which could allow an attacker to take full control of a device via a TCP/IP stack vulnerability. This includes the ability to capture data (patient), disable/manipulate critical alarms, reversing motors, etc. and was quickly rated a major threat because of its severity of impact and ease of exploitation. Manufacturers acted quickly to release a patch. However, many in the HTM and security communities were still caught flat-footed as most local inventory queries came up negative since RTOS were not properly identified … rather they were characterized using broader terms such as Other OS, Proprietary, or just Embedded. Examples of widely used RTOS are LynxOS, OSE, QNX, RTLinux and VxWorks (WindRiver) as detailed in Figure 1 below.
There are various physical, technical and administrative controls that we as HTM can deploy to protect this new breed of OS. Of the available controls, arguably the most important administratively is knowing what you have in your environment. Take the time during procurement to ask vendors specific questions on systems that are labelled vaguely (i.e “proprietary embedded”) and inquire on their specific patching policies. This information can be better used to effectively perform a more granular risk assessment on the device.
Once identified, consider the actual location/placement of the RTOS. Is the device small and in a high-volume area that can be stolen easily? Should it be moved to a secure storage when not in use? Physical USB blockers may also be applied to safeguard any open input/output (IO) on the device. Technical controls should consist of network isolation and segmentation, as well as network monitoring of what traffic enters and leaves the VLAN. User authentication for these systems should also be considered.
RTOS’s prove to be effective targets, as even within the last months we’ve seen a CISA advisory given a 9.8 CVSS score on “BadAlloc” which details easily exploitable vulnerabilities in several RTOS products. Threat actors will continue to target these systems due in part to their limited security controls and to their abundant use across multiple critical industries. It is part of our job as HTM professionals to ensure that we do not leave our facilities open to attack. – to paraphrase G.I. Joe, knowing what we have is half the battle.
– Andrew Aiken is an Information Systems Biomedical Equipment Support Specialist (IS-BESS) for the VISN 9 program office at the Department of Veterans Affairs. Connor Walsh, CISSP, is a supervisory clinical engineer for the VA Boston Healthcare System.
The views expressed here are those of the author and do not necessarily represent or reflect the views of TechNation or MD Publishing.
