Learn about the Salt + CrowdStrike Falcon integration
Learn more
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.
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.
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.
On 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.
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:
Each maturity stage contains two sub-groupings of measurements which are:
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.
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.
.jpg)
