Critical Mass: Why We Need to Assess API Security Maturity
Explore the risks of shadow APIs and discover strategies to enhance API security maturity.
APIs have reached a tipping point, dominating internet traffic but remaining poorly protected. Could assessing security provisioning using the cybersecurity maturity model improve their governance? Andy Mills, VP of EMEA for Cequence Security, explores this critical issue.
Application programming interfaces (APIs) have become the dominant form of internet traffic. Deployments have now reached critical mass, with many organizations moving to an API-first model, which sees the API determine the approach taken in software development and service delivery. Yet despite APIs acting as the digital enterprise’s building blocks, API governance still needs to improve. APIs provide applications with such rich data and are relatively quick to spin up, enabling services to be rapidly deployed. But as a result, it can be easy to lose track of them.
Left to their own devices, these APIs function below the security team’s radar. They allow threat actors to conduct reconnaissance to understand how the API works and its level of access, all without the risk of detection. Once they have a blueprint of the API, the threat actor can use this information to map out its connections to other APIs or use it to access and mine sensitive data on the backend.
As an example, a large mobile operator with over 100 million subscribers carried out a discovery exercise to verify the APIs over its infrastructure. Over a thousand unprotected API servers, equivalent to 18 percent of its server base, were publicly exposed. Over 30 percent of its API servers had SSL issues, such as invalid or expired certificates, which would have made it possible for an attacker to launch a Man-in-the-Middle attack. Discovery also revealed 107 files that could expose private keys and five API servers that remained Log4j vulnerable.
Shadow APIs
Shadow APIs illustrate that while organizations now have sizable deployments, they lack the visibility to understand the risks these pose to protect and govern them. They need to begin measuring their API Security maturity level so that they can look at how effective their current methods of security are and seek to improve upon them.
In a cybersecurity context, measuring a business’s level of maturity means assessing its risks and evaluating its level of protection against those risks in the event they are realized. Businesses with a mature cybersecurity posture will have the processes and systems to detect a threat and appropriately respond to and mitigate it, minimizing the impact on the business.
Cyber maturity is a risk-based approach. It’s typically evaluated using an established risk framework such as NIST 2.0, which has six pillars: identify, protect, detect, respond, and recover, with govern overarching the other five. Applying the same concept to APIs would see the assessment of the organization’s ability to identify its API assets and the threats against them, how these will be protected, that systems are in place for threat detection, and the processes to respond and recover in the event the API’s function is compromised.
A Risk-based Approach
Looking at each of these in turn, it’s clear that many organizations will need help with the first stage of identifying their assets. You can’t secure what you don’t know, making discovery a must. But just creating a point-in-time inventory is not sufficient. The dynamic nature of APIs demands a continuous runtime inventory to ensure that all APIs are tracked and monitored on an ongoing basis. The APIs should then be profiled based on the risk they pose, which may depend upon the data they access or how dependent the business is upon them.
Once security teams know the extent of their companies’ API profiles, they can begin protecting them more effectively, including API Security Testing for pre-production APIs and employing defensive tactics for live APIs. This might involve stopping a threat by blocking or using deception to exhaust the attacker’s resources. API attacks are often automated, but attacks will usually only persist for a given time before the attacker becomes frustrated or decides it’s not worth their time and effort.
An example of this in action can be seen in an attack against Ulta Beauty, a retailer of beauty products. Its Inventory API was hit with high traffic volumes from high-quality residential proxy IP addresses. It rotated through over 153,000 unique product and SKU combinations while scraping 61,000 ZIP codes and 33,000 products. These proxies rendered traditional web application firewall (WAF) and CDN mitigation efforts ineffective. Policies were implemented to block 85.9 million requests at the height of the attack, blocking more than 17 million requests.
When it comes to detection, the security team needs to consider the API’s level of exposure. Objectively analyzing the API estate internally and externally can give a comprehensive view of how data moves through those APIs. An inside-out assessment tracks the API inventory from within, determining the risks and basing protection on those findings. This is the predominant way of assessing exposure today, but it can be insular, and doing this alone only provides half the picture.
See More: How to Tackle Cybersecurity Threats with a Risk-Based Approach
Attacker’s Eye View
Complementing this approach with an outside-in assessment, however, allows the security team to detect issues that would otherwise go unnoticed. It involves analyzing the public domain to pinpoint every publicly visible API endpoint, mapping the organization’s attack surface, and providing the team with an attacker’s eye view. It can yield surprising results, such as internal APIs that have inadvertently become public or problems with deprecated APIs. It can even reveal security and compliance issues missed by standard vulnerability and penetration testing.
Detection is, of course, also concerned with threats and having the measures in place to spot these. It’s often the case that Web Application Firewalls (WAFs) and API gateways are used for this purpose, but both have their limitations. WAFs use signatures to detect known vulnerabilities and so struggle to find and block attacks that appear legitimate. At the same time, API gateways are predominantly a way of managing APIs, so they provide access control with security functions limited to rate limiting and IP block lists, which attackers can easily circumvent. Moreover, API Gateways fail to detect, manage, and protect unmanaged, zombie and shadow APIs. Both operate in isolation and cannot understand business logic or how it might be abused nor can they identify sensitive data being inappropriately shared or what security risk it represents.
Effectively responding to these threats demands a nuanced approach that integrates context and behavior-based analysis. By leveraging machine learning, we can discern whether API requests align with acceptable parameters, ensuring a proactive defense against potential risks. The security team can determine the attack path and objectives by comparing the tactics, techniques and procedures used against threat databases, enabling the security team to determine the attack path and objectives. This, in turn, will help determine the defense approach used. Importantly, the response also needs to be proportionate, and it’s here where the risk profile of the API comes into its own by helping to prioritize the response. API Security Risks 2023 and threat databases. This, in turn, will help determine the defense approach used. Importantly, the response also needs to be proportionate, and it’s here where the risk profile of the API comes into its own by helping to prioritize the response.
Maintaining BAU
Recovery is all about ensuring the organization can get back to business as usual and remain compliant. An attack could see the business in breach of regulations pertaining to APIs in PCI DSS, for example, if the application involves payment processing. So, recovery needs to factor in how the business will meet its regulatory obligations, i.e., notifying the necessary authorities and impacted parties, as well as how it will maintain operations.
Some might argue that their API security is at a nascent stage and that they’re not ready to assess their API maturity levels. But the fact is that deployment levels have reached critical mass, and there is an urgent need for organizations to baseline their security so that they can begin to see where the gaps are. Doing so will bring APIs into line and help build a business case for investing in API-specific protection rather than using a square peg to fill a round hole by relying on web application solutions.
Ultimately, assessing API Security maturity is all about a better understanding of the attack surface and the API footprint. This can then enable the business to create a unified approach that secures internal and external APIs throughout their lifecycle by implementing effective discovery, protection, and compliance.
Image Source: Shutterstock
MORE ON API SECURITY
