When security specialists focus on APIs as part of their discipline, they run the risk of not seeing the forest for the trees, which is precisely what bad actors count on. When the overarching business logic is overlooked, all the API testing and security measures in the world will fail to protect the enterprise.
A Clever Theft that’s Difficult to Spot in Advance
Business logic describes a process with an end goal, inside of which will be a number of functions that are supported by code. Nir Rothenberg, CISO at Rapyd.net, described how things can go wrong when the APIs work correctly, but not within the greater context of business logic. He offered up an e-commerce scenario in which a cash transaction is involved:
“Generally, an API has a number of endpoints that all talk to a database,” he said. “Suppose a hacker tells four different endpoints to say the same thing to the database at the same second. It becomes a race. The command executes four times, each on a different endpoint, but will only be reported once. If each of these commands is to transfer $25 from wallet A to wallet B, the total amount of money moved is $100 but the database only writes $25.”
Rothenberg pointed out that this type of hack can be exploited by understanding the business logic of how the API talks to the database and what a sometimes overly complex API is trying to achieve.
“API security,” he said, “is a world of developers and business logic, and malicious hackers often can have a deeper understanding of the business logic of an API than developers do. When there is a situation that has to be fixed, it has to be translated to a developer. But this developer might not think, ‘how would a hacker abuse this?’ or ‘why would anybody do this four times in one second?’”
This is why it’s critical for security practitioners to grasp business logic. They must understand, from the level of a product manager, what the API is trying to contribute to and how a hacker might abuse this.
Thanks to our sponsor, Salt Security
Got feedback? Join the conversation on LinkedIn.
How do APIs Serve your Business?
APIs form a central part of the operation of any business, but many organizations treat them the way they used to treat traditional web applications: by pen testing or red-teaming periodically and assuming that tools like WAFs will protect API traffic. APIs are often treated in isolation with little consideration given to the overarching business logic. But APIs are aggressively changing, and most companies do not realize just how vulnerable they are. Unlike other attack vectors, this is not a situation where a person must click on something. It’s public, it’s on the internet, and anyone can access it.
For Nina Wyatt, svp, CISO, Sunflower Bank, risk management is vital to business logic since it allows for targeted security policies instead of a broad-brush approach. Risk management must be applied to an organization’s entire API inventory since each API represents a unique value and risk to the business.
“Security specialists have the tech expertise,” said Wyatt, “but when you apply risk management to the equation, you can say, ‘here’s the context – the business logic – this is what the API is actually touching,’ and then you can collaborate on what controls should apply.”
She added that there remains a specific cultural mindset in IT security akin to a “patch mentality” that seeks to close as many threat windows as possible, but the reality is, a more thoughtful process needs to happen. APIs need to be mapped to business operations to see exactly how they are introducing risk and how that can be mitigated.
Don’t get Mired in the Complexity of APIs
It’s easy to let the complexity of APIs send you down a rabbit hole of patching vulnerabilities while separating you from business logic.
Ben Walther, principal security engineer, Atlassian, stated that a “Top 25” checklist is fantastic for improving API security, but in terms of preventative practices, you always have to have human intuition involved.
For more, read “25 API Security Tips You’re Probably Not Considering.”
“Checklists by themselves will never allow you to consider the business context or impact. There are steps in threat modeling that explicitly include identifying assets, or mechanisms to detect and exploit those assets and the business impact of those exploits. But for this you need someone with a strong business context and understanding along with the technology experts in the room.
Ben suggested teams get out of the building mindset and into the breaking mindset, specifically, the builders-breakers-defenders model that OWASP uses.
Nir Rothenberg advocated keeping as close to a single point of entry as possible, since more entry points means more monitoring, more difficult trend detection, and greater chances for errors when patching.
Nina Wyatt added, “For an organization to adopt all the best practices in a Top 25 API Security tips article would not make sense by itself. All are great suggestions, but everything must be associated with the business focus and risk – let’s not create more work than is necessary.”
Ensuring that security initiatives are applied to the right APIs in the context of business processes and business logic means letting product managers step up and take a more prominent role in your API security. They’re the ones driving the purpose behind a product or an API. Chances are they can provide the business logic that will make the process of API security more manageable. Heck, they may have already written it down in the product documentation.
The opinions expressed within this article by Nina Wyatt are hers alone and are not associated or representative of her professional network, associations, or her employer, Sunflower Bank.
The opinions expressed by Ben Walther in this article are his alone and not associated or representative of his professional network, associations, or his employer, Atlassian.