[et_pb_section fb_built="1" admin_label="section" _builder_version="4.16" global_colors_info="{}"][et_pb_row admin_label="row" _builder_version="4.16" background_size="initial" background_position="top_left" background_repeat="repeat" global_colors_info="{}"][et_pb_column type="4_4" _builder_version="4.16" custom_padding="|||" global_colors_info="{}" custom_padding__hover="|||"][et_pb_text admin_label="Text" _builder_version="4.23" background_size="initial" background_position="top_left" background_repeat="repeat" hover_enabled="0" sticky_enabled="0"]

Overview

APIs have become the critical glue that binds together almost all of the applications and online services that the world now uses daily.

What hasn’t evolved as quickly as API usage itself, is the way that we secure these critical communication channels. The industry is beginning to catch on to the importance of API security and the available solutions have started to flourish, as have the terms, and concepts of what exactly API security is comprised of. This makes it increasingly difficult to not only have discussions about how we move forward as a community, but also for organizations to properly adopt API security and API security solutions.

The community needs to be able to have discussions about how to properly secure our APIs, and businesses need to be able to compare different solutions to see which ones meet their needs. To accomplish both of these objectives, the API security community should be having healthy conversations with an agreed-upon vocabulary and concepts about what is required.

The API Security Solution Framework

If everyone writes their own version of what is required, then it becomes a lot of noise and very hard to have productive conversations. A shared framework can help resolve this, so we are starting one that we can all iterate from and collaborate on.

To start this framework, we began to document what we believe are required capabilities. We’ve strived to be as impartial as possible (eg. if something made sense and it wasn’t in our product or product plans, it still made the list).

However, we’re sure that this isn’t complete or all correct. This is the first of many iterations and we expect it to improve as the collaboration and contributions grow.

The core of the framework is the capabilities. Each capability is classified either as “must have”, “should have”, or “nice to have”. The capabilities are organized into high-level use-case-based categories. We envision a healthy and productive dialog among all interested groups to refine this into a clear and useful framework that can be used to more fairly measure API security solutions.

Categories of API Security Solutions

API Security solutions encompass a wide set of needs that often fall across different roles, teams, and products. Organizing the API security requirements into value-based categories helps to keep the conversation focused on what value each category is meant to provide its users.

Some products might specialize in just one or two of these categories, while others might be broader, bringing together capabilities from several of these categories. This framework should be a useful assessment tool whether an organization chooses to implement API security using one product or many.

We can sort the framework capabilities into a few higher-level categories which are:

• API Discovery
• API Security Posture
• Runtime protection
• Security Insights
• Secure API Development

We’ll look at the must-haves and should-haves for each of these categories in the following sections.

API Discovery

The value of API discovery is in knowing what your total inventory of APIs is because this is your API attack surface. This is asset management for APIs. As development teams rapidly create new services and change existing ones, the APIs that these services provide and rely on can quickly become untracked and/or miss documented.

Understanding what APIs are being exposed and what APIs are being used is a critical step in securing your APIs. You can not protect what you don’t know about.

For good API discovery, a solution should include the following capabilities:

Must have

• Discover API Endpoints in the system
• Auto grouping of discovered APIs into service/application collections
• Understand queries, parameters, and attributes of the  API
• Interpret REST, SOAP, gRPC, and GraphQL protocols
• Discovery of 3rd party API use and configuration

Should have

• Identify API changes and versions
• Discover API endpoint usage patterns within an application session

API Security Posture

The API security posture category is focused on the capabilities necessary to know how exposed and how high a risk your API attack surface presents. This includes understanding sensitive data exposure, the risk level of API endpoints, and policy violations.

A good API security posture management solution should include the following capabilities:

Must have

• Discovery of sensitive data in the APIs
• Sensitive data classification (including customized)
• Flagging shadow, zombie, and orphaned endpoints
• Ability to create collections and apply policies to them
• Ability to flag high-risk factors in API endpoints

Should have

• Discovery of sensitive data flows
• Risk scoring for API endpoints
• OpenAPI spec upload and conformance analysis
• 3rd party API access policy enforcement
• Discovering development and operational ownership of API EPs
• Discover vulnerable software/library versions
• Identify policy violations in API changes
• Detect internal, external, 3rd party API security posture violations

Runtime protection

The runtime protection category includes capabilities that actively detect and prevent attacks, breaches, and data exfiltration. Capabilities in runtime protection can span the range from auto-blocking upon detection to flagging/alerting anomalies and waiting for human decisions. Either way, these capabilities are where the action is typically taken against threats.

A good API runtime protection solution should include the following capabilities:

Must have

• Detect and block OWASP Top 10 events
• Detect and block OWASP API Top 10 events, including session-based
• Detect and block newly-discovered CVEs
• Identify abnormal API usage rates
• Detect and block credential stuffing & Brute forcing (ATO attempts)
• Enforce protection in a heterogeneous environment based on what is detected
• Automatically block highly rated threats

Should have

• Define alerts based on a positive security model
• Identify abnormal API behavior
• Identify abnormal API error rates
• Dynamically score threats based on multiple conditions
• Detect bot use of the APIs
• Enforce blocking in-line, based on what is detected
• Enforce blocking via integrations, based on what is detected
• In-app virtual patching

Secure API Development

The most effective API security requires securing your APIs throughout the software delivery lifecycle. A good API security solution should include capabilities that help developers write and test secure APIs from the start, and further, helps them proactively improve the security of their APIs using data from production.

To help teams develop secure APIs, a good API security solution should include the following capabilities:

Must have

• Identify API endpoint configurations not matching industry best practices
• Pro-active vulnerability detection/probing using a library of known bad payloads
• White-box security testing
• CI/CD integrated security tests

Should have

• Discover API EP configurations not matching company policies (governance)
• Detection based on request / response correlation
• Using production traffic patterns to test n+1 versions of APIs
• Workflow around vulnerability lifecycle (i.e. Jira)
• CI/CD pipeline informed by API risk scores
• Provide remediation suggestions

Security Insights

A good API security solution will include capabilities to help you gain a deep contextual awareness of your applications and what goes on between and within them. For example, understanding API call pattern behaviors at different times of the day can help identify anomalous activity. This deep correlated data enables efficient troubleshooting, root cause analysis, and threat hunting.

For good API security insights, a solution should include the following capabilities:

Must have

• Analyze the body and payloads of requests and responses
• Detect suspicious client requests based on IP reputation

Should have

• Detect unusual geographical patterns
• API Performance metrics, call and error patterns

Wrapping up for now

Although this is just an article right now, the next steps in bootstrapping this will be two things. To provide more details of each requirement (got too long to do it here), and to make this framework publicly available for contribution and collaboration. Coming soon to a git repository near you.

About the Authors

Renata Budko, Head of Product at Traceable AI, is an accomplished product and technology leader in the cybersecurity space.

Dan Gordon, Director of Technical Evangelism, is passionate about how we develop software together and is guided by his time in the trenches and leading several Agile and DevOps transformations.

About Traceable AI

Traceable AI enables security to manage their application and API risks given the continuous pace of change and modern threats to applications. Traceable AI applies the power of machine learning and distributed tracing to understand the application context, how it is changing, and where there are anomalies to detect and block threats, making businesses more secure and resilient. You can check out how Traceable AI works and reach out to team members to learn more about how to better secure your digital assets.