 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
It seems like every time you turn around, there’s another front that needs protecting in a distributed, cloud native environment. There’s the cloud itself, which is vulnerable to attack. Your applications and data are, of course, juicy targets, and your APIs. But what about your business logic?
Business logic, we’re reminded in this episode of The New Stack Makers, includes “the rules and processes that govern how the application functions, and basically how users interact with it and other systems,” according to Peter Klimek, director of technology, in the Office of the CTO at Imperva.
In other words, he told Heather Joslyn of TNS, host of this episode, “It’s kind of the core. It’s everything that your developers build on top of the core frameworks and libraries that they use to compose those applications.”
In this episode of Makers, Klimek talked about why business logic is so vulnerable, what form some of the most common attacks take, and what organizations can do to protect their business logic from attacks.
This conversation was sponsored by Imperva.
In 2022, 17% of all attacks on APIs came from bad bots abusing business logic, according to Imperva’s latest “Bad Bot Report.” APIs are vulnerable to malicious bots for a number of reasons, Klimek said.
For starters, APIs are “machine-readable by default,” he noted. They also serve a diverse group of clients and “ultimately, by definition, everything accessing an API is effectively a bot, because it’s an automated program that’s consuming it.”
And finally, Klimek added, APIs tend to be poorly protected: “Most attackers will start with the most obvious place, which is going to be the Web site. And a lot of organizations have put in defenses there.
“But what will happen very quickly, as soon as they find that there’s defenses protecting that website, they’ll just go and they’ll look at what the mobile application is using to authenticate users, and then they’ll start targeting that instead.”
And the attacks on business logic can take a number of different forms: credential stuffing attacks, in which the attacker tries a number of different user identities in an attempt to log in.
Or carding, in which stolen credit cards are tested to see if they work.
Said Klimek, “It can even include some of the newer and emerging use cases that we’re seeing, like influence fraud: gaming algorithms in order to basically go and try to manipulate platforms and manipulate the users on the platform.”
Battling business logic attacks takes more than simply “shifting left” and making developers take more responsibility for building secure applications, Klimek said.
“I think we have definitely hit the limit of what ‘shift left’ can do,” he said. That doesn’t, however, mean that devs should be absolved of responsibility for business logic security. Instead, he said, it’s a “cross-functional problem,” one that requires developers, operations engineers, along with security and fraud teams to work together.
“This is something that is an operational problem,” Klimek said. “ It’s something that ultimately is going to be how your users are actually using your applications in production.
To keep business logic more secure, he advises a couple of initial steps. First, run a threat modeling exercise in your organization.
“Threat modeling has always kind of been the the dark art of application security programs,” Klimek said. “It’s been recommended by the Microsoft [Security Development Lifecycle] for the last 20 years now, but I think very few organizations do it. But this is really a good opportunity for you to be able to start with to be able to understand what your potential risk vector risk actually looks like.”
In conjunction with this exercise, he recommended checking out the Open Web Application Security Project (OWASP) website, specifically its list of automated threats.
“When you’re performing a threat modeling exercise, and you’re looking at all of these different services, then that’s a really good guide for you to basically use as a checklist to check against it.”
Check out the entire episode for more detail, including Klimek’s thoughts on which industries are most vulnerable to specific kinds of threats.
