Implementing an API Security Strategy

This book’s final chapter focuses on applying the knowledge you’ve gained over the last 12 chapters to create a comprehensive API security strategy for your organization. Your strategy will depend on your current position and your security goals and will largely be influenced by your organizational structure, particularly who owns APIs and their security. In the first section, we will examine typical organizational stakeholders and how their roles and responsibilities must be aligned as part of your strategy. We will then examine the 42Crunch API security maturity model to understand the six domains of API security and what maturation looks like for each domain. After, we’ll dive into rolling out your API security strategy, firstly by planning your objectives against the current state and capabilities and, secondly, by running your strategy as part of your daily process. Finally, we’ll conclude this chapter –...

Ownership of API security

Your API security strategy cannot exist in isolation from your organization’s API business and development strategy. As a security leader, you must understand the other stakeholders responsible for API strategy and delivery to ensure that your security strategy aligns with their objectives.

Ownership of APIs tends to vary from one organization to another, and there is no hard and fast rule regarding how it is assigned. In the Further reading section, there is a reference to a blog post from MuleSoft that describes a typical pattern for API ownership; we will use this to frame our discussion. This is shown visually in Figure 13.1:

Figure 13.1 – API ownership model

There are three main API owners in this model:

• IT-owned APIs: This ownership model aligns most closely with traditional IT systems where the IT department wholly owns the resources. These are core services such as infrastructure provisioning or...

The 42Crunch maturity model

In my time as a technical evangelist at 42Crunch, I formulated a six-domain API security maturity model that has proved to be popular with customs in determining both their current security posture and their roadmap toward a more secure posture.

The maturity model features a set of activities for each domain, which may exist to varying degrees based on maturity. For this discussion, we will bucket the activities as non-existent, emerging, or established.

Inventory

An up-to-date and accurate inventory is key to maintaining visibility into the exposed risk and attack surface.

The adage “you can’t protect what you can’t see” applies perfectly to API security. As APIs grow exponentially, fueled by business demand, it is increasingly difficult for security teams to maintain visibility of what APIs exist and what risks they expose.

Three elements are key:

• How new APIs are introduced and tracked in the organization...

Planning your program

Now that you have examined the key topics of API and API security ownership and have the foundations of a maturity model, it is time for the rubber to hit the road as you begin to plan your program.

Establishing your objectives

Simon Sinek’s seminal TED talk Start with Why inspires leaders and organizations to understand their motivation for what they do and the importance of the “why” they do what they do. The same can be said for establishing an API security program – without clear objectives or raison d’etre, your program may flounder and fail. You need to understand the compelling reason(s) for implementing a change program of scale. Perhaps you process medical records and cannot risk an API breach disclosing patient data. Or maybe you are a payment processor that is bound by strict regulatory requirements. Or perhaps you are an “API-first” company whose very business succeeds (or fails) on the strength...

Running your program

Once you have established your program’s goals and identified your stakeholders, you can start running your program. To do that, first and foremost, you need a team composed of the right people for the job. The trick is to find the right people; let’s look at some approaches.

Building your teams

First up, you need to build your own team who will work to achieve your objectives. Adam Shostack has written an excellent blog on the topic (see Further reading), and his perspectives reflect my reality of having built several large-scale AppSec programs. The key point is the hardest one to grasp: to build an AppSec team, you do not need a team of AppSec specialists. Shostack expresses it perfectly: “by using exceptional talents doing over-specialization.” While securing software has an obvious technical element to it, by far, the biggest challenges are human-centric. You will, above all else, require the buy-in and cooperation of your...

Your personal API security journey

We are now at the end of this book, but that does not mean that your personal API security journey has concluded. I would like to think it has only just started. APIs and API security are rapidly evolving domains, with new technologies (such as GraphQL) posing new risks to organizations. Hopefully, this book has given you a solid foundation in the basics of API security, how to attack APIs, and, most importantly, how to defend them.

To keep up to date on all breaking news relating to API security, including breaches, views and opinions, tools, and techniques, I would recommend the bi-weekly newsletter I curate at APISecurity.io (https://apisecurity.io/).

If you prefer a more tactile, hands-on approach to learning, then the good folks at APISecurity University have several online training courses on various API security topics (https://www.apisecuniversity.com/).

Happy learning!

Summary

This brief chapter covered the very important topic of building an API security strategy and saw the theory we have learned about API security applied to real-world API development. Understanding who owns your APIs is important in understanding how to drive the messaging around the need for API security. A broad-based approach involving the CISO or IT security organization and their colleagues in the API product development teams is likely to produce the best results since this will include API security touchpoints across all phases of the SDLC.

First, we learned how to plan an API security initiative by understanding our objectives (the “why”) and then understanding our current state to form our strategy. We then looked at running a program, focusing on the critical step of building our team and selecting our KPIs to gauge our progress.

Finally, your own continued learning is important for staying on top of emerging threats and changes in technology landscapes...

Further reading

These links provide further reading on the ownership of API security:

• https://blogs.mulesoft.com/api-integration/strategy/api-ownership-enterprise/
• https://medium.com/apis-and-digital-transformation/without-an-api-product-owner-your-apis-have-a-limited-lifespan-6df98d6ad281
• https://www.traceable.ai/blog-post/what-is-api-ownership

These links provide further reading on the 42Crunch API security maturity model:

• https://42crunch.com/ebook-api-security-blueprint/

These links provide further reading on planning your program:

• https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action?language=en
• https://csrc.nist.gov/pubs/sp/800/218/final
• https://www.opensamm.org/
• https://dzone.com/articles/how-to-bring-the-power-of-security-guardrails-to-y

These links provide further reading on running your program:

• https://shostack.org/blog/application-security-team/
• https://owasp.org/www-project-security...