11436 SSO

APIs for Data Security and Privacy: Part Two

Apigee's testimony before the ONC API Task Force
Gregory Brail
Mar 09, 2016

Apigee was invited to submit testimony to a January 2016 meeting of the API Task Force of the Office of the National Coordinator for Health Information Technology (known as the ONC). The Task Force posed a series of questions about the security of APIs and the ability of APIs to protect consumer data.

These questions are part of the panel’s effort to identify perceived and real privacy and security risks that could slow adoption of open APIs in healthcare. The Task Force is expected to present a set of recommendations to the ONC to help consumers leverage APIs to access patient data securely. It is set to present these recommendations in April 2016.

In the previous post, I answered questions about potential API vulnerabilities and how to protect data. Here, I discuss whether there are security protections unique to APIs in healthcare, and how developers can find and assess APIs.

Are [there security techniques] specific to APIs in general? What might be unique/specific to healthcare?

Of course, since the protection of personal information is especially important in the healthcare context, it is important to pay special attention to issues such as data encryption (both at rest and in transit). It is also important to design mechanisms that ensure data is only shared when the patient has given consent, and to give the patient tools to understand what consent was granted and to withdraw that consent when necessary.

How does the issuer of the API ensure that the API won’t become a tool used for malicious activity which could compromise the data source?

The first lines of defense against malicious activity are the ones described in the previous post—ensuring that each API call comes only from a properly-authorized application, on behalf of a legitimate user, and that both application and user are only accessing the data that they are authorized to access, and that neither is accessing the API more than they have agreed to in their contract.

Of course, with any technology it is always possible for a legitimate user to exceed the bounds of their authority. For instance, in the API world a developer could sign up to build a legitimate app, but then over time turn their app into a “bot” that attempts to gather large amounts of data from the API, perhaps for competitive purposes.

When that happens, it is critical that the API maintain an audit trail that shows which API calls were accessed, by whom, and when. More advanced technologies are becoming available today that can scan such an audit trail to detect “bot-like” activity and stop it before it goes too far.

How are APIs distributed in a way that the recipient/end-user of the API can trust the API is authentic?

Similar to web applications on the internet, any API that handles sensitive data must only be accessed using TLS (transport-level security, sometimes referred to as “SSL”) to encrypt the information, and to ensure the identity of the API server itself. That way the client calling the API can ensure that it will not attempt to use any API server that does not present the correct digital signature.

Furthermore, a well-run API will offer a complete “web portal,” which allows the developer considering the use of the API to learn more about the API and interact with the team that offers it. An API with a good portal and web presence, and better yet one that is backed by an enthusiastic community of developers who take pride in their work and answer questions from users and potential users, is much more attractive than an API that is just an empty storefront. A savvy developer will think twice before building mission-critical infrastructure on an API that appears to be abandoned by its creators, but the same developer will enthusiastically trust an API that is backed by an engaged community.

Are there existing metrics or is there a need to develop metrics to measure the maturity of security and privacy controls in the use of APIs?

While there are many well-known security best practices for APIs, there is not necessarily an “API security score” or something similar that the industry has agreed on. Such a “score” could certainly be developed as part of this effort, however.

Is there a catalogue or store of tools that are built for the APIs for third parties to access?

APIs themselves are typically discovered using the world wide web, just like so many things. A well-designed API will offer a “portal” that allows developers to discover what the API does, read documentation, and sign up for access, all via self-service. Depending on the security posture of the API, an API may allow access to any developer who asks, or require approval from a member of the API team, or even be set up so that only authenticated users can access the portal to learn about the API at all.

A good API will offer on this portal not only information and documentation, but tools to make it easier to use the API. For instance the most popular APIs offer a set of SDKs (software development kits) for various platforms and languages that make it easier to use the API.

With that said, the beauty of APIs is in their simplicity. All of the best APIs may be used by any programmer, from any environment, as long as they possess an application that is able to use the HTTP protocol and parse JSON data—in other words, just about every computing device in use today.

Furthermore, because of this simplicity, the developer who decides to adopt an API in an application can see exactly what data they are sending to the API -- it is not hidden by some proprietary protocol or opaque library. This improves the security posture of the application that uses the API, because nothing is left hidden.

In the next and final post of this series, I’ll examine perceived API security risks and how they might affect adoption of APIs.

Microservices Done Right

Next Steps

 
 

Resources Gallery

News