By Vidya Murthy

The healthcare community has made progress in bringing awareness to medical device cyber-risks, as evidenced by the nearly 400%, year-over-year, increase in vulnerability disclosures since the U.S. FDA post-market guidance in 2016. However, identifying, managing, and remediating vulnerabilities is a complex task and has been burdensome and slow as it has traditionally relied on manual processes. 

The strategic imperative is to move security upstream in the supply chain and build proactive security into devices starting with the architecture and design phases. If this methodology is applied across the lifecycle, it could reduce total costs, improve cybersecurity, and alleviate the burden that is currently passed on to and consequently carried by healthcare delivery organizations, physicians, and patients. One of the first steps in this journey is to build a vulnerability management program, which includes generating a software bill of materials (SBOM)—meaning a definite and accurate identification of all software components in a device. 

Today’s State of Affairs

There are certain trends which highlight the urgency for addressing security gaps sooner rather than waiting to react to them in the deployed device, e.g., in a hospital. As a recent study highlighted, “hospitals are already facing the consequences of omitted [security] measures within their growing pool of medical devices.” 

When designing a security program, there is seemingly a never-ending list of things that need to be added or could possibly derail the success of the program, and they must be mitigated. Seasoned executives will confirm that delivering security used to be relatively straightforward, with amateur or opportunistic attackers being the most probable adversary. 

Today, the situation is different. Cybercriminals are organized, motivated, well-funded, and possess a wide range of skills. In an assessment of the SolarWinds attack during the winter of 2020, Microsoft estimated at least 1,000 engineers were involved in creating the attack. Is there any non-government entity that has an equivalent number of resources at their disposal to defend their ecosystem? 

Why a Reactive Approach Doesn’t Work 

It’s a common trope in cybersecurity to say that people are the weakest link. This is often followed by a statistic from the 2020 Cost of a Data Breach Report published annually by IBM and Ponemon stating 23% of breaches were attributed to human error or negligence.  

But maybe that statistic should instead be interpreted as we are missing 23% of use-cases where a human’s behavior has been misunderstood, and where technology failed so that the human became the expected last line of defense. A great example is email—we’ve all sat through training which shows when clicking on a link in an email, make sure you check various feature to avoid falling for a phishing scam.

In reality, most email providers already have ML/AI trained filters to identify potential scams and have filtered out suspicious emails. If this filter cannot identify a phishing email, is it really fair to ask an end user to be able to do this? The gap keeps widening between attackers and defenders, and while there are some mitigation tools implemented to bridge us through this cybersecurity maturation, pointing to the people and manual processes to mitigate cybersecurity is not scalable nor sustainable. 

During WannaCry in 2017, regulators and hospitals needed to answer the question: “Which devices in the field are affected by the Windows SMB vulnerability that is allowing WannaCry to spread?” This was difficult to do, because there was limited record of which version and patch level of Windows deployed medical devices were running.

This pain point was further evidenced with the recently disclosed, deeply embedded technology stack vulnerabilities (Urgent11, Amnesia:33, etc.), which impacts components, in some cases several generations, commonly found in medical devices.

How to Move Forward

As with most hard things, our industry seems to be struggling to get started. Frequent supply chain attacks have become something of a “new normal” for those of us whose everyday work involves protecting applications. 

Further validated by the executive order (EO) issued in May by the White House, which directed federal agencies to bolster cybersecurity and that the National Institute of Standards and Technology (NIST) issue new guidelines to support the EO. Supply chain vulnerability management thus seems a prudent place to start, as evident by the fact that the EO specifically calls out SBOM as a procurement deliverable.

In practice, some device manufacturers have people-driven processes that manage vulnerabilities on a device during the pre- and post-market phases. Healthcare organizations, on the other hand, typically are struggling to get accurate inventories of devices and their respective SBOMs. This reflects the reality that there is massive variability in maturity across healthcare. 

Supporting a product SBOM was never meant to be a standalone silver-bullet. It plays a role as part of a security strategy that begins at the inception of product design and persists across a device’s lifecycle. The transparency an SBOM provides into all the dependencies between the software components of an application or device can help prevent, or more quickly mitigate, supply chain vulnerabilities.

How Does the SBOM Help?

Over the years there have been objections to the SBOM, which the NTIA recently myth-busted. Of particular interest is the discussion around not making SBOMs public but being intentional in what information is shared and with whom. Within healthcare this is absolutely relevant as the value proposition varies dramatically depending on where you sit in the device lifecycle:  

  • For software producers (i.e., manufacturers): 
    • An SBOM enables maintaining applications by detailing upstream components and tracking changes between the versions of the application. When a vulnerability is disclosed, using an SBOM the software producer can detect right away which versions are impacted, address the issue and notify their customers.
  • For software buyers and operators (i.e., healthcare delivery organizations): 
    • The SBOM provides visibility into the product they’re purchasing to assess security and compliance standards and requirements, especially in a highly-regulated industry like healthcare. It also helps them anticipate and quantify the inherent risks in a particular software package.
  • For software operators (i.e., manufacturers and operators): 
    • The SBOM helps inform processes for vulnerability and asset management, licensing compliance verification, and identification of risky software components. The SBOM can also help optimize the reliability of the software, lowering the risk of failure and malfunctions.

The more complex an application, the more valuable an SBOM, as it provides clarity into the dependencies within the components, and among the multiple layers of the software (i.e., the application, and the OS).

To date, the industry is still working through aligning on what should be included in the SBOM and the depth to which it must be compiled to be useful. The NTIA recently published a minimum expectation for what should be included in an SBOM, but much like security continues to evolve, it is reasonable to expect this will evolve as well. 

Vidya Murthy is chief operating officer at MedCrypt. Questions and comments can be directed to 24×7 Magazine chief editor Keri Forsythe-Stephens at editor@24x7mag.com.