This article was originally published in The Hacker News
Securing applications can be an uphill battle. As development accelerates, accountability becomes unclear, and getting controls to operate becomes a challenge in itself. Securing tomorrow’s applications begins with assessing the business risks today. It’s time that we as security leaders rethink our application security strategies to reflect new priorities, principles, and processes in the API-first era.
The trends and risks shaping today’s applications
As the world continues to become more and more interconnected via devices — and the APIs that connect them — individuals are growing accustomed to the frictionless experience that they provide. While this frictionless reality is doubtlessly more user-friendly, i.e., faster and more convenient, it also requires a trade-off. This convenience demands openness, and openness is a risk when it comes to cybersecurity.
According to Sidney Gottesman, Mastercard’s SVP for Security Innovation, the above situation leads to one of the biggest trends shaping the security posture for today’s applications: A crisis of trust between individuals and the applications they use.
A second major trend is that of the supply chain. Simply handling your own risks isn’t enough, as attacks increasingly penetrate internal systems via 3rd party, vendor-supplied components. In digital products and even connected hardware products, supply chains are now composed of different services bundled together in the final product through APIs, creating a new type of integration risk rooted in the supply chain.
If the recent Colonial Pipeline and JBS attacks indicate anything, it’s that another major trend is the abundance of malicious actors, both at the individual and state level. Businesses must now assume that sooner, rather than later, they will be attacked and must be prepared. The abundance of data can not be ignored. Enterprises are storing, managing, and enabling access to so much data, making the application layer (and APIs) more attractive to attackers. Increasing regulations aimed at improving the security postures of both public and private enterprises also get a special spot in the landscape of security trends.
Application security isn’t what it used to be
80% of enterprises currently allow external access to data and functionality via APIs, according to a recent industry survey published by Imvision, looking into the current state of API use and adoption among leading enterprises. The results are in line with other research on the topic, and conclude that enterprises are much more open than they used to be just a few years back – and growing.
But this means that application security has moved beyond its “doorman” status of asking “who’s allowed in?” Nowadays, application security should assume that users are already inside the application and focus on asking “what do we allow them to do?”, “what’s the expected usage?” and “how do we stop undesirable behavior?”.
According to Rob Cuddy, the Global Application Security Evangelist at HCL, the fundamental shift enterprises must make in their approach to application security is that securing the application perimeter from external penetration simply doesn’t make sense in the era of APIs.
Building layers of security around the application won’t work when the application is exposed via APIs. Instead, a new inside-out approach is required. This new approach assumes application penetration in service of the user but puts protective mechanisms in place in case that the actor is malicious.
If you ask developers, they’d tell you that security was there all along, but now it’s become critical. However, it’s not an issue of adding new tools or automations, but rather a matter of making a fundamental shift in people, processes, and culture. In the race for superfast agile deliveries, many enterprises are adopting a DevSecOps approach that mandates the integration of security practices within the development lifecycle. But while many are talking about doing it, only about half are actually doing something about it – meaning, actually having a full lifecycle API security in place.
*** This is a Security Bloggers Network syndicated blog from Imvision Blog authored by Omer Primor. Read the original post at: https://blog.imvision.ai/rethinking-application-security-in-the-api-first-era