API Security Tools: What To Look For

Determine the Goals

In Bruce Lee’s famous movie, “Enter the Dragon,” there’s a scene of Bruce on the junk with the other contenders. One of them, Parsons, asks, “What’s your style?” Bruce answers, “The art of fighting without fighting,” after which he tricks Parsons onto the lifeboat, and Parsons is dragged in that boat behind the ship while the onlookers laugh.

Similar to the “What’s your style?” is “What’s your goal?” questions, there is no one right style, and there is no one right goal. Before testing APIs, determine the goals of testing; the goals of testing will help determine the tool specifications. Are there compliance standards to meet? What are the internal departmental and business goals? Are there contractual requirements? Does the SDLC require SAST and DAST to be applied? Does the CISO require RASP and IAST? Define and document the requirements. Remember – if it isn’t documented, it doesn’t exist.

Background Checks

These are some specific things you need to know to find the right kinds of API security tools.

Budget

• This will determine if you’re limited to free and open source. If purchasing is an option, then it will help narrow down the paid options.
• If going the free to low-cost route, then ensure that personnel has the proper skill to configure the tools to the company’s needs.

Architecture and Design

• Testing for SOAP (XML) is different than REST (JSON) is different than GraphQL, etc.

Staffing

• What’s the skill level and the number of people available for running, monitoring, and maintaining the tools?

xAST, RASP, etc.

• What style(s) of testing are in scope? And where will it fit in the pipeline?

Integration Needs With Other Tools or Platforms

• E.g., If using Jenkins, Google Cloud Apigee might be a good fit. Before someone obtains a solution, consider where it needs coordination.

Data Flow and Privacy

• If you’re held to privacy and security standards for the data transmitted, then on-prem solutions might work best instead of hosted because you might not want confidential data leaving the premises during analysis.

Culture

• What image does the company want to convey? In a former place of employment, I was curating tools for monitoring and alerting. One tool was open source, and the other was a professional paid service. The company chose the paid service because they felt it would better reflect the business image when people found out it was used instead of open source. Get input from your business leaders on what kind of image, culture, and reputation they want to convey. I’ve been in a manufacturing company that presented a DIY image and a real estate company that did everything elaborately. Like goals and styles, no culture is inherently right or wrong, but each company has a culture. The saying holds true: “Culture eats strategy for breakfast.”

What Not to Look For

One thing you’re not looking for is that one tool that will do and fix everything. There are lots of good tools out there, and not one among them will do it all. This approach also avoids a single point of failure. Taking a multi-pronged approach allows for a temporary outage in one tool while not hanging up the whole process.

Some Core Functions to Look For

Regardless of things like budget and culture, look for tools that provide the following:

OWASP API Top 10 Detection

That’s what attackers are reading, too, so tools should address those vulnerabilities. 

Runtime Protection

Runtime protection is vital because that’s where the API is taken to task. How does the production endpoint truly respond when it’s called and put under duress?

API Inventory

APIs are everywhere, so make sure you can see everything. If you can’t see it, you can’t protect it.

Fuzzing

Ensure at least one of your tools can fuzz the APIs. Rest assured that threat actors will fuzz – all it takes for them is to get one instance of BOLA to get an inroad, so it’s best if you find it first. 

Reporting

Brian King of Black Hills Infosec has a presentation called “Hack for Show, Report for Dough.” While it’s about pen testing and ethical hacking, it applies to API tools. An API tool needs to produce detailed reports that give clear direction to those who need to see it so they can properly address issues and build confidence that their investment in API protection is paying off.

A Couple Soft Skill Tools – Understanding and Lists

API security is different than web app security, though still in the overall application security category. This is one of many resources to build your understanding of why API-specific security is important, different, and necessary. 

Lists are a must. Lists help ensure that nothing gets missed. Even with something seemingly banal as deploying a workstation, there are at least a couple dozen factors that must be kept in mind, and that’s not scalable using memorization. OWASP’s ASVS is a great list from which to draw specifics. 

Final Consideration- People

With security audits, one of the categories is “Assets.” From my perspective, “assets” means things, but in audits, it includes people. I don’t prefer that term for people, but it’s part of the audit world. In this current topic, I’ll include personnel under the category of Tools, but only in the sense of people being the most necessary aspect of API security.

A model of information is the DIKW model – data, information, knowledge, wisdom. Many tools will excel at the first three, but the last – wisdom – is solely within the purview of people. Automated tools can do a fantastic job at monitoring, detecting, and alerting to anomalous behavior, but it’s always people who determine for their business what is a relevant risk or not (those who have worked with monitoring tools like Splunk, Sentinel, or Snort know exactly what this is like) and how to address and report the relevant findings.

This quote from a 2019 article about the Capital One hack points this out: “There’s a lot of specialized knowledge that comes with operating a service within AWS, and to someone without specialized knowledge of AWS, [SSRF attacks are] not something that would show up on any critical configuration guide.” The API world needs trained professionals, whether they’re trained prior to arrival or on the job. 

Dr. Jessica Barker said, “Without people, there would be no cybersecurity. There would be no one to design infrastructure, test systems, report issues, or respond to incidents.”

Invest well in people, and the rest will take care of itself.