API Security: In Pursuit Of MASH

Between the Cambridge Analytica incident at Facebook and the General Data Protection Regulation (GDPR) kicking in across Europe from the 25th of May, it’s safe to say that online security is set to take center stage like never before. A repercussion of all this for API developers is a renewed focus on discovering and analyzing exactly how consumers are interacting with your API.

From Nissan to Tinder, many of the high profile online vulnerabilities hitting the headlines of late come down to issues with APIs. As a result there’s a very real possibility that, particularly for large organizations, 2018 will be the year of meeting with an API security specialist.

Insecure APIs are causing public breaches and negative press at many organizations.

Akshay Aggarwal, one such security specialist, is a former Microsoft Director and current CEO of PeachTech. He appeared at our Platform Summit last year and dropped a few thoughts on security that — now more than ever — make for essential reading for all API developers.

Complexity

Let’s start things off by highlighting the fact that API security is complicated. That’s not to say that traditional web security is easy but, as Akshay says, “as soon as you enter the world of microservices architecture [as opposed to a traditional application], the complexity of this problem explodes by an order of magnitude or more.”

As is so often the case, that increased level of complexity is associated with additional cost. It’s anecdotal evidence but Akshay suggests that, in his experience, fixing a bug in an API vs. a comparable bug on a standard website can cost anywhere from 1.5 to 2x as much.

While there are common design threads across many APIs, each API infrastructure works differently. In other words, there’s no “one size fits all” approach on par with, say, adding a firewall to a network. As Akshay says:

“Securing web APIs is slow, manual, and reliant upon tester skill.”

But that’s not where the problem ends.

Understanding and future proofing known vulnerabilities in your code is all well and good, but Akshay encourages developers to ask themselves “what is your plan to find the unknown vulnerabilities in your API?”

A study conducted by HP found that the average IoT (Internet of Things) device may have as many as 25 vulnerabilities, including insufficient encryption and unsecure user interfaces; it’s practically a sure thing that some of these security flaws will be related to the APIs used to give data and functionality to said client devices.

It’s almost enough to make you want to seek out some white hat hackers to put your API through its paces…or at the very least review some security-centric courses by someone like Troy Hunt, Microsoft Regional Director and creator of tools like Have I Been Pwned.

Responsibility

Who is responsible for API security? Akshay brings up a summary of a recent Ovum study that found 53% of respondents believe the IT department is responsible for securing APIs while 47% said the API development team in question is responsible. When there’s this type of disparity between people’s answers, it becomes way too easy for API security to fall through the cracks.

One of Akshay’s slides notes that “API security now relies on the developer consumer” too. To put it another way, responsibility doesn’t begin and end with API developers and/or the IT department. Unfortunately, as he notes, the assumption is often that the API developer has taken care of everything on the security side of the API.

While there are arguments to be made that everyone from API consumers all the way through to end users of apps have a role to play when it comes to security, it’s probably wiser for API developers to assume that the buck stops with them. Insecure processes will always come back to haunt the team of developers behind an API and, with the precedent set by huge potential fines we’re seeing associated with GDPR non-compliance, may also have a significant financial impact.

3 Steps To Scale Security

As we’ve already mentioned above, it’s difficult to prescribe a “silver bullet” that will work for every API. What Akshay does suggest, however, is a set of three checkpoints that can be thought of as a solid foundation for good API security.

1. Integrate with CI System

Akshay suggests blending your security measures with unit testing – with the end goal of integrating them into your existing tools and processes.

“Make security testing just another step in your build pipeline”

2. Test Security of Each Build

Relying on manual testing is problematic for a couple of reasons. As well as being time consuming, it also relies on the relevant person making sure they add it into their workflow on a regular basis. We all know that life sometimes gets in the way and, before you know it, you’ve deployed a ton of code without any security checks being carried out.

3. Return Actionable Results

In order to get anything from automatic testing, you must act on your testing information.
This is actually a two parter, because you must both take appropriate action based on the result, and assign the remediation effort to a team member. That may be API developers themselves, a QA team, IT security specialist, or someone from all of the above areas.

What’s interesting is that all of the above points sort of boil down to one key instruction, and it’s one with a nice little acronym to boot: MASH (Make API Security Habitual).

Final Thoughts

Perhaps the biggest issue with API and microservices security right now is that it’s often viewed as an afterthought, rather than as a key part of the development process. Rik Turner, senior analyst at Ovum, that “this study [mentioned above] highlights an alarming lack of consistency and ownership in how API security is addressed.”

That’s echoed in the thought that Akshay leaves us with, saying that ultimately “[any solution your implement] has to match the testing you’re already doing. Think of security not as a unique case of testing, but something that fits within your existing testing framework.”

We’ve seen above that there are plenty of ways to do this, ranging from brushing up on API security best practices and trying to hack your own API – Akshay jokes at the beginning of his talk that he doesn’t build APIs, but takes them apart – through to using an external tool to get the job done. Whatever route you take, perhaps the most important thing of all is ensuring that the people in charge of API security at your organization are actively securing, testing, and fine-tuning API connections.