API Security Is a Team Sport

I had the opportunity to catch up with Keith Casey, API Problem Solver at Okta during Oktane19.

Here's what he had to say about the current and future state of API security.

How has API security changed in the past year?

"We're seeing a lot more attacks and the scale is still growing. While we haven’t reached a turning point, we are beginning to see API security become a team sport as evidenced by what happened at T-Mobile. The telecom company has 77 million customers. It was hacked and someone was trying to download their customer base. SecOps saw what was happening and shut it down. While a few million records were compromised, they stopped the exfiltration in progress protecting many millions of more records. Security and operations knew what normal looked like and stopped the attack in progress.

I’d look forward to seeing more examples of security and operations working together. I've been pushing for security to be a team sport for past two-plus years. Developers cannot just ship code, throw it over the wall and hope for the best. Security, operations, and DevSecOps need to know what’s normal, what’s not normal, and respond accordingly.

We've been trying to partner with others to plug in information and intelligence. If we can stop an attack that’s coming through an access token and we know the common pattern for an access token, we may be able to stop without the gateway or the API ever seeing the traffic."

What are the most common API security failures you see?

"The biggest in terms of use cases is the limited view developers and SecOps have of how people will use their APIs. They think they have a complete understanding of the use cases but, in reality, only have one or two. People are constrained by their lack of imagination. I encourage SecOps to sit down with the development team and trusted customers to discuss what they are planning to do that may result in new use cases. On the security side I tell people to sit down with developers to learn how bad was it at their last place, what bad things have you seen that required you to bring legal and compliance to discuss it.

Write a Black Mirror episode. Take your technology and apply a twist to it to determine how can this be used in horrible awful ways to damage our company, industry, and other people."

What are some use cases you’d like to highlight?

"One of the patterns we’ve seen as more and more are companies launched APIs, different teams move at different speeds, so they launch with different architectures, different API gateways, out of different cloud providers. It’s a mishmash of everything, so being able to plug into every single gateway across the board and centralize that authentication across the user store and authorization policies have been fantastic.

We work with a number of customers. We don’t care what platform or gateway they're using, as long as they plug-in Okta, it’s part of the open platform solution."

What announcement at Oktane19 are you most excited about?

My favorite is Advanced Server Access. We were founded doing SSO for applications that’s what we’re known for. With API access management two years ago, we’ve got API access management behind the scenes, we can protect applications and APIs. Now with Advanced Server Access, you have the individual containers protected so we can now protect the servers APIs are running on as well.

Behind the scenes, the open SSA protocol allows you to authenticate with a certificate so when you deploy this container you can configure us as a certificate authority, which means instead of using a user name and password, you use a certificate that's good for three minutes to log into the server and then the certificate expires.

So now, we can protect everything. We’re using standards across the board and all powered by SAML, OIDC, OAuth, SSH behind the scenes all powered by Universal Directory, so you have one source of truth on who has access to what and behind that you have a Syslog that you plug into the SIM so the Ops team can ask why you need access to this.

You get a complete view of everything going on across your system. It’s all open standards, so you won’t have to rip and replace in five years"

What do you think developers will be most interested in?

"Okta Hooks. We've broken our identity engine into five parts with defaults on each that can be replaced with the developers' own logic with the webhooks systems. That’s when things get interesting.

The more custom code, greater the opportunity for a bug or vulnerability. The most secure code you have is the code you don’t have to write. With Okta, you don’t have to write much custom code to accomplish great things."

What do developers need to keep in mind?

"Understand that you don’t have to rebuild every time, you can use APIs. However, more APIs mean bigger attack vectors. API security will gain awareness.

One of the most common things I run into is most developers think they know how OAuth and how the protocol works

Some people decide to implement it themselves. I received an email this morning “I want to build an OAuth server, where should I start?”

I urge people to do what you know but acknowledge what don’t know. Be willing to defer to people who do this as a living. We’ve had major customers that have wanted to build their own OAuth libraries. I say, “Please don’t.”

At Okta, we use the app auth libraries which are led by Google we support them, we are contributors that’s the gold standard for mobile.

A major finance company was going to roll their own. I suggested for them to do a security audit of what’s out there. Gain confidence in what’s out there or find issues and call them out to the developers. When you identify and fix vulnerabilities, the community as a whole improves. They practiced responsible disclosure and went to the developers to resolve the bugs.

The finance company got SDKs that worked for them for a fraction of the cost of building something for themselves and the ecosystem is improved as well. Have a feel for what you are working with and don’t roll your own. We don’t need another and you don’t want the risk of building it yourself and increasing your liability."

What else?

"The community as a whole is trying different solutions and people are evaluating API gateways to come up with one solution for every use case. I think that’s a broken mindset

Realize up front that there is not one solution that is going to work for everything. Choose the best tool for the job, best of breed, it makes life easier.

I'm active in an API dev evangelist community along with product leaders from each major API gateway. Someone asked, “Which API gateway is best?” That led to many questions that you need to ask to determine your "best of breed" solution:

• What are you doing?

• What are you trying to accomplish?

• What is the infrastructure?

• Are you on-prem or in the cloud?

• Is it entirely in one place or another?

• Is it aggregating systems behind the scenes or is it a system you are putting this in front of?

Apigee a lot of great content that’s not self-promotional — how to evaluate, consider, and plan. 98 percent of the content is generic and super-useful. That’s why we wrote a guide on authentication. It's important to stay well informed and educated on best practices and not try to invent something from scratch."