With McAfee Focus underway this week I wanted to revisit security, risk and compliance in the context of providing Bulletproof API management. So what does it take? There is some prevailing wisdom out there that security for APIs and API management is licked and considered a solved problem. With the widespread use of standards like OAuth 2 and SSL/TLS it seems that Enterprises have nothing to worry about when considering authentication, authorization and transport level security for their APIs. Well, almost nothing – modulo back-doors in the pseudo-random number generation from the NSA (scary if true). For most public or open APIs, OAuth 2 or shared-secret style API keys seems like security enough.
Simply relying on these standards without looking at all possible attack vectors can lull the Enterprise into a false sense of security. What do I mean?
Bulletproof API Management Tip: Content Threats
As APIs continue their prodigious rise across all sectors of the world economy let’s not forget that they are a data and function window into your organization. I’ve used the term universal tunnel before and I think the term is as apt as ever. Moreover, if we consider some of the business models where the API is the product itself, bulletproofing the API takes on even greater import. APIs allow programmatic access to your Enterprise assets, and the more valuable & interconnected you make your API, the more you will need bulletproof API management.
This is not a new concept, but simply a variation of code injection applied to JSON content as it travels between a device (or client) and your Enterprise. When an API call is executed there is an assumption that the system exposing the API endpoint is strongly correlating function or method calls to parts of the JSON content. In other words, your phone (or API client) is actually causing server side function calls – it’s this essential behavior the attacker is trying to exploit.
These concerns potentially multiply when we move to a world of connected “IoT” devices, which may be more susceptible to physical tampering in the wild. Where and how exactly this happens in your environment is a function of how you designed your API and your adherence to various levels of RESTfulness, but it’s always the weakest link: It’s the authenticated and authorized clients that will best be able to best play with, discover and exploit the limits of your API. Attackers and rogue users can discover the undocumented parts & behaviors of your API by hacking different types of requests and function calls, especially if you don’t have an active strategy in place for limit or quota enforcement or input validation. Even better, the code injection is sent over SSL/TLS so its protected by prying eyes and authorized with an OAuth 2 secret. Phew, good thing we have security in place…
Bulletproof API Management Tip: Data Leaks
The second piece of achieving Bulletproof API Management is to mitigate risks to the Enterprise for data leakage (DLP), compliance and personally identifiable information. Most modern application servers make it easy to expose a RESTful model, take Ruby on Rails (RoR) for example which exposes a CRUDable interface nearly by default in rails routing. This means that developers can easily enable RESTful access, potentially exposing data of unknown sensitivity quite easily.
This is great for productivity and is exactly how developers should be thinking about APIs, after all, when APIs begin their life it’s not entirely clear how they will be accessed and by whom. With time to market pressures, however, the development team may be more worried about getting the new API up and running and the CISO may not know if parts of the database contain trade secrets, employee data, patent data, price lists, revenue, or sensitive PII data. With more and more data moving between devices and APIs, Enterprises need a DLP strategy for APIs.
So what to do? For starters, obfuscating exceptions and errors is an important first step to mitigate code injection attempts. Exceptions and stack traces will give the attacker information about the underlying system that implements the API. Second, you need some type of input validation which ensures that data sent in RESTful requests undergoes the proper data-type checking and range checking. Third, if you are exposing an internal system as an API without the use of an API management solution, you really have to ensure that internal APIs are inaccessible, which could mean expensive code auditing and further software development costs.
The core problem here is that security hole can be inadvertently introduced with a strong coupling between Enterprise middleware, databases, or application servers and the published API; it’s always a good idea to have a level of separation and the API management solution can trap these types of attacks in a distinct security layer, check outgoing payloads against a DLP engine (such as McAfee DLP), protect PII through format preserving encryption or tokenization and act as a security policy enforcement point before threats become that or before sensitive data leaves the Enterprise.