API management is becoming increasingly important for organisations. Companies have used them internally for connecting their own systems. Now they are adapting their existing APIs and building new ones as part of their digital transformation plans. The question is, how well are they managed?
To understand more about APIs, the risk they might pose and security, Enterprise Times spoke with Paul Fremantle, CTO, WS02. WS02’s API Manager is an open-source full lifecycle API Management solution. It can be deployed on-premises, private cloud, as a service or in any combination thereof.
How do we manage the risk of API attacks?
One of the concerns over increased API usage is that APIs connect people deeply into our infrastructure. Unlike human-centric attacks, which are still the dominant form of attack, they run at machine speed. The question is, are we able to detect bad behaviour from an API and stop an attack?
Fremantle answered: “We’ve looked at this and identified ways to deal with it. First, we have scope and policy-based authorisation. It starts by making sure the API key expires and needs to be refreshed regularly. If somebody does manage to steal it, they need to have stolen the full credentials and not just the key itself.
“Secondly, we limit the access to what that key can do to the minimum. We don’t allow a key to do everything on this API. There are a set of policies and scopes that are associated with each key.
“The third thing is that the key itself has access to a certain subscription level. Every level has a throttling policy associated with it. If the behaviour of this key suddenly starts trying to do 100 requests a second and it wasn’t designed to do that, then it’s going to be throttled automatically down to up to five per second. All that helps to minimise the damage in that way.”
How do you handle onboarding and subscription?
Onboarding partners and setting up subscriptions requires properly thought out processes. According to Fremantle, that means you don’t just hand out the API key to anyone who asks.
He said: “One of the things that we’ve built in that our customers are very keen to use is the right onboarding mechanism. You don’t just give an ID to anybody on the portal to come and subscribe. There’s a process to validate your API partners. That means having a subscription onboarding workflow. It means doing various checks on this company before they’re given a key.”
But all of that takes time. To ensure that partners can work during that process, Fremantle says you can give them a sandbox key. It allows their developers to work with the API and test their app. It also gives you the time to make sure that they can be trusted. But is that enough?
Fremantle replied: “We’ve seen some people go even further and, and do what’s called a walled garden approach.” He gives the example of working with Boeing, who were concerned about security and access.
“They were talking about giving access to data from the plane itself. They built a system where the clients talked to the API. All the code running in this ecosystem lived in their Platform as a Service Cloud. They did security scans and validation and all kinds of processes to ensure that it met their standards. Even small players had to have the same rigour that Boeing had on their own project.”
Can that work for smaller companies?
Somebody the size of Boeing can enforce sandboxes and build their own platform. For many organisations, however, that isn’t viable. So what do companies do?
Fremantle commented: “What I’m seeing is it depends on what that API can do. If you are selling your API, and you are selling a product to a third party, then typically if they screw up and buy too much, well, I’m not going to be unhappy about that. Refund them if they ask, but that’s their problem. For example, if you’re Twilio and somebody sends a million text messages and owes you $100,000 for that, you’re not necessarily going to be upset about that.”
What about quality and security?
But what about the quality issue? Companies are exposing internal APIs to partners, customers and even make them public. Are they investing in proper code reviews before they onboard customers?
Fremantle said: “We’ve been trying to help people design their APIs from the outside in, rather than just from the inside out. In other words, take a swagger open API first approach to design.” Another approach that Fremantle advocates is to aggregate and filter existing APIs into a much cleaner API. He also believes that development teams should use tools to analyse their open API definitions. The goal is to apply a design-time policy across those APIs effectively.
Fremantle is also seeing customers adding API gateways and firewalls. One way that this happens is through the use of an AI-driven security rule-based analysis policy. He says that companies are adopting API Management inside their organisation. “Then they take those internal APIs and promote them through a process to then have an exposed API. Often, that is not the same API.”
Are companies adding audits?
One way of checking a system is working properly is to use audits. Surprisingly, few companies do this well. Instead, they just relying on SIEM systems to detect everything. Fremantle said: “That’s where some of the rule-based and AI security that we have comes in. We have a very flexible policy engine, which has both a set of pre-written policies and on-board policies.”
He gave examples of sudden spikes in the average traffic per day from a supplier. That behaviour should flag up and require an administrator to check it is okay. Fremantle also believes that companies need to understand how traffic differs between suppliers. It allows them to detect any anomalies more easily.
One way of doing this is to make sure the rule-based policies look at traffic and time-based patterns. For example, a customer may preface every order with two queries. If suddenly it submits orders with no queries that should be a red flag. To build these rules takes time and experience, which is why WS02 has its own AI research team looking for these anomalies through an automated AI-based solution.
How easy is it to patch an API?
APIs can be complicated, and few customers use all of them. It creates a risk that customers might not patch because they don’t think the patch applies to them. Additionally, a customer may be worried about a patch breaking their software. How do you enforce patching?
Fremantle believes that API patching is easier than with other software. He says: “Once you’ve applied a patch to the API, everyone has it. Any calls they make will be to the patched API.”
At the same time, Fremantle believes the API provider needs to think the process through. “The API provider creates two kinds of patches; breaking patches and non-breaking patches. When you update that API, you as the provider have to do the testing and decide, is this something that I can change without breaking my consumers or not? If it is a non-breaking patch its easy. You just fix that security hole directly and enforce it.”
What about breaking API changes? This is where Fremantle sees the power of an API over traditional software. In the case of the latter, you cannot enforce what customers download and use. With an API, it is different. He says: “In the API case, I launch an updated version and push out a notification to all the API consumers through the portal to say, “There’s going to be a CVE notification in a month’s time. We need everybody to have updated before that notification goes out to the public.”
If customers don’t upgrade the API, Fremantle says you just email them, call them, nag them. Warn that you are going to cut them off if they don’t act. Importantly, you can see what version they are using so security is stronger.
But does this approach work?
Fremantle believes it does. He says that WS02 is seeing customers enforcing versioning. It’s part of the solution that WS02 provides. He said: “You cannot do unversioned APIs. All of our customers are doing versioned APIs because we won’t let them do anything else. They are using that capability to track who’s on the old versions and to actively try and move deprecated users over.”
What’s important here is that this solves the problem companies have across their wider software estate. Many find themselves running multiple versions of software in test, dev and production. It increases the security gap, especially for developers who may write code without realising it reopens a vulnerability. If that isn’t picked up in testing, then it ends up a production problem.
One of the advantages of moving to cloud-based platforms, says Fremantle is: “They are doing more robust security in the cloud than they were on-premises. Amazon, Microsoft, Google are applying AI and other techniques, and best practice to securing things.” Interestingly, he also sees this shifting responsibility for security. “Once you have a cloud-based solution, you are responsible for security, not the customer.”
Enterprise Times: What does this mean
Software security is hard. There are a lot of moving parts, and not all of them are under the control of the vendor. What is clear from talking with Fremantle, is that this is changing with APIs and cloud-based systems. Those vendors who invest in APIs and manage them correctly can address security issues quickly and enforce patching. The key here is enforcing. As some API vendors have discovered, you can’t just leave it to customers to choose when they get around to patching a vulnerability.
Cloud also brings a change in security, not least in responsibility. It’s too easy to blame the customer for not patching. Few customers run simple environments where a patch can be thrown at software with no concern. The more complex the environment, the more chance a patch for one product will break others. As software moves to the cloud, Freemantle sees the responsibility being that of the vendor to patch.
This is exactly what we see with mobile devices. Software is constantly being updated to fix bugs, vulnerabilities and add new functionality. Users don’t question the level of updates, they just let them happen. Can cloud-based APIs be the solution for the enterprise to get to this same level of security and control?
