Forem: Jamie Beckland

Why Every Level of the API Context Maturity Model Matters

Jamie Beckland — Wed, 06 Sep 2023 09:00:00 +0000

By: Mayur Upadhyaya & Jamie Beckland

Welcome back to our ongoing exploration of the API Context Maturity Model. As we've navigated the diverse landscape of API maturity, it's become clear that each level, from open public API calls to open standards compliance, holds unique value and challenges. Today, we'll delve into why every level of our API Maturity Model is crucial to your organization's API security and effectiveness.

The Foundation: Open, Public API Calls

At Level 0, open public API calls form the bedrock of the API journey. An executive from a global retailer emphasized that while this level offers ease of accessibility and innovation, it's a double-edged sword, with potential data exposure risks. This level matters because it's where organizations learn the fundamentals of APIs and the inherent necessity for effective management tools, like Contxt.

Showing Progress: Authenticated API Calls

Next, we see authenticated API calls at Level 1. This level introduces a layer of security, helping to verify who is accessing the APIs. However, as the representative from an Oil and Gas multinational highlighted, it's not without its challenges, particularly around creating user-friendly authentication measures. This stage is vital as it emphasizes the importance of balancing user experience with robust security.

A Power Shift: Authorized API Calls

Moving to Level 2, the introduction of authorization adds another dimension to API security. Here, organizations learn to manage not just who can access APIs, but also what they can do. The Head of Engineering from a data scaleup shared the complexities of implementing granular access controls, underlining why this level is crucial for organizations to master.

Toward Clarity: Purpose and Use Defined

Level 3 ushers in a significant shift where organizations define the purpose and use of their APIs. As a finance expert recounted, this step is critical to ensure compliance, especially under regulations like GDPR. This level, therefore, is pivotal in helping organizations understand the importance of transparency and control in their API strategy.

The Culmination: Open Standards Compliance

Finally, at Level 4, organizations grapple with open standards compliance. This level is the zenith of API maturity, where the focus is on ensuring APIs are not just secure but also interoperable and forward-compatible. The CTO of a tech enterprise underscored the challenges and the imperative nature of adopting these standards.

The journey through the API Context Maturity Model is more than just a progressive roadmap. It's a recognition that each level presents opportunities for growth and learning. As organizations move through these stages, they learn to manage APIs more effectively and securely, preparing themselves for the ever-evolving landscape of API-driven innovation.

Throughout this journey, Contxt is your trusted partner, providing the tools and insights needed at each level. Remember, every level matters because each one adds a layer of understanding, security, and effectiveness to your API strategy, leading to a more robust, compliant, and future-proof API ecosystem.

New U.S. Regulations Highlight the Importance of Collecting Personal Data Purpose and Use

Jamie Beckland — Thu, 31 Aug 2023 15:00:44 +0000

Today, the White House hosted a roundtable on data broker practices that harm consumer privacy, in particular, selling “credit header data,” which can contain sensitive personal information such as name, Social Security number, and date of birth. Simultaneously, the Consumer Financial Protection Bureau (CFPB) announced it will propose new regulations to limit the operations of data brokers under the Fair Credit Reporting Act (FCRA). This move aims to safeguard consumer rights and privacy while bringing data brokers under more stringent control.

Data brokers vacuum up and sell personal information, often without our explicit consent, and sometimes even without our knowledge or awareness. These brokers often rely on data with an unknowable chain of custody, mixing together data from a variety of sources, and often relying on blanket permissions from parties that are not authorized to grant them.

The CFPB’s initiative reinforces the need for high quality data collection practices, in particular, the need to collect purpose and use consent alongside data attributes. Many digital product owners would never consider selling their customer data, but the reality is that personal data often leaks from poorly constructed and monitored APIs.

Internal and external teams often have access to sensitive data over APIs, including marketing and data analytics teams. These new rules further highlight the need to limit customer data exposure with better tooling.

This comes on the heels of the Securities and Exchange Commission (SEC) adopting new rules earlier this month that require companies to disclose cybersecurity incidents on Form 8-K within just four business days.

There’s no question the regulatory cost of mishandling sensitive customer data is increasing.

For most API product teams, the challenge has been they don’t have a good understanding of API misconfigurations; and they can’t control data flow at a granular enough level.

At Contxt, we know that trust starts with discovery. Our first step is always to understand what data actually flows over your APIs.

Once we have established a baseline, we empower you to collect and document the intended purpose of data usage. This aligns with the CFPB's goal of ensuring companies comply with authorized data uses, as specified by the FCRA.

Then, Contxt's capabilities extend beyond data collection and reporting. We enable you to enforce proper usage downstream, ensuring that the data's purpose remains consistent throughout its journey.

To learn more about Contxt's capabilities and how we can help your business prepare for the dynamic regulatory environment, sign up for an account for free.

Ask the Experts: Understanding the API Context Maturity Model - Level 4 - Open Standards Compliant API Calls

Jamie Beckland — Wed, 23 Aug 2023 09:00:00 +0000

By: Mayur Upadhyaya & Jamie Beckland

Welcome to the final stage of our API Context Maturity Model journey - Level 4, where Open Standards Compliance reigns. It is at this stage that organizations reach the pinnacle of API maturity, where the established API ecosystem adheres to recognized industry standards.

In order to share key comments from the hundreds of technology leaders we consulted to develop the Context Maturity Model, we have anonymized their thoughts to give you the most unfiltered view.

Adhering to open standards means the API calls are designed and operated in accordance with accepted industry best practices. These standards include mechanisms to ensure secure data transmission, robust authentication protocols, and well-defined data structures.

A technology lead from a global financial services firm shared, "Adopting open standards helped us establish a common language and baseline for security within our API infrastructure. It's like a safety net that ensures we're following best practices."

However, transitioning to Level 4 is not without its challenges. It demands an in-depth understanding of the standards, significant alignment effort, and continuous monitoring for adherence.

A cybersecurity executive from a multinational logistics company explained their journey: "It was a massive task to align our existing API landscape to open standards. We found a few gaps during the transition, but it also helped us to uncover some hidden vulnerabilities."

Achieving Level 4 maturity not only improves API security but also enhances interoperability, a significant advantage in today's increasingly interconnected world. It is the realization of a robust, secure, and efficient API ecosystem.

While it's important to aim for Level 4 maturity, the journey through each level provides invaluable insights. With each step, organizations become more aware of their API ecosystem, uncovering vulnerabilities and enhancing security measures.

This marks the conclusion of our 'Ask the Experts' series on the API Context Maturity Model. We've examined each level, the benefits, and challenges involved, and shared expert insights. No matter where you are in your API journey, remember that the aim is continuous improvement and security. As always, we encourage you to reach out with any questions or thoughts on your API journey.

Ask the Experts: Understanding the API Context Maturity Model - Level 2 - Authorized API Calls

Jamie Beckland — Wed, 09 Aug 2023 09:00:00 +0000

By: Mayur Upadhyaya & Jamie Beckland

Welcome back to our 'Ask the Experts: Understanding the API Context Maturity Model' series. We've made our way up from open public API calls to authenticated API calls, and now we're ready to unpack Level 2 - Authorized API Calls. As a reminder, we have distilled key comments from the hundreds of technology leaders we consulted to develop the Context Maturity Model, and we are sharing their thoughts anonymously to give you the most unfiltered view of the current state of APIs.

After establishing an authentication system at Level 1, the next challenge for organizations is to establish an authorization system. With authorization in place, API calls can be made by authenticated users with specific permissions. This reduces the risk of users accessing data or functions that they aren't supposed to, adding another layer of security and control to the API environment.

A CTO of a fintech start-up shared their experience moving to Level 2. "After incorporating authentication measures, we soon realized the need for further granularity in API access. We needed to ensure that authenticated users could only access data and functions relevant to their roles. Transitioning to authorized API calls helped us achieve that."

This level of authorization is crucial in environments where data sensitivity varies or where roles differ significantly in their access requirements. For instance, an executive at a multinational banking corporation highlighted how implementing authorization measures was a game-changer in their highly regulated industry.

They said, "In our industry, data sensitivity varies enormously, and so does role-based access requirements. With authorized API calls, we were able to ensure that our employees could access only the data and functions that were pertinent to their work. This move dramatically improved our data security posture."

However, like every step in the maturity model, Level 2 comes with its own set of challenges. The more granular the access control, the more complex the system can become. Organizations often struggle with managing a large number of roles and permissions, which can lead to misconfigurations.

In our next post, we'll delve into Level 3 - Purpose and Use Defined API Calls, where we will discuss how organizations can deal with complex role and permission challenges by defining the purpose and use of each API call.

Till then, stay tuned, and as always, feel free to reach out for more insights on API security and best practices.

Ask the Experts: Understanding the API Context Maturity Model - Level 0 - Open, Public API Calls

Jamie Beckland — Fri, 28 Jul 2023 09:00:00 +0000

By: Mayur Upadhyaya & Jamie Beckland

Welcome to our new series, 'Ask the Experts: Understanding the API Context Maturity Model.' In the course of developing the Context Maturity Model, we spoke with hundreds of technology leaders across a variety of industries. In this series, we hear from some of these experts in their own words. Throughout this series, we will share their candid thoughts and feedback anonymously, to give you the most unfiltered view of the current state of APIs.

Our journey begins at Level 0 - Open, Public API Calls. APIs at this level are accessible to anyone and can be called freely. They serve as the foundation for organizations entering the realm of APIs, creating an open-ended environment for data sharing but also posing significant potential risks.

A technology lead at a multinational oil and gas company offered insight into their experience at this level. He noted, "APIs initially seemed like a simple way to share data and establish connections. However, we quickly realized that without proper control measures, our exposure to risk was far greater than necessary."

These sentiments underscore the trade-offs businesses must consider at Level 0. While open, public API calls can accelerate digital transformation, they also emphasize the importance of implementing secure API practices from the outset.

Another perspective came from a manager at a global retailer, who described an incident where public access to an API led to its misuse and unnecessary exposure of a significant amount of data. This experience further highlights the potential pitfalls at this level.

Open, public API calls are incredibly useful, but they should only be used once you have confirmed that there is no risk of proprietary or sensitive data leaks.

As we progress through the Context Maturity Model in subsequent posts, we will explore how to navigate these challenges and adopt more secure and sophisticated API practices. The journey from open, public API calls to achieving open standards compliance has many considerations, but by understanding each level's unique challenges, your organization can confidently navigate the path to API maturity.

Join us in our next post as we delve into Level 1 - Authenticated API Calls. As always, if you'd like more information on API security and best practices, feel free to reach out. We're here to help!

Introducing the API Context Maturity Model

Jamie Beckland — Mon, 12 Jun 2023 23:00:00 +0000

By: Mayur Upadhyaya and Jamie Beckland

Every API call has context around it.

Who is making the API call?
What data are they requesting or attempting to post?
Is that data public or private?
Do we need to check with anyone else before permitting the request?
Does the data transfer have any legal or ethical considerations or constraints?

Our goal should be to provide the right response, in the right context, every time.

But, for the past decade, APIs have moved at the speed of business. APIs have grown so quickly because they have proven their value in creating flexibility and functionality. The cost, however, has been with inconsistent security, privacy, and performance rigor.

That’s why there have been so many data issues, breaches, and leaky APIs recently. Bad actors know that the APIs are the weak link in protecting your customers’ and your business’ data assets.

Our approach to API context maturity comes from understanding that you are building the plane while you fly it. You need to move quickly, and enable teams to deliver business objectives. One approach is to slow teams down by asking them to be experts in security and privacy (in addition to all of the other functions that they need to be experts in).

We think you get better outcomes faster when you ensure that there are adequate guardrails, so teams can’t make egregious mistakes, while maintaining velocity.

Then, incrementally, we can raise the guardrails to enforce higher standards for use cases where more protection is necessary.

The API Context Maturity Model breaks down building and maintaining APIs with an increasingly sophisticated understanding of the context surrounding the API call.

Level 0 - Open, public API calls. These calls require no information from the requester before delivering a response. This may be totally appropriate for many (or most!) API calls. An API call that delivers weather for a location, or the cost of a flight, may not need any special protections, and Level 0 works well. It is fast and efficient, and ensures that the barrier to deploy and maintain these services is as low as possible. However, if an API call contains personal or sensitive data, or if it requires authentication, Level 0 is not appropriate.

Level 1 - Authenticated API calls. These calls have an understanding of who the requester is, and can provide information specific to that requester. There are lots of reasons that an API call should be authenticated. Perhaps a customer wants to know information about their account. Or you need to monitor the usage of the API call, so you need to understand how much each user is calling the service. Or there is proprietary pricing and inventory information that you only want to expose to certain employees and partners. Regardless of the reason, any API that needs to be authenticated should have validation of authentication every time it is delivered. There are many ways to authenticate an API call, and different levels of authentication should apply to different APIs.

Level 2 - Authorized API calls. These calls have specific permissions and requester expectations attached to them. For example, maybe you offer different bulk pricing discounts to different partners, based on the level of commercial relationship. You want to make sure that pricing information is not shared with every user and system from the partner, but customize the response based on the authorization scope. Another example is when you have different services calling the same API endpoint, and want to return different information. If your get_customers endpoint is used by your internal analytics tool, you may want to share birthdate, mailing address, and other personal information. But, when your advertising partners call that same endpoint, you need to reduce the scope of the payload to avoid sharing PII.

Level 3 - Purpose and use defined. These calls rely on an understanding of why and how the data in the payload will be used. Perhaps the subject of the data request needs to consent for the requester to have the data, or to use the data in certain ways. You may need to collect consent from a patient to share their health data with their doctor or other provider. Or, with proper customer consent, you actually can share PII with advertisers.

Level 4 - Open standards compliant. These calls are critical to core business operations, and as such, they need to conform to rigorous public standards. In many markets, standards that have been developed and hardened in public working groups are now being adopted as regulatory requirements for operations. Regulators in finance, health, and other areas may want to periodically review API calls to ensure compliance.

The API Context Maturity Model requires an understanding of each individual API call; and also of the specific circumstances of that call. As APIs move through the levels in the model, the complexity to and assurance does not go up linearly. It is much more complex to interpret changing regulations than simple authentication.

But, the framework provides a glidepath for Enterprises to incrementally improve their risk posture, and demonstrate conformance quickly.

Implementing this maturity model becomes dramatically easier when you have an accurate understanding of your existing APIs, because the highest risk becomes clear quickly.

Existing API Maturity Models - Overview and Limitations

Jamie Beckland — Mon, 05 Jun 2023 15:13:20 +0000

In 2023, it seems that every company is in the middle of an API transformation. Which makes sense, after all, because APIs have become the primary mode of communication for all connected services. And as a result, they are the primary attack vector for bad actors online. Teams need to up their API security, and quickly.

Once you start building a work program, however, you quickly find that there are many competing approaches to putting order and structure to your API estate. Some options include:

Richardson Maturity Model

The (Leonard) Richardson Maturity Model defines four levels of API maturity:

Level 0 - No APIs: At this level, there are no APIs in place, and all data exchange happens through a user interface or direct database access.

Level 1 - Resources: At this level, APIs are designed as basic resource endpoints. They are accessed over HTTP and can be thought of as simple web pages that provide information.

Level 2 - HTTP Verbs: At this level, APIs are designed to use HTTP verbs such as GET, POST, PUT, and DELETE to perform operations on resources.

Level 3 - Hypermedia Controls: At this level, APIs are designed to include hypermedia controls, which provide links to related resources and enable clients to discover and navigate the API dynamically.

The Richardson model is not very useful for making a plan to organize and secure an existing set of APIs for an enterprise, because it looks at API development and management as a linear pattern. But, most organizations have multiple teams and applications, with varied maturity and resourcing, which means that your API status will always contain elements at all four levels.

APIOps Cycles

The APIOps Cycles, created by Marjukka Niinioja, Jarkko Moilanen, and others, is a framework that focuses on the entire API lifecycle, from design to retirement. It’s focused on a product development and product management approach to API design and construction. It consists of eight stages:

Business First with API Canvas - This stage is focused on aligning business needs and customer journeys.

Mind the Developer Experience - In this stage, the focus is on making sure your APIs can be found, used, and supported.

Minimum Viable API Architecture - This stage is focused on making nonfunctional requirements as easy to accomplish as possible.

Build APIs - Here, the work is focused on designing simple-to-use interaction models, focusing on design styles and open standards.

API Audit - In this stage, APIs are compared against checklists of the previous stages as well as security.

Publish API - Here, the team makes the API available for the first time.

Monitor, Measure, and Analyze - This stage is focused on collecting metrics and KPIs to understand how your APIs are being used.

Learn and Improve - This final stage is about speeding up cycle time and improving quality of the APIs incrementally.

The APIOps Cycles framework emphasizes the importance of a holistic approach to API development and management, where each stage builds upon the previous one. It comes from lean/agile product development, and is focused on building APIs as products. This is very useful if you are mapping how mature your API development process is, but it doesn’t give you any information on the quality and maturity of the APIs themselves. The best development methodology can still create security and privacy vulnerabilities.

The API Security Maturity Model

Jacob Idesvog shared his API Security Maturity Model in 2019, as a response to trying to articulate the increased security risk from the proliferation of inadequate API construction and management. It has four phases:

Level 0: API Keys and Basic Authentication - If an API request presents an API key, then that key should be valid and should be trusted. It does not question the resources making the calls to the API at all.

Level 1: Token-Based Authentication - When an API call is accompanied with a token, the token can be used to authenticate the requestor before providing a response.

Level 2: Token-Based Authorization - In addition to an authentication, the API call is also expected to include a token that authorizes the requester to take certain actions (and to prevent them from taking other actions). This allows a lot of granularity in validating requests before delivering responses.

Level 3: Centralized Trust Using Claims - By introducing claims of veracity, we give the API the ability to independently assess the veracity of the authorization. Signed JSON Web Tokens (JWTs) are commonly used to present to share claims by using their in-built scopes capability. Third parties can leverage encrypted keys to validate payloads even after they are delivered.

Again, this model is useful when thinking through how to build and maintain protected API services. But, it falls short when we try to understand where risk lies within our existing environments. This model tells us what to do to make our APIs more secure, but it doesn’t tell us what APIs most need protecting, and to what extent.

A Different Approach

At Contxt, we know that most companies must move quickly into an API-first IT model. External products, internal applications, and backend services all use APIs, and they are in various states of maturity at any given time.

Several years ago, it was helpful to evaluate your APIs against these models to help you build APIs quickly and with high confidence.

But now that you are managing so many live API systems, attentions are turning toward identifying and remediating risky API construction, data transfer, and permissions.

Coming soon, we will share our model for API maturity, that is focused on building a mature monitoring, detection and response capability for APIs that we must have, but can never fully control.

Best practice is to send PII using POST, not GET…so why don’t more developers do it?

Jamie Beckland — Thu, 23 Mar 2023 16:33:02 +0000

One of the first principles developers learn when writing REST APIs is to use GET for retrieving data and POST for modifying data.

Except, of course, GET exposes the parameters in the URL directly. And we never want to expose sensitive data like user credentials, PII, or PIFI. So they immediately must un-learn what they have learned, and put sensitive data in the body, using POST, to provide a slightly better default security and privacy posture.

In an attempt to mitigate the risk, some organizations create policies to make using GET requests so cumbersome to deploy - with additional security checks and review queues - that they effectively ban them from use.

Which, in turn, creates downstream problems. When all the requests are POST, then all the requests can modify the data. This gives many API users a lot of discretion and power.

In the end, of course, the right way to solve the problem is to tokenize sensitive data, so it can be transmitted using any API call.

But, as applications improve tokenization and context-awareness, we are left with a patchwork of half-secure, mostly-private applications talking to each other. Older applications may run on SSL or an outdated version of TLS. Rogue application developers may find ways to accidentally push unsecured http requests live. Relay APIs may sit outside of the security perimeter.

In addition, external API consumers may only have GET permissions, they can consume data but they can’t change it. Or, an API call may not have a specific method defined, in which case many services will assume the request should be a GET request.

If only one element is misconfigured, personal data is exposed, which is a security breach and also a privacy breach.

It’s critical to improve the awareness and visibility of these security and privacy gaps, in order to make incremental improvements across the entire system. We need to be able to fixing privacy and security in post…by monitoring how actual calls are made in real, live operational systems.

Revised OWASP Top Ten shows how companies that live by the API also risk dying by the API

Jamie Beckland — Thu, 23 Mar 2023 16:32:41 +0000

Recently, the OWASP Foundation updated their list of the top 10 most common web application vulnerabilities, aka the OWASP Top Ten. The new list is an update from the previous version, published in 2017, and was driven by the dramatic pace of change in web application development and the behaviors of bad actors.

Here’s the full list of changes:

OWASP Top Ten 2017 compared to OWASP Top Ten 2022

There is not much in the way of good news. While several issues have been consolidated, like Cross-Site Scripting and Insecure Deserialization, none have dropped off the top ten list entirely. That means that the risks from 2017 are still risks today.

But, in addition, there are several new risks and several risks that are placed much higher than previously. Broadly speaking, that is because the risks of APIs have never been adequately managed, even while their popularity continues to explode.

In fact, due to the rise of microservices, new digital businesses, and cloud deployments, APIs are now 83% of all internet traffic.

We have clearly passed the tipping point where APIs are critical operational elements in a technology stack. Which means they are a more attractive target than ever for bad actors.

In short, as more and more companies live by the API, they also run the risk of dying by the API.

To make things even more challenging, legacy security applications do a poor job managing these new vulnerabilities. It’s no longer enough to track the volume of API calls to identify a DDOS attack based on scale alone. Today’s attackers can probe slowly, and under the radar of brute force monitoring.

The best solution would be for development teams who deeply understand their own application logic to instill security best practices consistently and perfectly. The “shift left” movement is improving tooling and education, but the reality is that business results can’t wait for millions of developers to collectively raise the bar for building secure applications.

That’s why it’s necessary to continue to shield applications in the wild with a coherent security monitoring strategy. As attacks get more sophisticated, our responses must also become more sophisticated. For most security teams, that means getting deeper into the API logic and capabilities, testing and probing to find vulnerabilities before bad actors do.

We will expand on several of the OWASP top ten vulnerabilities over a series of blog posts, identifying both why these issues are more prevalent than ever, and also what to do about them. Stay tuned for more.

API security is now more important than web application security

Jamie Beckland — Thu, 23 Mar 2023 16:31:31 +0000

We have been reviewing the OWASP Top Ten in some detail, which is the premier index of the most critical vulnerabilities in web applications.

But, in 2019, the OWASP Foundation found that their traditional web application security vulnerability was simply not advanced enough to bring visibility to the fastest growing threat categories: API vulnerabilities.

So, in response, the foundation published its first-ever API Top Ten. It’s quite staggering. Between 2017 and 2021, the vulnerability posture of APIs grew to overtake the traditional web application, to the extent that even the web application vulnerabilities often overlap with API vulnerabilities.

In fact, if APIs were fully secured, it’s likely that web application breaches would fall by at least 66%.

So, as an extension of our security vulnerabilities overview, we will extend and expand to review many of the OWASP API Top Ten.

Since the majority of all internet traffic is over APIs, it makes sense that we would want to prioritize improving and hardening APIs above even many traditional web application vulnerabilities. APIs are more often exploited, and their preference as an attack vector continues to grow for bad actors.

Stay tuned for a more detailed review of these risks and how to manage them without paralyzing your customer-facing initiatives.