Techniques to Mature Platform Security

If you’re into building with APIs, you’re probably introducing new software architecture to bring scalability and efficiency advancements. But are you introducing insecurities as well? As digital ecosystems mature, so must cybersecurity. Especially for large platforms with externalized resources, data breaches should be expected, and API vulnerabilities must be mitigated before a breach occurs.

To combat these prevalent issues, we recently assembled three expert speakers in our Maturing Platform Security LiveCast. This hour-long webinar features API security experts Jacob Ideskog, VP, and identity expert at Curity, Dr. Keith Casey, API Problem Solver at Okta, and Himanshu Kumar, MTS API Security, and Design at T-Mobile.

Below, we cover the main takeaways from this expert dialogue and demonstrate how identity handling and proper testing can mature API platforms at scale. We’ll cover a maturity ladder for API security, practical handling of scopes in a real-world enterprise environment, and thinking like a bad guy to attack your own APIs.

Watch the Maturing Platform Security LiveCast here:

First, What is API Security Maturity?

Jacob Ideskog works with OpenID Connect and OAuth every day, building OAuth servers and authentication mechanisms at Curity. Throughout his work, he’s seen all types of API security approaches, from HTTP Basic Auth, API Keys, to JWTs and advanced OAuth flows. Naturally, some methods are better than others.

According to Jacob, understanding platform security starts with understanding where your platform lies on The API Security Maturity Model. Borrowing ideas from the REST Richardson Maturity Model, The API Security Maturity Model defines a spectrum of API security models. It shows how secure a platform is and offers a step-by-step ladder to improve.

Jacob Ideskog describes how to assess the maturity of your API security approach with a helpful model.

The API Security Maturity Model starts at Level Zero. At Level Zero, the platform only uses API keys or basic authentication. To Jacob, this is a legacy, insecure method because it only verifies that one machine can talk to another machine; it doesn’t bind the user to the requested resource. User information, passed within HTTP requests, remains unasserted. It’s authentication only, without authorization.

Level One introduces token-based authentication with an OAuth server. OAuth flows involve the users to authenticate and grant access with a bearer token, making the user part of the authentication mechanism. Level One is a good start, as it binds the user to the request, but this approach still doesn’t verify authorization, i.e., “WHAT you’re allowed to do.” Level One also struggles to separate roles between groups, such as backend versus external users.

Level Two introduces OAuth Scopes. These hold named “permissions,” which can be used to assign access roles. Jacob details how an eCommerce shop could use scopes to assign specific roles, such as inventory_read read or billing_write. These scopes are embedded within the token. Level Two locks down the application, binding user permissions. Unfortunately, Scopes are still application-bound, not user-bound. This model also leads to an unintended chain of trust.

Lastly, Level Three is the final step in the API Security Maturity Model. Here, we introduce centralized trust using Claims. According to Jacob, a Claim is “a property about a subject asserted by a party.” By embedding Claims into Access Tokens (like account IDs, or user types), the OAuth server can look up identity details and centralize this security.

Centralized trust using claims is “the place you want to get to in order to mature your API Security model,” says Jacob. With this approach, authorization is uniform and reliable, and attack vectors (or room for honest mistakes) are significantly reduced.

Case Study: Zero Trust Communication at T-Mobile

Himanshu Kumar demonstrates how OAuth Scopes can be used alongside a Zero Trust Model.

Himanshu Kumar agrees that user-binded tokens and Scopes provide a high level of security maturity. Within our LiveCast, Himanshu built on Jacob’s ideas to discuss how OpenID Connect and OAuth Scopes are being applied within an enterprise-level situation to enable federated endpoint security.

Himanshu acknowledges how you may encounter problems when introducing Scope usage. For one, he recognizes that, for user experience reasons, scopes don’t always reflect user-selected Scopes. He recognizes other issues universally interpreting Scopes, and leveraging Scopes for endpoint access authorization.

In enterprise environments, an Identity Server typically grants an application to make calls on behalf of a user. Within this environment, Scopes are made to represent domain-driven endpoint functionalities; as Himanshu says, “a union of the User & Application Client.” Himanshu describes how to adopt two token types: an Access Token for endpoint authorization, and Identity Token for user-level data authorization.

If a company has thousands of API endpoints and hundreds of domains, there will be many cross-domain API dependencies. So, how can we approach this while retaining security? Himanshu recommends adopting the Zero Trust Model, in which access tokens must be re-issued to cross domains.

Himanshu also stresses the importance of governance for OAuth Scopes and access token previews. One aspect of this is naming conventions for Scopes. At T-mobile, they are defined with three segments as such: <domain-name>:<resource/function>:<action>. An example would be is ecommerce:orders:read. Watch the entire presentation for Himanshu’s further thoughts on Scope governance, Token flow, and optimization techniques.

How Scopes are managed in an enterprise setting.

Dawning the Black Hat

Whereas our first two speakers seek to improve API security, Keith Casey aims to destroy it.

As an API Problem Solver at Okta, Dr. Keith Casey Jr “lives and breathes” OAuth and customer security problems. In his talk, “Practical Privacy, and Adversarial Approach,” Keith examines how flirting with the dark side can reveal unseen vulnerabilities.

But first, to consider how vulnerabilities arise, let’s go to the root issue. An API is typically developed in-house to solve some sort of operational problem. It’s used by a single team. Eventually, interest in the API grows, as more teams see the benefit in its use, and usage expands across an organization.

Now, here is when a major shift occurs: product-oriented folks see business potential in the integration, and they push to open it up for partners. Thinking around the API begins to change from an internal mechanism to an API-as-a-product. Now, we have hundreds of external developers consuming an API that was originally intended for a minimal internal use case. See the dilemma?

According to Keith, too often, security teams are only made aware of the API right before it is externalized. Developers often don’t build from an external-facing viewpoint. Thus vulnerabilities are often hard-coded. Keith sees many dilemmas in this typical progression.

“Fundamentally, we should realize that as our APIs are successful, they are going to grow in usage,” says Keith. “If we don’t take these concerns early on, they will cause catastrophic problems later on.” It seems there are security benefits in following the Amazon philosophy of building for externalization from day one.

To rectify gaps, owners must consider security before the product phase, and alongside development. Imagine you are an attacker. How would you misuse and abuse an API? By taking this perspective with your own services, product owners can learn a ton and better arm their services.

Keith recommends API developers literally attack the Authentication & Authorization modes, endpoints, and payloads. Here are some ways to bang up your API:

Authentication

Test your API keys: Are character strings long enough? How are they secured?
Test your scopes: Are scopes actually reflective of the permissions they grant?
Fuzz your scopes: If we combine Scopes does that bring negative results? Are there mismatches between systems?

Endpoints

Use garbage data: What happens if we feed it enormous request packages? Try to cripple systems.
Explore endpoints: Use Open API & Hypermedia to discover endpoints. Generate random URLs to find “secret” endpoints.
Try every verb: Does using the OPTIONS HTTP method cause an unexpected result?

Payload

Increment the IDs: Literally add “1” to customer IDs.
Review error messages: Consider if error messages are giving away too much information.
Try every verb: Feed complex payloads with nuanced HTTTP Verbs.

Keith adds that performing these actions should trigger many API monitoring alerts. If not, it’s a sign your DevSecOps processes aren’t running as smoothly as they should.

By dawning the black hat to take an adversarial approach, you will likely find vulnerabilities you hadn’t considered (as the “kind user” you are), and you’ll discover information your API is unintendedly exposing. You may have a little fun as well.

Keith adds how it’s better to “attack our API with the people we trust.” Because if you don’t, somebody else will.

Takeaways From Maturing Platform Security

Continual exploits clearly demonstrate a lack of security maturity across the industry, underscoring the need for more security forethought. In this webinar, we got a glimpse of how API providers can advance their security with established approaches. Some key takeaways include: