APIs for Data Security and Privacy: Part Three
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 whether there are security protections unique to APIs in healthcare, and how developers can find and assess APIs.
In the third and final post of this series, I’ll examine perceived API compliance and security risks and how they might affect adoption of APIs.
Are there known compliance implications with the use of APIs?
There are no compliance implications to the use of APIs that do not already apply to data that is exposed via a web application or file transfer system. Industry standards such as PCI and HIPAA apply to APIs just as they apply to other systems. Similarly, information privacy or data protection laws such as ECPA in the United States, PIPEDA in Canada, ECHR in Europe, and DPA in the United Kingdom may also have implications with the use of APIs.
What are the perceived and actual security concerns or barriers to the adoption of APIs?
The actual security concerns are those that we have previously discussed: ensuring that only authorized end users and applications access APIs, controlling the amount of API traffic that they are allowed to generate, ensuring that the API traffic does not contain malicious content, and auditing all the traffic for later analysis and risk mitigation. These best practices are critical, but at the same time they are well known and there are many products available from commercial firms as well as open-source organizations that can help.
The perceived security barriers are often higher. Many people believe that by “offering an API,” an organization is suddenly “exposing data” that was previously locked away in a secure vault. While this sometimes happens, it is more common that the data being offered via API was previously transferred between systems using a marginally-secure file transfer system, or displayed by a complex web application, or even routinely sent via e-mail.
APIs are different because they are designed from the ground up to do only one thing, and that is to provide programmatic access to developers who code applications. As such, an API provides a much tighter contract than a web application. There is no reason why an API built to today’s best practices cannot be set up so that every single API interaction is authenticated, authorized, encrypted, and audited to ensure that no data protection policies are breached.
How can these risks be mitigated/how are you addressing this?
Every API provider is responsible for following API security best practices such as those described earlier in this document.
To that end, we at Apigee provide a software product that makes it possible to implement these security practices, by doing things like authenticating API traffic, controlling the amount of traffic from each application, scanning for threats, and detecting and rejecting “bot-like” activity automatically.
Furthermore, there is a great deal of information to be found in various webinars, blogs, books, and other formats written by experts from Apigee and from many other companies that describes how APIs can be deployed in ways that allow developers to quickly build new solutions, while protecting against security risks.