As a founder, I’ve gotten the chance to talk to hundreds of security professionals about their pain points, specifically around APIs and API Security. These conversations have been extremely enlightening about the state of API security and application security, and also been lots of fun as I have gotten to meet and talk to a lot of interesting people with great experiences.  From a problem statement standpoint, there seems to be very broad agreement on the high level problem of API security.  

Mark O’Neill and Jeremy D’Hoinne  summed it up best in Gartner Predicts 2022 :

“Enterprises are producing a massive number of APIs  at a rate that far outpaces the maturity of network and application security practices.”

However, when asked more specific questions about acute API security pain points, practitioners vary greatly in their responses and often struggle to explain what their pain points are.

If You Only Have a Hammer…

Abraham Maslow, a well known American psychologist known for creating Maslow’s hierarchy of needs, wrote in 1966 that “if the only tool you have is a hammer, it is tempting to treat everything as a nail.”  The same could be said of how the practitioners I’ve spoken with view the problem of API security.  How practitioners view the problem of API security tends to be informed by the security approaches they feel most comfortable with, and in my conversations, has clustered into one of three categories:

• API Security is a A Scanning and Testing Problem - One cohort of professionals views API security as a scanning and testing problem.  To address it, they are trying to improve their API scanning or testing process.  They’re doing this by trying to automate what has historically been a manual testing process through use of scripts and automated run-books, or by asking developers to run their own scanning and testing by integrating testing earlier in the development process.  The challenge with this process is that it’s very easy to create more work for both the security team and the development team who have to sort through lists of issues and vulnerabilities to remediate.

• API Security is a Detection and Response Problem - Another cohort of professionals views API security as a detection and response problem.  To address it, they are is trying to improve their visibility into their API behavior through use of observability techniques like distributed tracing, logging, and traffic monitoring.  They use this data to detect threats and trigger responses like alerts, notifications, or API calls to other systems based on statistical anomalies.  The challenge with this approach is that it is slow to respond to attacks, and creates a long backlog of system integrations and compliance work for security, IT, and privacy teams.

• API Security is a Perimeter Problem - The last cohort of professionals view API security as a perimeter security problem.  They are trying to protect their APIs by running lightweight detections for each request at runtime, using combinations of regex, signatures, or basic thresholds.  The challenge with this approach is that these detections aren’t smart enough to detect the #1  API security problem (Broken Object Level  Authorization) and lack sufficient context about the intended behavior of a given API to be effective. As a result, constant maintenance and tuning is required to keep these detections up to date and effective without impacting production traffic.

Reducing Busy Work is the Problem

The fundamental challenge with API Security is that no matter which of these approaches you take, there is too much management overhead (or as we like to call it, busy work) required to easily implement any of them.

For example, if you’ve already got a backlog of several hundred severe security issues for remediation, why would you want to add another source of API vulnerabilities to the list and go through the hassle of triaging and prioritizing all of them?

Alternatively,  If you’ve already got a SIEM analyzing all of your logs and infrastructure to detect and respond to threats, why would you want to add another observability layer just for your APIs?  You’ve just doubled your overhead costs and now have to deal with two sets of detection and response tools.

Getting alignment between business teams, product teams, development teams, and security teams about the specific purpose and usage of a given API (not to mention 20,000 APIs) is a very costly and painful process; yet this alignment is exactly what is needed for an API to be made truly secure.  Otherwise, it’s just guessing, predictions, and assumptions that perpetuate the cycle of extra work for everyone by creating more vulnerabilities to manage, anomalies to investigate, and design documents to review.

Real Collaboration Requires Strong Product

Although alignment and collaboration are easy to say, they are very hard to do.  While most team in an organization will say they want to align with each other, the incentives at play in most organizations actually makes that very hard to do.

For example, product and engineering teams are typically incentivized to ship as many new customer features as possible in a limited timeframe.  At the same time, security teams are usually incentivized to minimize business risk and exposure.  These two incentives are in direct contradiction.  No matter how many meetings these teams have with one another, these structural incentives make true collaboration a challenge.  You can’t overcome conflicting incentives with good vibes, a shared spreadsheet, or a JIRA ticket integration.

The key to successful collaboration is to find effective ways for teams to add value to each other in every interaction.  This way, every stakeholder in a security program always feels like they’re getting something by leaning into the collaborative process, and if you do this right, you create a self reinforcing flywheel that drives additional collaboration. Executing this vision requires strong product execution and a deep security industry experience.

The Road Ahead

Our vision at Impart Security is to attack the core problem of helping Security teams collaborate with other teams in their organizations to be able to reduce the amount of extra work that is being created, and to ultimately deliver better security outcomes.  We’re building real products with cutting edge  technology to make this happen, and we’re super excited about the future.

We’ll be sharing more about our unique approach to API security and how we are building security tools that foster better collaboration within your organization in the coming weeks.  

Stay tuned to our blog for more exciting updates!  Or join the BETA and experience our approach for yourself!  

‍