Interconnected and distributed systems have made the role of APIs critical to enabling discreet connectivity between systems but can create additional risk.
Application Programming Interfaces (APIs) are notoriously difficult to secure, particularly if they are internet-facing. As one source puts it: “APIs are designed to facilitate communication between different systems and applications, which means they are inherently exposed to various external actors. This exposure increases the attack surface, making them attractive targets for malicious actors”.
So, what can we do to make the best of a challenging concept? In a ISC2 webinar, Byron McNaught from the security division of F5, gave us a few ideas.
The Reality of Using APIs
If APIs are so hard to secure, should we continue using them at all. After all, why do we need to expose parts of our systems so that third parties can access them? There are two answers.
First, it’s because our customers and partners need – not just want – to be able to interact with our systems to perform transactions or manipulate data, and they want to have their systems rather than their people doing these interactions.
But second, it’s not just third parties accessing our APIs – it’s us too. Take things like mobile banking applications, for instance. In many cases the application is extremely “thin” – it has the company brand and handles inputs and outputs with the user, and the heavy lifting of the business logic is at the server end, the other side of the API, on the premise that you write it once and can access it from many apps and places. And the approach has some security benefits, in fact, because if you put all the functionality in the mobile app itself, a bad actor can reverse-compile the code and learn about our business logic and perhaps use that logic against us.
One key mention is PCI-DSS, the data security standard for payment card processing, which is always a worthwhile reference because even if you aren’t dealing with payment cards, the principles it contains are often pertinent to security in general. These days PCI-DSS understandably contains references to APIs.
McNaught talked about the mechanisms people use to secure APIs, of which there were four key approaches: Web Application Firewalls (WAFs), API gateways, proxies/load balancers and service meshes. Prior to the webinar, ISC2 had carried out some research and had discovered that 56% of respondents use WAFs for API defence, with API gateways the next most popular at 31%. McNaught was surprised that the WAF was most popular, saying: “I was expecting API gateway and WAF to be at the top”, he says, “but to be honest, I thought it was going to be the converse”.
His logic is understandable, because a WAF is a very general tool that defends against common web attacks such as SQL injection or Cross-Site Request Forgery (CSRF). WAFs have been along for much, much longer than APIs have been popular. API gateways, on the other hand, exist entirely because of a desire to secure APIs. They do tasks like passing incoming requests to back-end servers, load-balancing the requests across servers and doing data transformations (for example converting between JSON and XML).
More Than One Tool to Do the Job
The point is made, too, that a combination of tools is the way to go, particularly in a complex setup (of which an example is a multi-cloud setup). Taking up an analogy with a medieval castle, McNaught said: “Think of your WAF as your drawbridge. But then you have to protect all your windows, that's your API security. You have your tower guards, looking for bots and DDoS. You have your app Infrastructure Protection, or cloud workload protection … protecting the underlying infrastructure, and then you have [a] messenger to prevent those client side attacks”.
On the subject of proxies (in this context we’re dealing with reverse proxies, which take the request from the calling system, make the call to the back-end system, then return the response to the caller) you can choose how much or how little examination the proxy makes on requests. McNaught noted that if you want to be particularly granular in inspecting requests: “you need to do deep inspection, you have complex and dynamic traffic patterns, that's really where like a load balancer, or Application Delivery Controller comes into play”. And with regard to service meshes: “because API's are, are [a] collection of business logic that's usually distributed in microservices clusters, that service to service communication is usually best handled with a service mesh, especially when there's different programming languages or tech stacks used”.
But where should we start? If we only have the time, people and/or money to do one of the above, which should it be? McNaught is clear on that one: “The API gateway has … probably the largest spread of capabilities”. If you’re going to pick what he refers to as a “jack of all trades”, the answer is the API gateway. “This … combines … the scalable high-performance capabilities of a reverse proxy or load balancer with some of the security capabilities like discovery, authentication, authorization, as well as logging so we're really seeing that as becoming a critical part of any modern technology stack”.
The ideal way to go, then, is to have a sensible combination of tools to defend your world. But if you have to start somewhere, or you simply can’t go for a multi-product system, you could do worse than implementing an API gateway.
Want to know more? The full webinar is here.