In the movie Idiocracy, society devolved toward having two major corporations control most of it, Costco and Brawndo. Brawndo was an energy drink known as The Thirst Mutilator. Because it had electrolytes, everyone used it instead of water, which led to its dominance. In this dystopian future, water was thought of as only for toilets. Even the water fountains in the hospital had Brawndo instead. It was also used for farming because the people in charge thought plants craved electrolytes. This led to a drought and no agriculture because of the years of chemicals building up and preventing plant growth.
When Secretary of the Interior Not Sure turned off the Brawndo and watered the plants instead, the subsequent crash caused the computers in charge of the Brawndo Corporation to automatically lay off most of the country and caused mass unemployment and riots. Not Sure was sentenced to almost certain death until at the last minute, and his decision paid off by showing plants growing in the soil.
While Idiocracy was just a movie, it has its parallels in Information Security. We can think of our current approach to security where we buy appliance upon appliance to protect different aspects of our environments every time a new technology becomes prevalent as a parallel to Brawndo being used as a panacea for everything from water fountains to agriculture. Meanwhile, the real technologies that facilitate security are relegated to utilities like water was in the movie Idiocracy.
In one of my previous articles, I discussed the basics of API security. This time around, I want to give more detail around what CIOs can do to protect their environments. The goal here is to make sure that you ask the right questions about your patient-facing API implementations to facilitate their access to their medical records. These nine questions will give you the insights you need to put systems in place to serve them securely. We’re here to facilitate their access to their data and do so as securely as possible.
The first question to ask is how these APIs will be developed. We’re going to give one piece of guidance. Don’t attempt this at home. Use the platform that your Electronic Medical Records vendor gives you whenever possible, and only use something else when there is no other option available for what you need. Are these APIs developed as part of the core Electronic Medical Records product, or are they put together to check a box that says you’re compliant? The answer needs to be the first, as there will continue to be changes in the core EMR product. The APIs need to be developed as part of this product so that changes made as part of the core product propagate to them. Fast Health Interoperability Resources (FHIR) is still being heavily developed. EMRs are adding more and more functionality, and patients demand it. Asking the question of whether or not this is considered core development will influence your future buying decisions.
Now that you have APIs, how will they be protected? Are they developed with security in mind? Do they test the code for security issues and address discovered vulnerabilities? Do they have continual integration and testing? Do they test for performance, which can also demonstrate where additional security issues can be found? Does the company employ teams to test their security and/or work with their defensive security teams that have significant application security experience to discover issues?
Too often the answer to these questions is to put them behind a firewall, web application firewall (WAF), or API firewall. The security testing turns out to be someone running Tenable Nessus or Rapid7 on the APIs and saying “No vulnerabilities here!”. These have the same effect on code as Brawndo does on crops. They make a lot of promises and claim to address issues, however they starve the development process of the attention it needs to integrate security and build better products. Firewalls, WAFs, and API Firewalls hide problems and do not give incentive for developers to make them better. Meanwhile, the mess behind them gets worse due to the false sense of security. If your vendor cannot affirmatively answer yes to the questions above, it’s time to find a new one. Real patients, not movie extras, use your systems. There’s a chasm of differences between acting like you have security and proving it.
The third question is whether you understand how the security works, and can you propagate it to your security team and organization? When we speak with customers, we often discuss something worse than no security at all, which is bad security. Bad security involves processes that interfere with existing workflows or are so different from existing ones that they are difficult to maintain. They also may be poorly documented and/or impossible for end users or superusers to execute. If your processes to maintain security for your API-based solutions are bad security, then they aren’t effective. These solutions won’t work. You need to push back until you address the root causes of the issues of why they are bad.
This leads to the fourth question, which is do you have good scalable patient identity management and proofing processes, and are they integrated across the organization? Right now, there’s a lot of vendors pushing patient identity management solutions for APIs. However, proofing for access isn’t that much more difficult than for a patient portal. There needs to be good identity proofing, verification, and validation processes that the organization understands in use across the teams. A solution will not work without good processes. Ideally, it will improve them and allow them to scale to provide better.
Scalable processes don’t work without an effective end product that can be used. This leads to the next question, which is if your patient identity management processes and products can integrate with OAuth 2 to authenticate users to the APIs? There are many great identity management products available. However, their end processes have to lead to the accepted form of authentication, which is OAuth 2. This is one of the most common authentication APIs out there. It’s as effective as a barcode in Idiocracy, however without the malfunctioning speech recognition.
Do these API implementations have a deployment plan that minimizes security risks? This is another question to ask. When you deploy these, you don’t want to have “test” APIs or sections exposed along with the secure ones. It’s these non-production systems that lead to attacks. Make sure that the non-production and development systems have better protections than the production ones and are kept isolated from each other. Also ensure you have a good internal communication plan that goes along with the deployment plan so all your teams are aware of what you’re doing.
How will security and performance be monitored? Do you have an operational plan to monitor for specific events, including:
- Error conditions
- Excess Errors
- Excess invalid logins
- Attempted password stuffing
- Invalid or faulty enrollments
- Logins from out of the USA
- Attempted application fuzzing. Fuzzing is a technique where someone induces erroneous behavior using invalid inputs to trigger a sequence of events to allow their code to run.
- Attempted SQL injection attacks
- Excess requests from single IP addresses
- Attempted bypassing of container or firewall security
If you do not have a plan to monitor for these conditions with your security team, EMR vendor, or Managed Security Services Provider (MSSP), you need to develop one as soon as possible. If your EMR vendor does not have a plan for these, then you need to have a long conversation with your executive team about the future of that EMR in your organization.
Does the vendor follow good DevSecOps practices, or have they just dumped a bunch of tools on their developers? Has the organization embraced DevSecOps techniques? Have they hired team members to help shepherd along the required changes? The move to APIs and iterative development requires a new mindset. This is no longer about planning monolithic releases. It’s about small-scale, continual, iterative change. Good security management with this requires organizations to embrace DevSecOps. Don’t let this be like when Microsoft released .NET and suddenly in-house Visual Basic developers became web developers of insecure and poorly maintained applications.
Finally, have you placed any of these security terms in your contracts? You’re not going to be able to enforce any of this unless you work with your legal teams or outside counsel to do so. We don’t recommend going to the character Dax Shepard played, Frito, for any advice, however. Seriously, you need to make sure you have good terms in writing enforcing security and continual vulnerability management.
We’re hoping this guide puts you on the right path forward for API security as a program, not just something that someone claims their appliance or magic beans can solve. It’s an involved process to make sure our patients get access to their data. Our jobs are to make sure they can do so securely and develop a sustainable management program to facilitate that. It’s like watering plants. If we water them with Brawndo, they won’t grow and will starve our organization. If we water them the right way and take care of them, we will see the benefits.
This article has (not) been brought to you by Carl’s Jr.
Excellent article, Mitch! Right in line with our conversation about security fundamentals. This is an important message.