With the meteoric rise in API attacks, someone needs to be responsible for securing APIs. One trouble is that “responsible” maintains nuances in meaning.

When someone says, “You’re responsible for getting this done,” they mean that person is supposed to supervise the project to completion.

When someone says, “I take full responsibility for this,” they often mean they’re taking charge of things.

When someone says, “You’re responsible for what happened,” they mean that person is held accountable for the bad thing that occurred.

So, “Who’s responsible for API security?” can mean different things. Let’s explore.

Supervision

As the reader probably expects, the answer for who’s responsible for supervision is, “It depends.”

The answer depends heavily on the organizational culture, not so much on organizational structure. Does the organization embrace a DevSecOps culture, where Developers, Security, and Operations work together and positively influence each other, and each person takes responsibility? Or, is it a culture where departments are siloed and have their territories marked? Are engineers afraid to fail for fear of retaliation (which means it’s not a true Agile environment)? Is it a “you made it, you fix it” culture?

When it comes to APIs, conditions are very wide-ranging. An organization might adopt a number of both public and private APIs and deploy them for different purposes. Because of this, there likely needs to be multiple owners responsible for API security.

Here’s a suggested chart (not comprehensive) of several roles and responsibilities involved in securing APIs. Keep in mind this is not the same as job positions, as not many will have enough revenue to support all these positions — a company could have a few positions that hold multiple roles, and some roles might even be filled by software. But these are roles that would benefit companies to designate to current positions, with the expectation of discovering where there are good fits and where new positions need to be created and hired for operating efficiency and effectiveness.

Since API security is so complex, the Parkerian Hexad might be more applicable than the traditional CIA (Confidentiality, Integrity, Availability) triad. The Parkerian Hexad contains the CIA triad and three additional components: Possession, Authenticity, and Utility. It’s essential to take a broad approach and focus on strategies and solutions to understand and mitigate API vulnerabilities.

Acquisition

If there’s no apparent supervision for APIs, this second aspect of responsibility will most likely be revealed (short of a breach) when an external party (e.g., pentester or bug bounty hunter) discloses one or more significant vulnerabilities. Someone needs to take the helm to fix the issues, and that person will surface.

The position might not be permanent, but someone will come to the fore to take responsibility for securing the APIs.

Accountability

What about when security goes very, very wrong? When there’s a breach, two entities are typically held responsible: the criminals and the C-Suite. An oft-used basic playbook is this: CEO gets named in media, Security Officer is forced to resign, SysAdmin gets fired.

When perusing articles about breaches, take note of who gets named. In the Equifax litigation, it wasn’t “the sysadmin” or “cloud architect” — it was “Equifax” leaders who were brought to court and “Equifax” who paid the fines. Those named were some of the C-Suite, and those were resignations or arrests. Members of the Chinese military were indicted, so Equifax was not guilty of a crime, but they did have to pay both financially and with a loss of reputation.

Also, consider the recent Okta breach. Okta’s CEO, Todd McKinnon, not any of the other employees, responded. The hacking group responsible for compromising the support engineer’s account showed screenshots that included trying to compromise Cloudflare. Who responded from Cloudflare? Matthew Prince, the CEO of Cloudflare, and David Bradbury, CSO.

While these incidents weren’t necessarily related to APIs, corporate leaders are responsible for responding to the public and legal authorities when a breach occurs. Think of the traditional ‘captain of the ship’ idea: if there’s a brawl on the ship or the crew is short on supplies, the captain is responsible due to ineffective leadership.

This article is not at all intended to cast blame, but to point out who shows up as responsible, publicly and legally, for security in the worst-case scenarios.

Challenges and The Future

Many hands make light work. When every person involved in the software lifecycle proceeds with security in mind, securing APIs becomes feasible.

GitLab’s 2021 DevSecOps Global Survey says: “A full 39% of developers feel fully responsible for security in their organizations (up from 28% last year), while 32% said they shared the burden with other teams. And the optimism about security improving is reflected by developers too: 75% said they feel their organizations make it possible for them to avoid breaches.”

In the day-to-day arena of developer security, which includes APIs, there’s an improvement in attitudes toward personal contribution to the process. Each organization needs to look critically at its business context, API ownership, resources, and actual hierarchy to determine how to properly secure the APIs used. But survey says — it’s possible.

What’s your next step in advancing API security in your organization?