2024 Archimedes Health Care Security Week Blog

DAY ONE

Hello Reader! My name is Christopher Pellegrini and I am an incoming PhD student to Professor Kevin Fu’s lab at Northeastern University. I am particularly interested in working with medical device security, so having the opportunity to attend the Archimedes Health Care Security Week was a daunting, yet incredibly exciting experience. My previous foray into medical device security was working with Dr. Dan Votipka and Ron Thompson at the Tufts Security and Privacy Lab (TSP) where I explored threat modeling cyber-physical systems, specifically medical devices. I had previously read about and worked with various topics during learning how to threat model medical devices, but most of the work was with toy models, and fictional medical devices that didn’t exist in the real world. 

During the first day of Archimedes, I had the opportunity to listen to Michelle Jump, the CEO of MedSec, lead an incredible discussion on Product Security Programs. I had previously read some regulatory documents/guidelines including some from ISO/IEEE 11073 and NIST’s OSCAL framework, so my understanding of pre and post-market product security was this: a lot documents, and a lot of acronyms. I sat down, laptop open and began to listen to Michelle dissect the current regulatory environment of medical device security. Michelle’s words sounded like a familiar, yet foreign language. It was almost like listening to my grandparents converse with each other and their friends in Cantonese. I was born and raised in New England, and learned Canto at home through my mother and grandparents, but my conversational ability was limited. I could pick up on various words and phrases, perhaps even make out sentences, but overall was lost. 

However, I continued to listen and began to pick up some interesting themes from Michelle’s analyses. It seems as if nowadays, it is much harder to obtain FDA approval for medical devices. Michelle described that the FDA was digging deeper into how security decisions are made rather than if they were made at all. I honestly had a hard time believing that all that was previously required by regulators was just a good faith effort at producing the required documents and system analyses. Now that the FDA seemingly transformed the process of medical device security regulation from the difficulty of a quick hike all the way to summiting a mountain (due to this nefarious sounding act called “Omnibus”). It made sense to me why Michelle’s workshop was so relevant. We continued through the afternoon discussing FDA’s eStar Program and pre-market product security. After, we virtually attended an FDA webinar regarding changes to section 524B of the FD&C Act. They discussed whether or not you would need to submit new documentation if you make changes to your medical device. The updates were intended to delineate between ‘significant’ and ‘not significant’ changes. From my time researching some of these topics, I have come to a conclusion that the current state of vulnerability scoring and risk assessment is not ideal. I do wonder what the threshold between ‘significant’ and ‘not significant’ changes will come out to be. To anyone reading, have you seen a change marked ‘not significant’ that was borderline or actually ‘significant’? But after listening to both Michelle and the webinar I got the impression that “reasonable assurance” is a pretty popular word in the space.

Another tool that was discussed to aid in determining that there is a “reasonable assurance of the safety and effectiveness of devices” are Software Bill of Materials (SBOMs). During the FDA presentation they described SBOM’s as very ‘dynamic’ and that they needed time to “mature and evolve”. Slightly interesting to me how they now explicitly require something that they believe still needs more infrastructure and literature. I would love to know in what ways the FDA believes SBOM’s should evolve. Is the FDA’s plan to essentially require it, and watch as the space scrambles to optimize and make the best use of this new technology? Michelle had also explained that it was difficult for her company to get SBOMs from certain part manufacturers, who do not fall under FDA’s SBOM requirement themselves.  Thank you very much to Allan Freidman for defining all the acronyms used during our conversations. Wildly helpful.

DAY TWO

Day two of Archimedes involved various talks from important members of the medical device security community. We started with a panel with Gerome Burrell from Abbott, Chris Reed from Medtronic, and Stacie Brough from Baxter Healthcare. They discussed building business value from building security into medical devices. It was interesting, yet understandable that HDO’s mainly prioritize profits. From the panel I learned that medical device security is often downplayed in order to care for a larger number of patients, and those that are involved in the space must present security as explicitly increasing business value. 

The next presentation was with Dr. Allan Friedman from CISA. He spoke about leading the SBOM project and its future path. SBOM’s were already on my radar, supporting Dr. Friedman’s claims that SBOM now has widespread awareness in 2024. The “Twinkie” example that was presented particularly stuck with me. It went something like this: Let’s say you are a vegetarian, in order to determine if you can eat a Twinkie you must check the ingredient list. Since tallow is listed as an ingredient, you can’t eat it. However, the ingredient list will not explicitly prevent people from deviating from their diet, or keeping people from eating something they are actually allergic to. The lesson here was despite the fact that the ingredient list does not enforce dietary rules, the list is necessary for determining what we actually do in certain situations. It is apparent that SBOM’s are not quite as simple as an ingredients list of pre-packaged snacks. He discussed the current problems companies have with SBOM’s, the main complaint being that many device/component manufacturers say that SBOM is too hard to implement, while still advertising that their products come with one. It was obvious to me that there is a discrepancy between the intended use case of SBOM from the FDA and what is actually being produced in practice. For example, Dr. Friedman mentioned that there is nothing in the guidelines that says you need a fully complete SBOM. In the future I would love to look more into how “depth” of SBOM’s are calculated as well as how SBOM’s are evaluated for completeness. 

After this we listened to David Brumley’s (from ForAllSecure) presentation called “Test Like a Hacker”.  He explained the processes by which “hackers” should explore, map, exploit, and weaponize various threats that exist within a system. I found it interesting that he used mainly automotive examples throughout his speech, but it was clear how different cyber-physical systems have the same core characteristics. After this I joined the Engineering & Medical Device Security breakout session, beginning with a talk called What FDA is Seeing and Seeking in Pre-Market Submissions by Justin Post from FDA. Justin expanded upon the Omnibus laws signed into effect December 2023, and provided more clarifications on section 524B of FD&C act. After this we listened to Dan Lyon from Boston Scientific give a presentation titled Security Fundamentals for Engineers. Much of the presentation involved discussing controls to maintain CIA principles, and various quips about the power of RSA (and crypto in general) to provide security. If I do anything I promise Dan Lyon to never improvise or take shortcuts when it comes to implementing crypto, I’ll leave that to the cryptographers :). To finish the day, Nastassia Tamari gave a talk called FDA Focus Areas in 2024 and Beyond - What Should We Prepare For? She explained that the conversation regarding medical device security has exponentially expanded from “Why are we doing cybersecurity?” to the who, what, when, where, how, and why. She discussed 542B (which seemed to be a wildly important theme of this conference) and the premarket cybersecurity guidance and its updates, which are intended to help manufacturers comply with requirements under section 542B of the FD&C Act.

To end the day, Professor Fu gathered the attendees in the hotel lobby for our “evening event”. As the elevator descended into the lobby I heard the commotion of a big band playing classic New Orleans street jazz, probably from right outside the hotel, but as the elevator doors opened I was greeted by the attendees of Archimedes surrounding a big band right in the hotel lobby! I soon found out that the band would be accompanying us on our walk to dinner, as the journey doubled as a funeral procession for Windows 10 End of Support. What a way to wrap up the second day!

DAY THREE

On the third and final day, I got straight out of bed and clipped on my race number in preparation for the 524B Fun Run. I descended down to the lobby and observed a mixture of both groggy-eyed and enthusiastic participants ready to do a run/walk through Nola. Despite my one season of cross country in high school (which I really struggled through), I took the back of the line, ensuring that no racers got left behind. My duties were not completely fulfilled as another group of participants snuck off to a cafe to get beignets before the race was even done! Once we returned to the location of the conference it was time to shower up and get ready for the first talk of the day.

Pat Baird, a Software Standards Specialist from Philips kicked off the day with a talk titled “Cybersecurity Considerations for Artificial Intelligence/Machine Learning Systems“. Up until this point I hadn’t heard much about the topic of security and privacy measures for AI, and Baird was able to easily break down the current landscape. He described how ML/AI systems have lots of potentially attractive data that is often passed from one system to another, between many stakeholders. He also described various security concerns of AI systems, which include model poisoning (injecting malicious data into training dataset), inversion (reverse engineering the input data used to develop a specific model), and model stealing (replicating the entire functionality of the model itself). In order to protect against these threats, and many others not described, Baird noted that ISO/IEC SC27 & SC42 have joined together to work on an international standard for AI security, but unfortunately they are moving too slow, which seems probable in a field that seemingly cannot slow down.

Following Baird’s warnings about AI/ML security, Hector Rodriguez from AWS presented a talk titled “Security Considerations for Medical Devices that Leverage the Cloud”. He described the current landscape of digital ecosystems as a new business and delivery model that heavily relies on connected devices, which require modern and resilient end-to-end cybersecurity. Following the idea that these digital ecosystems are reliant upon connected devices, Rodriguez stated that connected medical devices will be everywhere in modern HCLS systems, and consequently become the “digital front door” of the future of healthcare. Rodriguez recommended that organizations should pivot to cyber-resilience rather than cybersecurity, as no solution can protect 100% against varied security events. Cyber-resilience is the idea that an organization can quickly protect, detect, analyze, contain, eradicate, and recover when issues arise. Rodriguez wrapped up his talk by noting that one should “think and test like an attacker” in order to undo the kill-chain process, a seemingly popular idea also brought up in Brumley’s talk from the previous day.

Finally, the last presentation I attended for the day was Adam Shostack’s talk titled “Threat Modeling in the Age of AI’. He began by discussing both the offensive and defensive purposes, examples include writing phishing emails or malware for offensive purposes, and anti-spam filtering for defensive purposes. Shostack also discussed the critical nature of training data in scenarios where AI is to be integrated into medical device security, or cybersecurity purposes in general. Shostack referenced the Berryville Institute's taxonomy of threats, which includes manipulation and extraction of data and models, referencing many of the same threats that Baird discussed in his talk previously in the day. For threat libraries Shostack recommends starting with Berryville’s taxonomy of threats, and then moving onto other resources. Shostack then discussed the implications of using LLMs to develop software, which he described as “deeply scary” due to AI taking our data as well as AI possibly producing bad code. However, when using AI to secure software, Shostack toys with the idea that AI can help humans to produce better code, but it is largely unknown if AI can produce better results than Veracode or Checkmarx at finding vulnerabilities. As for threat modeling, Shostack differentiates between using LLMs to aid in the threat modeling process and raw LLM usage for threat modeling. LLMs used as an aid can help to increase the speed and scale of the threat modeling process, but may introduce issues such as hallucination and the inability to discover threats to new technologies. As for raw LLM usage for the threat modeling process, Shostack states that it isn’t yet highly effective. Shostack concluded with the idea that LLMs are most likely best at tasks smaller than threat modeling as a whole, including tasks such as generating system models, stories about what can go wrong, and even writing mitigation code to observed threats.

This wraps up my report of Archimedes 2024! I would like to extend a huge thank you to Veronica Estrella, Kelly Sabo, and Bill Aerts for allowing me to join the event staff team! I had a great time working with you all! And another huge thank you to Professor Fu for the incredible opportunity to attend this year's Archimedes! Finally, thank you to all the speaker and attendees for the vibrant conversation, and the fascinating talks. The future of medical device security seems so exciting, and I cannot wait to share ideas and continue exploring the field.