Press Release
Last Updated on January 19, 2024
As development trends have shifted from traditional web applications with 3-tier (client-server-database) architectures to today’s API-first apps, the need has arisen for “observability” into what all those API calls are returning, and whether that data spells “attack.”
The ability to process your API calls for troubleshooting, remediation and analytics purposes can significantly reduce app-related risk. But can it bring knock-on benefits, like the ability to calculate positive or negative business impacts from API calls?
To talk about the new world of API-centric application security, Rob Dickinson, CTO at Resurface Labs, joined a recent episode of The Virtual CISO Podcast. Hosting the podcast is Pivot Point Security CISO and Managing Partner, John Verry.
API calls as transactions
With the right level of observability, API calls become like durable transactions, making it comparatively easy to know how APIs are being used or misused.
“When you think about these API calls themselves representing transactions, what is the record of that transaction?” posits Rob. “Did that transaction complete successfully? If that transaction didn’t complete successfully, was there revenue lost? Yes, we’re a security company so we’re obsessed with security. But a lot of security problems are also quality problems. And a lot of those quality problems have negative customer outcomes or lost revenue attached to them.”
Rob continues: “One thing that’s horrible about the API economy is the API providers that we talk to, their attackers actually dominate their user traffic. It’s not an attacker showing up every once in a while. Their attackers are actually in the majority. So, you can’t statistically baseline these people out very well. All those traditional techniques don’t work. For me as a developer, that puts this horrible pall over what I thought I knew about things like response codes and errors and things like that. So that means every time in my log if I have a 500 error that popped up, well, now I’ve got like a 50/50 chance. Either that was a real user that was impacted and there might have been revenue loss associated with that, or it was an attacker doing something stupid and trying to crack in.”
The environments that our apps are operating in are so hostile compared to the three-tier web systems of the recent past that we can’t ignore API security any longer.
From value preservation to value creation
Forward-looking security leaders are recognizing that cybersecurity can not only preserve value by mitigating risk, but also create value, e.g., by solving critical business problems like meeting strict security requirements for bidding on US government contracts.
An API observability solution like Resurface could improve the effectiveness of your development team by helping them focus their efforts in the right areas to advance the business. It could also save money, such as reducing the number of AWS Lambda function calls you’re paying for. It could also help improve the quality and security of your code, leading to improved customer satisfaction and competitive differentiation.
Putting APIs to the test
A problem Rob notes with typical API security is that test environments are too sanitized to uncover real-world issues that come up quickly in production.
“If your developers don’t know what that malicious traffic looks like, how can they design systems to be resilient to that?” Rob asks. “What I see traditionally is the ops group and the security group own the production systems. Of course, to minimize your surface area, you want to limit the number of people that have access to those systems. What does that translate to? Development sees the code on their machines, in their sanitized test environments, and then when it goes into ops, it goes to somebody else.”
“I love when people say, ‘There wouldn’t be security problems if the systems were designed right to begin with,’” says Rob. “Part of that is acknowledging that these systems are being designed in too clean a room. It’s not just that the designers don’t know what they’re doing and if they could only do better, it’s the environment in which those systems are being created.”
“You’re almost saying our staging environments should be on the internet next to our production environments,” John replies. “It’s almost like that Chaos Monkey concept, right? Unless you’re actually going to inject really bad crap into that part of the process, the likelihood of you being prepared for the bad crap to happen when it does happen is pretty damn low. Because you can’t possibly mirror what’s going to happen in the real world.”
What’s next?
To hear the podcast episode with Rob Dickinson from the beginning, click here.
Wondering how API security could fit with a continuous integration model? Check out this blog post: Application Security Best Practices in a Continuous Integration Model
Free OWASP ASVS Testing Guide
If you are just learning about OWASP’s testing standard or are considering the best way to prove the security of an application, this guide is meant for you!
