In my last post, “Know Your Enemy, Know Yourself: Why WAFs can’t protect your APIs,” we took an in-depth look at four reasons why WAFs fail to protect our APIs. This led us to the evolution of API security and how to truly protect our APIs.
With this article, I want to focus on what good API security looks like which brought to mind another quote from Sun Tzu that I found insightful:
“Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.”
For all of the devs and security teams out there, we want to win at API security and then declare war on bad actors. To do this, we have to do our research and listen to the troops who are out there every day defending our data and our privacy.
I’ve spoken to nearly a hundred security practitioners in the last 2 months and what has become increasingly clear to me is that the market has become very well educated about the problem of API security.
In these conversations, most security teams are telling me that API security is an urgent and pressing problem that needs to be solved.
It’s been very rare for me to hear from someone who is very happy with their current solution.
What also seems clear to me now is that the initial hype for API security has passed. Teams know they need a solution, and security teams are starting to realize that the solutions that they’ve implemented over the past few years aren’t solving their problems.
Here’s a snapshot of the feedback we’ve received recently about what’s not working with existing solutions:
What they’re saying: Many API security solutions have marketed themselves on ease of implementation, and the concept of an agentless, integration focused middleware layer does make sense in theory.
What we’re hearing: However, we’re hearing that these implementations are actually much harder to set up and maintain than they appear, with some folks telling us that their implementations are taking up to 6 months!
Common gotchas we’re hearing about include things like TLS encryption handling, version control, and reporting.
What they’re saying: Many API security solutions expound on how convenient enterprise rollout is without going into specifics or argue the advantages of other positive traits over being able to onboard effectively.
What we’re hearing:e’re hearing the current crop of API security solutions is very difficult to roll out enterprise-wide. Specifically, security practitioners say it is difficult to get multiple dev teams on-boarded into new API security processes and procedures.
They’ve also told us it’s been difficult to deploy and manage multiple classes of integrations with different levels of features across a large enterprise footprint.
What they’re saying: Many API security solutions tout their exceptional ability to protect APIs at runtime and during attacks due to their integrations with WAFs and API gateways.
What we’re hearing: We’re hearing that existing solutions have a hard time holding up when customers’ APIs are under attack. In particular, folks are telling us how hard it is for security teams to explain to angry executives what is happening when things hit the fan, such as what requests were blocked and why because their integrations don’t provide the visibility or audit trail that can be used to quickly explain attacks in progress.
In the API security industry, it’s become increasingly clear that success is not solely defined by functional requirements like number of security detections that a tool can identify.
While metrics like the number of API endpoints a solution can discover or the breadth of canned tests it can automatically execute are important, they’re no longer the unique selling points they once were.
These functional requirements have become features that security teams simply expect all their tools to possess. The actual indicator of a tool’s success is how seamlessly it can be implemented within an organization. As a result, the industry’s focus has shifted toward non-functional requirements such as performance, reliability, ergonomics, and usability.
There are a number of examples in SaaS and Security that we can draw from in recent memory:
These non-functional factors play an important role, if not the most important role, in the successful implementation of an API security tool within an organization’s ecosystem.
What good is an API Security solution that only analyzes 50% of your API traffic? Or what good is an API testing suite that is used by a single developer in an organization of 250? Broad adoption of the tool is largely the driver of success.
Success in API Security goes beyond functional requirements. Equally important as knowing your enemy and knowing yourself is being victorious even before you go to war.
While having functional requirements, then getting to know your enemy and yourself will help you win at API security, you need a solution that is easy to be truly victorious. F
Finding a solution with all of the above that can be easily implemented and rolled out across large enterprises thereby reducing the overall work that is needed from security and development teams is key.
To successfully do this, you should look for solutions that:
Here at Impart Security, our work is focused strictly on an API security solution that is made to lead you to victory. If you’d like to learn more about Impart’s integrated API security solution, get started today with a live demo.
Want to learn more about API security? Sebscribe to our newsletter for updates.
Oops! Something went wrong while submitting the form.