Discovering your APIs does not secure your APIs
Over the past few months, we’ve heard countless variations of the following from customers and prospects – “We brought a vendor in last year that told us they could discover all of our rogue APIs, tell us where our sensitive data was flowing, and find where and how our APIs are being attacked. We’re now 10 months in and we’ve deployed across only 10% of our APIs, we’re being inundated with false positives, and we feel no closer to addressing the core issue – that we have vulnerable APIs.”
Looking for the Easy Button
As a product category, API Security solutions could be classified as residing in the early phases of Geoffrey Moore’s technology adoption lifecycle. Many early adopters have chosen to tackle the problem with traffic analysis tools that use AI/ML to discover known and unknown APIs and identify suspected attacks.
It’s easy to see why these solutions have garnered interest as CISOs come under pressure to do something in light of the ever increasing volume of API breaches that make headlines every week. The idea of deploying something at the perimeter to detect where the weak spots are seems like a reasonable place to start – especially since pushing packets to another security device on the network is quick and easy. Furthermore, most security teams may be hoping that this will become another one of those “set it and forget it” types of tools that, once tuned, will require minimal overhead.
While there’s no doubting the value of runtime monitoring tools when it comes to an API protection program, it seems that many early adopters of this approach have struggled to make meaningful progress.
Fixing the API Security Problem
Based on our discussions with many of these enterprises we have identified three common themes emerging:
-
Heterogeneous Networks
While most of these behavior monitoring tools have a wide range of deployment options, APIs can be scattered across an enterprise’s distributed infrastructure making it extra challenging to get wide standardized coverage across a heterogeneous network environment. -
False Positives
Even the most sophisticated detection engines yield a high number of false positives. For SOC teams that already suffer a high degree of alert fatigue, it doesn’t take much for incident responders to lose confidence in a new noisy tool. -
Lack of Remediation
When the tool detects legitimate API attacks, security teams are ill equipped to take remediative action to fix the root cause. In other words: “this API is being attacked – now what do I do?”
At 42Crunch, we’ve been fortunate to work with customers that have chosen to start earlier in the API lifecycle when looking to deploy a security tool. Rather than wait until after the APIs have been deployed, our customers are involving developers as a critical part of resolving the security challenge from the API design time and see 42Crunch as a key enabler for them.
A recent 42Crunch poll of 243 engineers from development and application security teams at large enterprises across North America and EMEA provides support for this trend.
Through the use of our IDE extensions and CI/CD automation, enterprises use our tools to run security tests across tens of thousands of APIs every day. Furthermore, our micro-firewall service provides runtime threat protection in production. Additionally, we’re proud to say that the public community of API developers using our free IDE extension has surged to nearly 1 million strong which validates our ease of adoption.
Charts below depict the increasing rate of adoption of the 42Crunch API security testing services for both API Audit and API Scan over the past 18 months by enterprises and governments globally.
As our customers have increased their usage of our platform consistently over time and worked with us to develop new capabilities, we’ve never been more confident that we’re on the right track in this rapidly evolving world of API security. In the words of Robert Frost, these customers took the road less travelled – and it’s made all the difference. If you’re interested in learning more, we’d love to talk.
