Avoiding Communication Breakdown

When dealing with connected medical devices in the IOMT (Internet of medical things) world no one wants a communication breakdown especially from a security vulnerability. Our guest cyber experts this week are John Bonham, John Paul Jones and Jimmy Page (I guess Mr. Plant was busy during this work.)

”Communication breakdown, it's always the same

Havin' a nervous breakdown, a-drive me insane, yeah”

(They look a bit like scruffy software developers any day but especially ones that have not had much human interaction for almost 12 months of pandemic.)

Where is this blog post going? Well one often recommended way to avoid communication breakdowns due to vulnerabilities is to incorporate security by design through up front threat modeling of your device design.

I recommend the book Threat Modeling Designing For Security by Adam Shostack. Not to brag, I will be attending an MDIC.org virtual boot camp on threat modeling with Adam Shostack starting next week. FDA is involved with this too. This is the second time they are doing this so try to catch it next time.

I am not going to try to cover something as big as threat modeling in a blog post but in Adam Shostack’s book I came across a free Microsoft threat modeling tool that I wanted to try. (https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling) This post will go through that tool for a fairly simple connected medical device example.

Note that for threat modeling in the past, I have just used Visio for diagrams and Word for the threat model text so I am interested to try something more integrated. By the way, Adam Shostack recommends pen and paper.

Example

Assume we have an embedded processor running FreeRTOS connected to an external SPI flash to store its data. The processor sends and receives data with an iPhone using Bluetooth/ BLE. The iPhone does not store any data.

In just a few minutes I was able to modify the example data flow diagram that came with the tool and create the figure above. That was nice and quick. For each element like the iPhone (external interactor) there are a number of attributes you can set. You can add custom attributes too. Once you set everything up then you can flip to the analysis view and see the threats that the tool identified. For the diagram above with 7 discrete elements there are 33 threats identified. Each of these threats are categorized using the STRIDE method. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privileges. The method is STRIDE by element so each element of the model is considered for each of the 6 types. Note that on a laptop screen it was difficult to view the details of the analysis view but there is an easy way to generate an HTML report that is easier to read. All 33 threats were identified as high priority by default.

Strangely in the analysis view the 33 threat numbers start at 7 and go to 52. In the html report they go from 1 to 33. I am assuming this unusual numbering is because I started with the example. It must reserve previous numbers as the drawing changes.

For example, one threat is that someone spoofs the iPhone

3. Spoofing of the iPhone External Destination Entity  [State: Not Started]  [Priority: High] 
Category: Spoofing 
Description: iPhone may be spoofed by an attacker and this may lead to data being sent to the attacker's target instead of iPhone. Consider using a standard authentication mechanism to identify the external entity.

One can change the authentication attribute on the BLE link and then mark this as mitigated. These sort of interactions are done manually.

Assessment, it is a helpful tool with good drawing capabilities. I may use it for some upcoming threat modeling work to see how it works on a real project. I don't think a tool can replace the value of a group getting together and talking things out though. It may help to generate ideas though.