Who owns API security and how do you decide how much is enough?

A few days ago I posted about the Nissan Leaf's Naked APIs. The enormity of having a totally naked API in the wild aside, I'm wondering how organizations assign responsibility for API security? And how do you decide how much security is 'enough'? Are API risks viewed any differently than other channel risks?

thanks

0 4 1,473
4 REPLIES 4

alan
Participant III

I think every company has their own "InfoSec" team that is responsible for security in general. Obviously, APIs that are meant to be used for external APIs need to have a much increased level of security reviews.

My best advice is that from a technology perspective, use the same technology stack for securing internal APIs that you would used for securing external APIs. I think this is where lots of companies get it wrong. For internal APIs, companies often leverage technologies such as VPNs to protect APIs within the firewall. When they want to externalize the APIs, then they have to "punch through" the VPNs, then implement totally different technology for securing the APIs. That leads to tonnes of rework, and dual security systems. If you use the same tech for internal as external from day 1, there is a lot less re-work and at the end of the day - you lower your Total Cost of Ownership.

Completely agree, treat all your APIs as external, you don't know what use cases might come up in the future that will mean you need to externalise todays 'internal' APIs

Not applicable

Hi David. I explored this topic in an article I just posted on the Apigee Forums. It got a bit larger than I had originally planned; so, I made it an article.

RCBJ

Not applicable

Its a classic question of "stability or instability" paradox. Who makes the security count for stability and who is responsible for instability (view breachs).

We do lot of consultancy in this space and answer this question . Everytime (mostly) the question is answered by who own the risk ?. For example if we have federated authentication using API Gateway , say OpenID trust link, we make the risk owner as API gateway owner. If its a public cloud authentication (IAM for eg). We make the shared-responsibility and the enterprise as risk owner.

And who own the risk, design the security (or delegate) .

For example , if we take the article on Nissan LEAF by @Robert C. Broeckelmann Jr. . And if we have mobile app that has the risk of using / consuming a malicious API - and outbreak because of it, still lies with enterprise B2B or user - B2C in general design patterns. Said this its always never black-white world , this needs a deliberation on business planning part of the API migration strategy.