Announcing the Salt API Security Maturity Model
Security practitioners often express concerns across related security problem areas. They may phrase their questions in the unique language of their industry, but supporting processes and technology remain similar at their core. Threats including account takeovers or digital supply chain attacks are very often the result of API problems. Today, few security teams are well versed in API security, and organizations and practitioners often struggle with where to start when embracing new technology. In cases where they’re further along on a security deployment journey, they wonder how to improve. What areas should the organization prioritize? What’s considered “good enough”? What do advanced approaches look like? What are others in the industry doing?
Possessing the time and resources to assess maturity is sometimes a luxury that is reserved only for large enterprises or those organizations that are already many years into an effort. In reality, organizations of all types can find value in reviewing maturity models, even when in the beginning stages of exploring a new process or technology. Maturity models provide a roadmap of the things you should be looking at if you’re just getting started as well as areas to focus on to maintain or improve maturity.
What’s a maturity model used for?
For those at the start of their IT or security journey, questions can arise as to what maturity models are even used for. Maturity is a measurement of an organization’s ability to continuously improve in a particular discipline, such as systems engineering or security strategy. Companies at a higher level of maturity in security face lower relative risk — that organization will likely suffer fewer errors or incidents. Risk is, of course, more comprehensive than just security and includes business risk, operational risk, and quality risk.
Maturity models differ from guidelines, standards, and best practices, which organizations will also often use to inform their requirements, compliance policies, and technical documentation. Organizations use maturity models to measure and assess how effectively they are utilizing their people, processes, and technology. Maturity models bring a spectrum of measurements across many areas including team structures, communication mechanisms, technology implementation that supports business goals and IT objectives, and technology operationalization.
Why do we need a separate maturity model for API security?
There’s no shortage of general, non-security IT maturity models. Capability Maturity Model (CMM), or its successor, Capability Maturity Model Integration (CMMI), are the most well known. Adoption of the model is particularly common in those organizations with structured systems engineering, software development, and standards adoption. The models are commonly viewed as too voluminous and too light on security. They can be overkill for many organizations since they are too process intensive, too academic, or too far afield from modern design and security approaches.
Download the Salt API Security Maturity Model to determine your organization's maturity stage placement.
Download NowOn the security front, we have Building Security In Maturity Model (BSIMM) and OWASP Software Assurance Maturity Model (SAMM). These models focus heavily on application security because of their origins and have more recently introduced some infrastructure security context. We also have rapidly evolving cybersecurity maturity models heavily entrenched in public sector such as Cybersecurity Maturity Model Certification (CMMC) and Cybersecurity Capability Maturity Model (C2M2). Both have mappings to the NIST Cybersecurity Framework (CSF), which some organizations are using to structure their cybersecurity programs.
Some measurements have evolved out of traditional systems engineering practices, which some organizations find less useful for modern initiatives. Also, not every organization is of comparable size to a federal entity, is transacting with federal entities, or is regulated as heavily as government. Cybersecurity initiatives in practice sometimes focus too heavily on infrastructure security or security operations. This narrower focus can be at the expense of development lifecycle work or shift-left focus areas. As a result, organizations ultimately seek something more applicable.
API security is a combination of many different security domains including application security, mobile security, network security, infrastructure security, and identity and access management. Most organizations are already entrenched in these broad processes and technology. They might also be assessing their own maturity in each domain. However, the combination of these cross-domain practices and technologies as seen with API work adds uniqueness that organizations must still account for. Combining all the measures of separate maturity models into one giant model or spreadsheet won’t cut it. And replacing terms like “system” and “application” for “API” in existing models also isn’t a solution.
How is the API Security Maturity Model structured?
The Salt API Security Maturity Model was created with simplicity in mind rather than the complexity that comes with hundreds of activities and measures. A simpler model is easier to digest and apply, and the industry overall is still relatively young and immature. This model will evolve over time as maturity improves, and we developed the foundations with future benchmarking in mind.
The model includes five stages that map the relative progression and maturity of organizations with respect to API and API security initiatives. The stages are:
- Stage 1: API learning — these organizations are becoming aware that APIs are the main vehicle for application design and data exchange. Stage 1 organizations have acknowledged they may have gaps in their API security posture and are educating teams on API engineering practices. They rely on traditional API protections such as web application firewalls with out of the box rulesets, inventory APIs manually, and rely on access control on external APIs.
- Stage 2: API piloting — these organizations have started educating teams on the basics of APIs and have initiated small pilot projects for APIs, likely focused on integration. For larger enterprises with dedicated development teams, the organization may start to dedicate some employees to API development or operations to the pilot projects. They are likely also deploying API gateway instances for added threat protection in addition to WAF and have started documenting APIs more readily.
- Stage 3: Limited API deployments — these organizations have working knowledge of API design patterns. Teams are actively creating new applications that leverage APIs or APIs as products unto themselves. At this stage, DevOps practices with standardized build pipelines for APIs are certainly in play and can quickly become a prerequisite in order to scale API delivery. The organization has added dedicated API security tooling to its technology stack for API protection of external APIs, documents and mediates APIs more readily, and mitigates OWASP API Security Top 10 issues for external APIs.
- Stage 4: Expansive API deployments — these organizations are actively creating and integrating APIs. It has established DevOps practices across the board with standardized build pipelines for all APIs, the organization is adopting microservice architecture patterns, and makes use of cloud-native technologies. The organization has expanded adoption of API security tooling to protect high-value internal APIs, analyzes API code readily, mediates external APIs fully, mitigates the OWASP API Security Top 10 issues for all APIs, and adds anti-abuse mechanisms for external APIs.
- Stage 5: API-first and cloud-native — these organizations are a relatively rarity since many organizations still have a mix of new and old technology stacks that muddy the waters of what process or technology can be put in place for API security. A direct correlation often exists with how far the organization has progressed in its digital transformation efforts. The organization has fully adopted API security tooling to protect all its APIs and third-party APIs, mediate all APIs fully, enforce strong access controls with modern protocols, implement API-centric incident response, and mitigate the OWASP API Security Top 10 and other types of abuse for all APIs.
Each maturity stage contains two sub-groupings of measurements which are:
- API Barometer — measures common non-security traits or indicators such as levels of API acquisition, integration, or creation and respective protocols.
- API Security Practices and Tooling — measures common security traits or indicators seen in organizations such as use of security testing tooling or runtime protection capabilities.
For those organizations looking to dive deeper into the stage measurements, the maturity model also includes tables that detail the measurements for activities and tools for each stage of the API security maturity model. These tables include a scoring column so teams can assess how well the organization satisfies a given category of activities and tooling. If the organization finds that it is scoring highly in most of the categories of a given stage, it’s likely ready to advance to the next.
Practitioners should find that the model pairs well with other Salt content including API Security Best Practices and the API Security Evaluation Guide.
What’s next?
Time and effort invested in maturing the organization’s API security program has amplifying effects. Many of the security techniques and tooling covered in this API security model support other security trends such as risk-based authentication, zero trust architecture, and digital supply chain integrity. Intersections also occur with other security program work, including cybersecurity, infrastructure security, application security, and cloud security.
Security strategy is a continuous process, and API security is in its earlier development. Many organizations will find they are in lower stages of maturity when factoring in all measurements. Most will also find they satisfy a majority of security practices in one level (the stage that is the best fit) and a smaller set of security practices in the next. This discrepancy is a good indicator that the organization is advancing in maturity and could progress in their API security program by adjusting in some areas. Looking ahead at the other stages is helpful if the organization is looking to advance its API security strategy and make short-term or long-term planning adjustments.
We’re excited to provide this maturity model to industry and look forward to seeing it evolve over time as practices and technology continue to improve. API security is still nascent but rapidly growing as a distinct domain since APIs have become a dominant attack vector. We’d love to hear your feedback on how this model is helpful for benchmarking your organization’s API security strategy or useful as general API security guidance. The intent is to help organizations self-assess, use the information in regular dialogs with others, share scores and learning lessons, and foster the growing API security community. Take a look at the model and see where your organization stands.
To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.
