Making a Business Case for API Security: Talking Points for Speaking to the Board

It didn’t take long for API security to make the news in 2023. In January, it was reported that a threat actor stole the personal information of 37 million T-Mobile customer accounts via an exposed API. With API security in the headlines, and more cybersecurity scrutiny from regulators coming later this year, chances are good that the board will start asking questions – if they haven’t already. What do you do? Where do you start? Let’s walk through the commonly asked questions and how to make a business case for a new API security program or to justify an existing program.  

The case for API security  

Regardless of what your business audience has been reading, it’s a good idea to establish a basic understanding of APIs, including the following:   

What is an API?  

An API (application programming interface) is an application that enables two or more other applications to seamlessly connect and share data.  

Why are APIs important to the business? 

APIs enable developers to build applications faster. Instead of building capabilities from scratch, they can reuse APIs to carry out common functionality.  

If possible, give an example of functionality from your own applications that users may be familiar with and is delivered via an API. Or, provide an example that they may have encountered in their everyday life, such as “Pay with PayPal” functionality that allows consumers to make an e-commerce purchase via their PayPal account. When the user chooses to Pay with PayPal by clicking on the appropriate button, the application makes a request to the PayPal API. The user is authenticated and the purchase is confirmed via a pop-up. If everything works correctly, the API returns payment confirmation to the application.  

Why are APIs at risk?  

• APIs are designed to expose application logic and sensitive data, so they’re a natural target for attackers.  
• Just like applications, APIs have vulnerabilities. And since many companies lack visibility into their APIs, it’s often easier for attackers to take advantage of these vulnerabilities while going virtually undetected. 
• In their efforts to build meaningful APIs, developers tend to overexpose data. 
• Organizations lack controls to ensure that APIs built for internal use are not exposed externally.  
• Developers can’t predict every future use case (and security control) required for public APIs. 

What would be the impact of an API attack?  

An API-based attack can result in a data breach or service disruption.  

What are some examples of API breaches?  

• A single API vulnerability led to the breach of 5.4 million Twitter users’ data. 
• Venmo leaked more than 200 million transactions via a publicly accessible API.  
• A vulnerable API allowed attackers to obtain private account data of Peloton users. 
• A threat actor stole the personal information of 37 million T-Mobile customer accounts via an exposed API. 

With this foundation, you can then explain what’s different and difficult about API risk management. These are important points because the traditional tools your team uses to protect web applications aren’t sufficient for protecting APIs. It will therefore be necessary to request the resources to obtain and manage the tooling required for an API security program.  

What are the challenges of API risk management?  

• Volume — Nearly every modern software application uses or is an API. We have exponentially more APIs to protect than we do applications – and for most organizations, we simply don’t know what they all are.  
• Reuse — Because of reuse, there can be many different types of clients making it more difficult to identify and understand risk at the API-level. It’s also harder to understand when and how they’re exploited. 
• Traffic — many of the attacks can look like legitimate user behavior that we don’t want to mistakenly block. 
• Complexity — Traditional security controls can’t detect the complex, multi-step attacks executed by today’s sophisticated attackers. 

What is the current state of our API security efforts?  

Current solutions (such as AppSec scanners, API gateways, legacy WAFs, or stand-alone API security solutions) don’t: 

• Provide visibility into API: We don’t know what APIs we have or how they are being used — and we can’t protect what we can’t see. 
• Identify sophisticated attacks against APIs. 
• Block threats to APIs in real time. 

Note: Code scanning for vulnerabilities will always be a best practice. However, there are limitations with these solutions: 

1) Scanners look for known vulnerabilities, but are always behind on newer attacks and zero-day exploits 

2) Run-time attacks that involve webshells, remote access software, and other attacks can’t be detected through scanning 

3) Sophisticated attacks will often use legitimate behavior as part of the attack and to attempt evasion from protection 

Building an API security program 

To effectively manage API security risk, security organizations need several key capabilities:  

• Discovery – Through discovery, the organization obtains a good understanding of how many APIs it has, how often they change, and which of them represent the most risk.  
• Visibility – The ability to visualize the entirety of the API attack surface and observe the use of APIs both in real time and over time.  
• Classification – To understand what applications APIs are supporting and therefore, if they were breached, what would be the risk? 
• Trend analysis – The ability to see how the organization is trending in terms of the attacks you’re observing, the vulnerabilities being detected, and the amount of risk introduced via development practices versus external threats.  
• Protection – The ability to detect and block attacks in real time, and work with developers to shore up vulnerabilities and prevent new ones in the future. 

Proving the effectiveness of the API security program  

Once an API security program is in place, you may need to keep the board current on your progress via periodic updates. These updates should have a natural progression as follows:  

First meeting: The first meeting should be to simply demonstrate that the program is working. Questions you can expect to hear include:  

• What kind of metrics are you getting?  
• How many attacks did we see? 
• What were they targeting? 
• Did we successfully block or deny the attack?  

Be prepared with metrics like number of APIs, percentage of APIs targeted, number of un-used APIs shut down, number of threats blocked, and the top three to five attack types.  

Subsequent meetings: During the next couple meetings, highlight trends that you’re seeing: whether threat activity is getting better or worse, where you’re seeing the most risk, etc. Questions you can expect from board members include:  

• Now that we’re spending money, is the risk increasing or decreasing?  
• How do you know? What are you tracking to understand that? 
• Are there certain apps or technologies that represent more risk than others? 

Be prepared with metrics like total API requests vs. API requests blocked over time or number of APIs targeted over time.   

Continued-investment meeting: If you do your job well enough for long enough, the board might start to question whether a continued investment in API security is necessary. To ensure that you continue to receive support, it’s important to demonstrate that you’re making the right investment with the money they entrusted to you. The way to do that is to compare your organization to others in your industry. This means gathering external data so you can understand the volume and type of activity other companies in your space are seeing compared to you. When presenting to the board, summarize the trends your peers are seeing vs. what you’re seeing in your API environment, and why you’re doing a good job comparatively.  

Be prepared to answer questions like:  

• How do we compare to the rest of our industry?  
• Are the numbers you’re showing us good numbers or bad? 
• Has this level of observability enabled us to head off specific attacks and/or identify areas for improved security practices?  

Work with your security vendors to collect metrics about your security posture vs. your peers, and be prepared with metrics like the cost of an API breach (consider ransom, non-compliance fines, lost business, time and cost to respond) and adherence to application/website update/availability SLAs over time. 

Start now  

Chances are good your board members are hearing about API security. If they aren’t asking questions yet, now is the time to get in front of the problem and obtain the support you need to avoid becoming the next headline. At the very least, you’ll establish a foundation for when the next breach hits the news and board members ask, “What are we doing about API security?”