Want Security AND Interoperability from Your Health Insurance API? Here’s What to Audit
Since the 21st Century Cures Act, APIs have been integral to the streamlined and rapid data sharing that modern care models depend upon. The ability of members, providers, and payors to access a comprehensive and clear view of individuals’ health and wellness picture has the potential to further transform treatments. Yet the accessibility of your health insurance API, as well as its ability to function as a go-between for a diverse array of systems, can put your organization at risk.
In a recent survey, 91% of respondents across industries shared that they identified some form of security threat within their production APIs last year. Unfortunately, these weren’t inconsequential issues:
- 54% found vulnerabilities that remained open to hackers
- 46% struggled with authentication issues
- 9% were outright breached
Rather than leaving vulnerabilities exposed to the outside world, it’s essential for healthcare payors to identify weak points and fortify your defenses. Yet where do you start? When we conduct an API audit, we always focus on these specific areas.
1.) Determine What Data Is Shared by Which APIs
Until recently, most consumers had little awareness about the unrestrained nature of modern data collection. Then, the fallout from the Cambridge Analytica scandal brought data harvesting and data protection into the limelight. As a result of the growing publicity of data misuse or breaches, 79% of Americans are now very or somewhat concerned about how organizations use the data they collect.
For healthcare providers and payors, there is another level of concern as personal health information (PHI) proliferates across a complex IT ecosystem. With the growing number of end points and interoperability, there’s a potential for thousands of people, if not millions, to be exposed with each data breach – if organizations are not careful. And any API that overshares information is a significant risk.
Auditing your APIs to determine what information they share in response to requests can help to prevent hackers from using that information later. API best practices assert that all each system should send is a communication confirmation (did it succeed or fail) and only the essential resources required by a request.
2.) Review Your API Security Strategy
Often, there’s an assumption that the healthcare compliance security polices which govern the rest of your business are rolled into your APIs. The truth is that the bulk of organizations have not appropriately hardened their API security stance – even if they already have zero trust security framework in place. As Keith Casey at the Austin API Summit put it, security strategies need to guide their actions by thinking like hackers and asking one key question, “how can we abuse this?” Only from there can you design an effective API security strategy from the top down.
When building an API security strategy, ask these questions to help you assess the vulnerabilities to your organization:
- Is there proper and secure authentication on your APIs? – With the often ad hoc nature of API implementation, there is a higher likelihood that only the bare minimum of security authentication is followed. Usernames and passwords only create a small hurdle for hackers to jump, especially since 80% of all breaches happen with stolen or brute-forced credentials. Even though authentication tokens can provide another level of security, hackers will abuse them if they fall into their hands.Beyond the basics is the OAuth protocol, which doesn’t have the end user share any of their user credentials when accessing third-party applications, removing the risk of stolen authentication from the equation. Since this is becoming increasingly standard, there is a chance that your health insurance API was built with that in mind. But it’s always better to verify than to accept this level of authentication security on faith.
- Do you have rate limit strategies in place? – Just like websites, your APIs can be subject to denial of service attacks. Because of the high number of queries and requests that can come to APIs, there is a fine line that organizations need to walk when creating security precautions. The answer is rate-limiting your health insurance API.Quotas and throttling are two primary ways to achieve rate-limit API requests that defend against DoS attacks. When using quotas, your organization limits the requests from individual users over a defined timeframe to hinder any malicious activity. On the other hand, throttling limits the number of requests by slowing a user’s connection to the API as a way of forcing them to make fewer requests.
- Are you controlling users and systems accessing your APIs? – There is a growing recognition across organizations about the potential profitability of well-constructed APIs. Yet this shouldn’t be used to justify a laissez-faire approach to accessibility. Again, Keith Casey brings up a strong point in his talk:“We’re not going to publish API keys to everyone. We need to stop and think who do we want to have access and is their use case valid? And sometimes the answer is going to be no, and that’s fine, but we need to draw these boundaries.”Organizations need to review all requests for access, whether manually or with dedicated personnel, to ensure that individuals or groups that will misuse or jeopardize your overall security are barred from access.
By asking these and other questions, you can construct an API security strategy that addresses potential problems before they put your business and your members at risk.
3.) Check for Standardization
The FHIR API framework creates a lingua franca for your diverse systems, but not all organizations build or invest in APIs with that standardization in mind. Unfortunately for them, their implementations might miss out on true interoperability if they neglect effective standards.
That begs the question: how standardized are APIs in the healthcare industry? The survey responses to HIMSS give some enlightening insight. Of the healthcare organizations they surveyed, each one has at least one of these types of APIs:
85.7% 71.4% 57.1%
API Developed In-House 3rd Party API Out-of-the-Box API
Though it’s possible to achieve interoperability across these types of implementations, there needs to be a clear commitment to creat