When it comes to cybersecurity, "absolute" security does not exist. Instead, it's a balance of risk management and pragmatic safeguarding. The goal is not to achieve impenetrability but to reach a state of sufficient security where risks are understood, measured, and consciously accepted.
The first article in this series, “How to Secure Data on Mobile Medical Devices”, identified five common weaknesses in systems:
- Weak Authentication and Authorization (A&A) Practices
- Insecure Data Storage
- Insufficient Encryption
- Inadequate Input Validation
- Lack of Proper Session Management
This article looks at each of these weaknesses and shares some advice on practices that will help provide an acceptable level of security.
Weak Authentication and Authorization
What is appropriate (and best) for A&A is mainly dependent on the infrastructure around the device. For instance, is a multifactor authentication (MFA) server available or is the system largely offline? However, regardless of the larger ecosystem of the device, some practices will go a long way to secure a device that applies to any deployment.
Recent years have seen a heightened focus on password handling and management, underscoring their critical role in device security while raising widespread awareness about the necessity of robust password protection. Regarding brute-force resistance, there is ongoing debate within the industry on whether a complex password is better than a long passphrase. Another strategy to consider is for the system to add a timeout for retry on an incorrect password, possibly with an increasing timeout as the number of retry attempts increases. This strategy will generally mitigate a brute-force attack or make it sufficiently cumbersome to be avoided.
Verifying user identification (ID) and the password as a set is essential. Consider the consequences if the device confirms the user ID without a password requirement. Such a scenario inadvertently aids malicious actors, allowing them to focus solely on deciphering the password, thereby partially solving the puzzle more swiftly. If it remains ambiguous which element is incorrect, the solution becomes more effectively obscured.
Many jurisdictions now require that default and setup accounts are forced to change the password on first use to prevent operations with defaults, a frequent operational weakness. As previously mentioned in the context of A&A, authenticated users must not be granted privileges that exceed the requirements of their designated roles. Typically referred to as the Principle of Least Privilege (PoLP), this practice limits a given user's footprint and restricts the damage a bad actor can accomplish with a general account. The counter is that it does make privileged accounts more valuable to acquire. It also increases the importance of ensuring a system resists privilege escalation attacks.
Insecure Data Storage/Insufficient encryption
Insecure storage and insufficient encryption are closely interrelated. Developers need to be diligent in segregating data within their applications. Consider securely storing anything critical or sensitive.
The secure storage of data refers to:
- Storing the data in a restricted location
- Ensuring the data is appropriately obscured (i.e., encrypted) if it is exposed
- Implementing integrity checks
A restricted location may mean it is unavailable for read access to a general user. The developer must use the operating system (OS) functionalities to limit file access solely to the user accounts that need to see them. For a bare metal embedded device, this might be storing data in a secured flash device. Once the data is stored, it should be encrypted.
The developer should limit the ability of an interested party to view data in the first place. Nonetheless, it will likely be difficult to restrict it thoroughly, so if a bad actor can view the data, it should not be in a form that is easily understood (i.e., "plain text"). Many operating systems provide encryption mechanisms that you can use, but it is essential to choose a currently accepted type of security. Many existing encryption methods are considered "broken" and should not be used. These are constantly changing, so reviewing the status of a chosen implementation is recommended to be sure it is still considered a valid approach.
Data should be stored in files or blocks that can check for integrity. Some embedded storage mediums have "hidden" parity checks that can be used to determine if the data has changed or has been corrupted. There are many methods to check the integrity of a file. For example, a hash could be calculated using the binary content of a file.
Consider the data valid if the hash matches the check file's stored data. You may want to generate an integrity fault if it doesn't fit. Although this method doesn't stop data from being altered, it ensures that if the data is manipulated, the system will be aware of it before use.
Inadequate Input Validation
Any system that takes a user’s "free-form" data must validate the input. It is highly recommended that all data—no matter the source—be treated as suspect, a concept frequently referred to as "zero trust." Several undesirable things can happen without appropriate input validation. Any interface that allows unrestricted input makes it possible for a bad actor to manipulate the system into unexpected states.
Any methods that consume data should evaluate the received data. Consider the following:
- Is the data within the range of rationality (e.g., range, size, non-zero or blank, etc.)?
- Is the data of the right type (e.g., a phone number will not contain alpha characters)?
- Does it contain unexpected content (e.g., command delimiters, etc.)?
- What is the length or size of the input (e.g., number of characters or digits)?
- What is the syntax (e.g., phone number, SSN, date, etc.)?
If the data doesn't meet the above checks, it should be gracefully handled and not be allowed to be consumed by the rest of the system.
Session Management
At its simplest, session management establishes a temporary trust between two parties for further exchange of information. Once you establish this trust, you must protect it from other parties attempting to interfere (e.g., spoofing, man-in-the-middle, etc.).
Many development frameworks have session management features. For this reason, consider using these existing frameworks instead of a "home roll" (i.e., a new method). Much like encryption, these frameworks will have vulnerabilities exposed over time, so it's always advisable to use the latest and review any bulletins applicable to systems in use. It is essential to use encrypted connections and current encryption methods (i.e., Transport Layer Security, or TLS, vs. Secure Sockets Layer, or SSL).
Comprehensive Security Solutions
Navigating the complexities of mobile medical application security can be daunting. While this article is only a partial discussion of practices that will fix security issues in developing mobile applications for medical devices, it provides a starting point for the conversation about your medical designs. Many decisions need to be evaluated within the context of your design's threat assessment and threat model. Benchmark can help guide you through those decisions and give you peace of mind for a secure method.
Our expertise in cybersecurity best practices, from robust password management to advanced encryption techniques, ensures your medical applications are compliant and resilient against potential threats. Partner with Benchmark to fortify your embedded software applications and safeguard sensitive data.
To learn more about cybersecurity best practices, download our white paper on Meeting FDA Cybersecurity Guidelines.
