Over the last several years of my career, I’ve had the opportunity to work with a variety of global medical device manufacturers. Recently, I have also started working with some new organizations that are not yet global in scale. A theme that I have discovered is that these organizations haven’t yet established true ownership for security within the organization, even though there is increasing regulatory pressure for building security, evidenced by updated FDA guidance and recognition of international standards such IEC 62443, UL 2900, and AAMI TIR 57.
Organizations are certainly aware of the increasing regulatory pressure. However, what many organizations are not yet aware of is how the software security industry has learned and evolved over the last 20 years to realize the importance of building security into the software that powers their offerings and overall business. For any medical device manufacturer, it only makes sense to learn from where the industry has been and use that knowledge to start an initiative to address security for their medical products and systems.
In my experience, many manufacturers start with only a vague understanding of what security is and how to achieve it, primarily informed by what not to do through sensationalized media headlines. Independent security researchers and media exposure are a fundamental part of the security industry, yet they often neglect to address organizational support to build security into devices.
Just like safety and reliability, building security into devices requires a mix of people, processes, and technology applied by an organization to achieve the appropriate security goals of a system. This requires an organizational structure that can bring about the needed changes in processes and skillsets to create the right technological solutions. Without the proper organizational structure that owns and drives these changes, security will be a piecemeal effort at best. Any piecemeal effort is doomed to fail because security is a systems problem. The organization needs to set itself up to address systems problems through the development organization and processes used to create products.
How can organizations structure themselves to address the security problem proactively? First and foremost, looking at any security-mature organization, one will notice that responsibility is clearly established at a leadership level, with security being the sole responsibility for key roles such as a CISO. The CISO tends to have broad responsibility for the entire organization, and products are but one of the many concerns.
To address this, an emerging trend among medical device manufacturers is the creation of a new role for a Product Security Officer or Product Security Group, whose sole purpose is to help guide the product development processes and tools to adopt secure-by-design principles.
Avoiding common security missteps in securing medical devices
There are three common missteps I often see when organizations set up a new initiative around security. These are things we often end up discussing with manufacturers to help them drive faster and more effective security programs.
1. A lack of responsibility and accountability within the organization.
Too often I see organizations that do not have a product security function at all—either no one is thinking about security or security is supposed to be addressed by everyone. When security is everybody’s responsibility, then no one owns it. Such an organizational structure leads to basic security needs being left out of the development process.
2. Making security a part-time responsibility.
It isn’t a good practice for organizations to assign security responsibility as a part-time job to someone who has other large responsibilities, such as quality or regulatory. Having a single person responsible for security who is also responsible for additional aspects like project management or product quality is insufficient. This type of organizational structure leads to security needs taking a backseat to items such as project cost, schedule, or performance. This lowering of priority leads to increased risks for the organization with respect to regulatory approval or media exposure. In the worst case, it may also lead to increased safety risks.
These approaches both suffer from setting up a clear line of ownership, responsibility, and priority. Product security is broad, complex, and different enough that it needs to have dedicated resources that focus all their time on security. Much like building a safety program that drives the organization to compliance with appropriate standards such as ISO 14971, medical device manufacturers need to build that same organizational security capability.
3. Attempting to solve medical device product security through the corporate IT function.
Organizations will often start out by assigning someone whose background is not product development, but rather information technology. This organizational structure causes a lot of friction between the IT security group and the product development group because neither understands the other very well. The solutions IT professionals are used to do not always apply very well on medical devices. Likewise, the development organization struggles to identify and incorporate the true security needs from the IT security function.
Again, taking safety as an example, one would not assign product safety responsibility to a person or group with no background in building devices for patient care. Addressing problems requires new and different skill sets. There are two ways in which organizations grow their capability in this manner. First is by hiring in resources with a security and product development background. While sometimes possible, this mix of skills is very rare, and organizations have learned that the next best approach is to take an engineer already familiar with product development and teach them security. While this approach can take time, it can also be a rewarding career path for the right resource.
Organizations all start their security journey in different places. There are significant challenges with building organizational capability and culture change. Avoiding these three common missteps will cut years off the timeline it takes to build that new organizational capability.
We have seen these missteps many times through the Building Security In Maturity Model (BSIMM), a study now in its 11th iteration which aims to understand how real-world organizations are executing their software security strategies. Any medical device manufacturer interested in security needs to be familiar with BSIMM in addition to the regulatory environment and most up to date medical devices security standards.
