Finally, after a mere four and a half years in draft form, the FDA has released updated cyber security requirements for new (medical) devices seeking approval this fall.  These updated requirements highlight how medical devices are falling far behind other industries and are currently in a game of catch up. In what’s sure to be a fast paced and slightly chaotic version of catch up, medical device makers are currently faced with a slightly guided version of “choose your own adventure”, which let’s be honest here, is both good and bad. In the good column, device manufactures aren’t forced to use specific technologies or methodologies (unlike some other industries).

It's not fair.

When attacking an embedded system, it takes only one vulnerability to lead to an exploit, or at least an exploit chain. Of course, this all depends on what the attacker’s goals are in the first place.

This means, when tasked with securing an embedded system, the defender must think through and be prepared to protect against every possible vulnerability, across all layers of the system and overall architecture. Overlook just one opening and the attacker may find it, take control, steal your secrets, and create an exploit for others to use anytime, anywhere.

Like many companies, we run our own private gitlab server, and while it’s highly configurable, it doesn’t always meet our needs out of the box. Sometimes we have to automate complex tasks outside of the normal workflow. As we discovered, the complexity of a tool such as gitlab would necessitate interaction with its backend API in order to automate some fairly complex tasks.

In part one, we focused on identifying what data needs to be secured in your system. In this part, we will consider where our applications and data reside, so we can make sure any applied protections are meeting the desired goal. Identifying where our applications and data reside is critical to protecting it at rest, runtime and in transit.