Labeling in medical devices is critical to ensuring the effective use of the system as a whole and the end user’s safety. Part of labeling that can be easily overlooked is the cybersecurity labeling portion. This guidance is passed down to the end user to help them stay informed on how to reduce cyber risk. Typical cybersecurity labeling can cover things such as default safe configurations on the device itself, any supplemental programs that can increase safety, and any other device-specific guidance.
Cybersecurity Labeling Concerns
Addressing cybersecurity labeling is one of the most important aspects of a submission for clearance by a regulatory agency, such as the FDA. Device manufacturers may have certain areas of the device that are exposed to higher risk without actionable ways to reduce this risk. As opposed to simply accepting the level of risk, it can be a much safer idea to develop a procedure to reduce risk as much as possible and inform the users of this procedure.
Labeling concerns can vary widely based on the specific device. Many requirements will be identified early in the process and integrated throughout the development lifecycle. How much of this is covered in these early phases depends on the cybersecurity expertise of the development team and how early they can begin the implementation of security principles.
While ideally, labeling concerns are addressed early and often, this may not always be the case. It can be easy for something small to go unnoticed and make its way into the final product. This is where penetration testing comes in. A penetration tester can evaluate the security of the device and notice things that should have been addressed before. While this will spot residual problems, it is typically more difficult to implement fixes at these later stages.
Penetration testing and vulnerability identification are critical components in this process, but without actionable ways to remediate the vulnerabilities, it is not very useful to manufacturers. Experience with medical device submissions is just as important as experience with penetration testing. When testing a typical application or network that a penetration tester may be accustomed to, they will not have to worry about labeling recommendations. When choosing a service provider for this task, it is important to make sure that they can assist with guidance on what can fall under labeling concerns.
Once labeling concerns have been identified, the next step is to make sure that they are communicated to the user. It is important to guide ranging technical levels, as the labeling considerations for a systems administrator deploying the device in the network will be different than the considerations for a non-technical end user. Device manufacturers need to be sure that they are addressing any different levels of consideration that may apply to the device.
Design vs. Labeling
When problems are identified, it can be difficult to decide what falls under labeling considerations and what should be done from a design perspective. Major software design changes can be very complex and costly to implement, and in many cases, fixes may not even be possible. When this is the case, it can make sense to find an alternative solution where enough of a change is made to allow labeling to inherit the rest of the risk.
A quick example of a fix easily covered by labeling is password strength requirements. While these can typically be built into the device as well, it is never a bad idea to have an additional layer of security. A very common password requirement would be a combination of upper and lower case letters, numbers, and special characters, along with a minimum length of 8 characters. While this is a good starting point, many insecure passwords such as ‘Password1!’ would meet these requirements and may expose the user to additional risk. Labeling can help bridge the gap and educate users on further best practices.
Another area that can be addressed by labeling more easily than design relates to interoperable systems and components. Interoperable components are anything that interfaces with the system that does not fall under the trust boundary mapped out by the development team. These components typically fall out of the control of the development team, and as such cannot be affected by design changes. This makes them the perfect candidate for labeling considerations. Using the same password example as before, a connected printer may have a weak default password policy, but labeling on securing the printer can act as a form of risk reduction to the system as a whole.
