‘Rogue’ APIs may be created by intent or by accident; it’s how you discover and deal with them that is important, writes Stephen Gillies, APAC Technology Evangelist, Fastly
For as long as IT and security departments have existed, there have been employees and organisations doing their best to bypass them and the guardrails and controls they set.
The result of that bypass is often lumped under the umbrella term ‘shadow IT’.
Shadow IT is talked about much less these days because IT departments have simply accepted that business units will buy and manage some software systems themselves, this kind of pseudo-sanctioned shadow IT still causes issues. An Australian KPMG survey found 41 percent of business-led IT decisions are made without formally involving IT, and that these companies “are twice as likely to have multiple security areas exposed than those who consult IT.”
Teams and companies traditionally justify shadow procurement or the bypassing of the IT or security departments with concerns about productivity or agility. For example, developers may be under time pressures due to the length of Agile sprint cycles or continuous integration and continuous delivery (CI/CD) practices. Hurried to get things done under pressure to ship, they may try to bypass established corporate channels (read: slow and bureaucratic) to get code into production.
But not all shadow IT is intentional.
When it comes to things like application programming interfaces (APIs), which – for all intents and purposes – are functional components of a larger system, there may not be awareness that they need special attention or specific disclosure that they exist, especially to an internal security team.
APIs may go undocumented because they are thought of as a piece of the machinery, as a part of a larger application, and therefore not as a product in their own right. These become ‘shadow’ or ‘rogue’ APIs, hidden pathways into an organisation that may be abused by bad actors.
APIs may also be properly disclosed to IT and security but published or made public accidentally, therefore also becoming ‘rogue’.
As security professionals know, APIs are already a sizable attack vector. Gartner has previously predicted that by 2022, API attacks will become the most-frequent attack vector, causing data breaches for enterprise web applications. Shadow or rogue APIs are considered the most vulnerable.
As APIs power more applications and public-facing experiences, organisations need to double-down on discovery and visibility to uncover the existence of APIs, and to keep the digital experiences they power safe and secure.
Scoping the challenge
Recent research by Enterprise Strategy Group (ESG) and Fastly found 45 percent of Australian organisations believe most or all of their applications will use APIs in the next two years.
In addition, 47 percent of Australian organisations expect to support more than 200 internally-developed applications within two years, up from 33 percent of organisations today. Most if not all internal applications rely on APIs to support the use of microservices, to share data or interconnect with other applications. Organisations are amassing large API footprints as a result.
Despite an anticipated increase in API implementation, organisations stated that web application and API security now is more difficult than it was two years ago. They indicated struggles to maintain adequate security across new application architectures.
Nine out of ten Australian organisations also experienced at least 10 attacks on their web applications and APIs in the past year that went undetected by current security tools until they had a negative impact of some kind on the business.
A new approach
Organisations have traditionally used a defense-in-depth approach to protect APIs and web apps, layering multiple security tools from multiple vendors in the hope of creating strong protection. But the result is a patchwork of incompatible tools that cause more problems than they solve.
In reality, the shift to API-centric applications requires a modern security strategy and solution to support continued innovation around digital experiences.
The first step is to slow down. That might sound counterintuitive but innovation filled with risk is not the endgame. Go slow, test new security approaches, and soon your organisation will be cranking out innovations at the same iteration pace as before, just much more securely.
To prevent bypass, organisations should implement security directly into the internal app and API workflow process so it is not a hurdle to work around, but a part of the process that can move as quickly as the rest if done right.
Organisations should also consider moving to a consolidated web application and API security solution that provides consistent protection and integrations across disparate application architectures and environments once the app or API is in production.
