Are we paying enough attention to API security?

Is API security on the radar of most IT teams? It’s arguably still not as high on the priority list as it should be. Consider this: an Imperva/Marsh McLennan study from 2022 claimed that vulnerable and unsecured APIs cause up to 7.5% of global “cyber events and losses”, and cost businesses an estimated $75bn annually.

The experts I spoke to for an upcoming feature highlighteed complexity, visibility gaps and skills shortages as key barriers to enhanced API security. As digital transformation initiatives push on across the globe, the need to fill these gaps will only increase.

Out of control

APIs are essential to digital projects, connecting as they do applications to backend databases. But by the same token, if compromised, they could be used to provide a neat pathway to exfiltrate corporate and customer data.

“APIs that aren’t closely monitored can easily fall victim to high-volume attacks such as brute force login attempts and enumeration techniques. They are also often easily identified, are web accessible, and each of their methods documented,” Bridewell Consulting senior pen tester, Andy Tyler, told me.

“Once an attacker knows how to interact with your API they can quickly hunt for vulnerabilities; from authentication issues, to injection attacks, or access control misconfigurations. All of these can lead to sudden data theft on a large scale.”

In fact, that happened to T-Mobile USA last year. Although full details of the incident are yet to be released, the firm admitted in January that an attacker took data on 37 million customers via an API.

For Forrester analyst, Sandy Carielli, security teams and tools have been slow to catch up, even as the number of APIs has exploded.

“A lot of the traditional web app security tools didn’t support APIs, leaving holes in the protection – even as API security has evolved and more solutions are available, organisations struggle to understand what combination of tools and processes are needed,” she told me.

“The tools and processes exist to counter this threat, but many organizations struggle due to the newness of the technology and the number of APIs in their organization. It’s not uncommon for enterprises to have tens of thousands or even hundreds of thousands of customer and partner facing APIs – and they may not have a good grasp of what those APIs are and what they do.”

Bridewell’s Tyler agrees, but thinks things are improving.

“The tools and testing techniques needed for assessing APIs have only more recently reached maturity. Automated scanners in particular are still very poor at identifying API security issues, which can lead to false negative results for those organisations running their own checks,” he said.

“Many of us in this industry are working to demystify many of the API-specific issues for the organisations we work with and we have seen great improvements in their overall API security approaches.”

Out of the loop

As is so often the case, API risk seems to have been allowed to snowball because security isn’t brought in early enough in the software development lifecycle.

“Unfortunately, many organisations have little to no oversight over their APIs given the pace of application development and the lack of visibility security teams have into development practices,” Imperva director of technology, Peter Klimek, told me.

“For example, APIs are often released into production before security teams can review and catalogue them. Such inadequate security practices lead to both ‘shadow’ APIs – an API that isn’t cataloged and is therefore invisible to the security team – and  “zombie” APIs, which haven’t been  properly disabled and are still accessible. Both of these can be a potential breeding ground for cyber-criminal activity.”

There’s no silver bullet to the challenge of escalating, API-driven cyber risk. But shifting security left, and protecting right through layered measures including encryption, API gateways, web app firewalls and zero trust approaches would seem like a good place to start.

When ethics meets cybersecurity: how should vendor choose who to sell to?

When we talk about ethics in cybersecurity, it’s largely a matter of where researchers should draw the line so that their behaviour doesn’t start to resemble the black hats their tracking. But there are also serious choices to be made by the security vendors they work for in terms of who ultimately gets to use their products. After all, in the wrong hands, legitimate tools could make the world a darker place, and expose vendors to potential fines and reputational damage.

I spoke to some experts about this for an upcoming Infosecurity Magazine article.

Complexity is everywhere

Discussions around ethics and cybersecurity came to a head recently when WhatsApp launched legal proceedings against a well-known Israeli ‘cyber intelligence’ firm, NSO Group, alleging it had helped to develop and deploy malware that was subsequently used to spy on civilians in the Middle East and elsewhere.

Firms like these notoriously operate in a grey area, claiming they only sell their wares for legitimate law enforcement and intelligence uses. Yet what about the much larger market of ‘regular’ cybersecurity vendors? What controls have they, or should they have, in place to limit who gets hold of their kit? After all, deep packet inspection tools could be subverted by despotic regimes to monitor legitimate internet traffic, and IP address filtering to enforce rigorous state censorship, for example.

Trade association techUK has developed a lengthy guidance document for organisations not sure of where their legal obligations stand, and how to comply. But even then, programme manager, Dan Paterson, told me that it can be difficult for especially smaller vendors to conduct due diligence effectively, particularly in the tricky area of dual-use technologies.

No cause for concern?

Even if they can’t, there may be no cause for concern, according to Privacy International’s state surveillance program lead, Edin Omanovic. He told me that, in fact, current UK export rules rely too much on “non-binding and unenforced risk assessments”, which makes it easy for unscrupulous vendors to sell to hostile nations.

It’s a point echoed by Luta Security CEO, Katy Moussouris, who is helping the US government negotiate the global control regime known as the Wassenaar Arrangement. She suggested when I spoke to her that export controls in tech aren’t even really there to restrict the flow of goods outwards, but merely to give domestic governments a better understanding of what its companies are producing.

If that’s true, then what’s the harm? Well, there are still major risk calculations that organisations must undertake — and it’s not just about selling to authoritarian regimes, according to Amanda Finch, CEO of the Chartered Institute of Information Security (CIISec).

“As with any other aspect of security, vendors need to consider risk when choosing their customers. Selling to the wrong customer might mean that a vendor has no way to support its product or resolve contractual disputes, resulting in wasted resources. It might mean that the vendor loses its unique IP, and ultimately its market position,” she explained to me.

“It might mean that the vendor loses the trust of many customers, if a new line of business opens those customers up to new threats. Even if there is no direct risk to the vendor itself, dealing with customers seen as unethical can still damage a business’s reputation. The vendor may still feel that going ahead with a sale is the right decision, but it needs to have weighed the risks beforehand.”

As with most things cybersecurity, therefore, it all boils down to risk management. And with CSR increasingly important in what is a crowded marketplace, ensuring you’re seen to be acting ethically is vitally important, even if export controls aren’t.