State of Application Strategy: Who Should Drive Your API Security Strategy?
There are at least three good answers and some not so good ones.
Strategy, particularly when it comes to technology, is often laid on the shoulders of executives. When it comes to security-related strategies, that’s often the CISO or, if there is no such role, the CIO.
But some organizations delegate responsibility for driving API security strategies to other roles. Developers, SREs, and even network professionals might own the strategy for securing APIs today.
Perhaps that’s because there’s no real research into what the results of those decisions might be. There are, after all, good reasons for developers to drive an API security strategy, just as there are good reasons to lay that responsibility on everyone who might touch an API is some way, whether during development, testing, or production.
In our recent research digging into API security, we asked each of our respondents—all API security decision makers—which roles in their organization were responsible for driving API security strategy. We found a mix of responses, from developers to network professionals to cross-organizational approaches.
But we also asked some nitty-gritty details about the types of security services organizations use to secure APIs. These are services like DDoS protection, access control, mTLS, and SSL. We used deployment of these services as a tangible representation of strategic execution because they are some of the controls needed to enforce policies derived from a security strategy. Then we looked at which of those services were deployed based on who drives API security strategy.
Quite frankly, we were stunned by the results.
It turns out that the most comprehensive set of services was deployed when API security strategy is a cross-organizational responsibility, closely followed by the more general Security organization, and the CIO/CISO leadership.
Perhaps more distressing is that when SREs drive security strategy, API security is not incorporated until the test phase of the API lifecycle. When other choices for leading API security strategy are made, incorporation of API security largely begins either in the design or development phases. Even when network teams drive API security strategy, they tell us development is the phase in which to incorporate API security.
Now, the good news is that most organizations designate responsibility for defining API security strategy to one of those three. A mere 8% hand it off to developers, even fewer (3%) expect network professionals to handle it, and only 1% assign this task to SREs.
This closely aligns with the domain to which API security is assigned. Because that decision is largely influenced by who drives the strategy. When API security strategy is driven by CIO/CISO leadership or considered cross-organizational, API security winds up being distributed across four typical domains: API management, application security, network, and in security but separate from application security. Given that the services that defend and protect APIs can span multiple domains, that makes sense.
So if your organization assigns API security strategy to the CIO/CISO leadership, Security, or considers it a cross-organizational responsibility, congratulations! Your strategic approach is leading to comprehensive security controls through security services that defend and protect APIs from a wide variety of attacks.
You can dig even deeper into the secret lives of APIs by reading today’s press release and grabbing our latest report. Inside you’ll find more scary statistics, but also learn more about the ways that APIs are actually used inside the enterprise as well as the security capabilities organizations consider important to keeping APIs safe.