Data Leak Prevention and APIs

Let’s face it, APIs are hot. They engender community by enabling third-party developers, they allow Enterprises to expose existing content and services in new ways, and they provide a way to deliver brand new products and services. If you haven’t seen the statistics, API traffic is now on the same order of magnitude as web traffic, and it just keeps growing. Further, platforms such as Ruby on Rails make it easy to expose REST based services by returning different formats (such as XML or JSON) for existing services initially designed for a web browser.

When an Enterprise exposes an API they are really exposing a back-end function call intended to return some useful data. In the case of REST the data returned is an XML or JSON representation of a server object. In the case of SOAP, it is an XML payload or possibly a MIME attachment.  Most Enterprises assume that as long as authentication is taken care of, via an API key or OAuth dance, and SSL is turned “on”, security is “done.” I would say that for most APIs this model works extremely well. The trouble with securing systems is that is the exceptional case rather than the rule that bites you in the end.

For instance, one trend we are seeing is the increased use of employee productivity applications being exposed on mobile devices, such as conference room booking applications or “people-finder” applications. Other similar applications are soon to follow and these applications do all of their business using REST. How long will it be before we start seeing the pervasive use document collaboration applications?

 Is DLP Necessary?

How do Enterprises safeguard their intellectual property or sensitive PCI or PII data that flows as API responses to these millions of connected devices? Do we need data leak prevention for APIs?

As I mentioned earlier, I don’t think many Enterprises have considered this issue of DLP and APIs yet because many Enterprises are still working on getting their APIs up and running with the current security feature set, which at the moment is focused very heavily on authentication and session security.

I can, however, think of potential risk scenarios where an FTP file share is opened up over an SOAP API (returning MIME), or a REST façade is put over a database that was once only intended for internal use.

Remember, a saboteur only needs to find one weak link to claim victory.

Enterprises might consider the following to reduce their risk

  • First assume all data leaving the Enterprise has the potential for intellectual property, privacy or PCI data leakage
  • Ensure application servers are drawing from a persistence tier that cannot be easily polluted by sensitive data
  • Enforce data loss/leakage controls on API responses (if available at your security gateway)
  • Consider encrypting, redacting or tokenizing API responses
  • Carefully examine APIs that return binary blobs/attachments or SOAP with Attachments to see where the data originates from
  • Ensure a security layer, such as a gateway or proxy, is in use when exposing APIs to millions of devices

 

-Blake

Blake Dournaee

About Blake Dournaee

Passionate, energetic product manager that lives at the intersection of business, innovation and technology. I currently work at Intel in the Datacenter Software Division working on products and technologies relating to mobile, APIs, cloud services and big data.

Comments are closed.