Time to Consolidate Your Web App and API Security Mess – InApps Technology 2022

When he was training to fight George Foreman in the famous “rumble in the jungle,” Muhammad Ali waved off the famed knockout power of his rival, declaring that “his hands can’t hit what his eyes can’t see.”

Fast-forward to the present and Ali’s observation still packs a punch when it comes to describing one of the biggest problems in the contemporary security world that nobody’s talking about: the utter lack of visibility when it comes to protecting apps and APIs.

Simply put, it’s impossible to secure what you don’t know about. But all too often, organizations simply don’t have any idea what’s running on their networks. Companies that added security tools in a one-off fashion (due to multiple acquisitions over time, for example) find themselves with mediocre protection as new kinds of threats become headline news. What’s more, traditional tools were not built with the modern, decentralized enterprise in mind and often cause more problems than they solve.

Every mobile app and single-page app now exclusively calls into an API. If enterprises are going to protect the APIs and apps that are now so critical to their success, they need to start rethinking some parts of their security posture and addressing these gaps.

How We Reached This Point

A few years ago, the number of internally developed applications began to soar. According to research company ESG, the average number of home-grown applications increased to 195 from 139 two years ago, and it’s now projected to soar to 263 within the next couple of years.

At the same time, there were more APIs than ever. But as they hurried to get things done under pressure to ship, developers often bypassed established corporate channels (read: slow and bureaucratic) to launch APIs on the network. That same eagerness to move ahead without first getting code blessed by IT or security added new security risks. The result was API sprawl with no uniform protection and policies. Let’s say you’ve got 20 APIs built by 20 different groups and they all come up with 20 different security models and protections. That disjointed scenario poses a high-severity risk if and when attackers find a way to exploit it.

Meanwhile, the corporate world went on a buying spree. ESG surveyed enterprise customers who reported that they now use an average of 11 separate security tools to manage their web application and API security.

I fully appreciate building a defense-in-depth strategy that incorporates individual products that are great at specific tasks. The problem is that these products rarely function in an integrated fashion or even talk with each other. Instead, they sit in silos and often don’t work together. So, you might ask yourself what’s the point?

Finally, a lot of the tools that were purchased weren’t designed for newer architectures like GraphQL or REST APIs. In other words, they now comprise what’s known in the profession as technical debt.

Needed: Leaders with Vision

Fixing the situation starts with CEOs who have confidence in the judgment of the CIO or CISO so they can tell their boards that slowing down a bit and not playing stop-the-threat-of-the-day bingo is in the long-term interest of the company.

On the surface, that might sound counter-intuitive. But think about it; the DevOps movement proved that rapid automation and testing and rapid iteration would translate into more innovation. But innovation filled with risk is not really the end game. The next crucial step is to implement security directly into the internal app and API workflow process so it is not a hurdle to work around, but a part of the process that can move as quickly as the rest if done right. Otherwise, it’s just more of the same, and security will remain elusive.

You can go slow at first and prove out the thesis with a small project to demonstrate how it can work. I’ve done that on several occasions. In the end, I was able to show that despite a short-term slowdown to implement the changes, we were soon back to normal, cranking out the same innovations at the same iteration pace as before.

Here’s where leadership counts for everything. Security is no longer one of those topics where the CEO doesn’t understand or isn’t sufficiently motivated to learn about it. It requires forward-looking executives who understand the big security picture and can articulate why it’s critical to improve overall processes and clear away the clutter.

Lather, Rinse, Repeat

Forget about pulling out the corporate checkbook and going on another buying bender. In that ESG survey I just referenced, 93% of the respondents expressed interest in deploying a consolidated web application and API security solution. They rightly viewed that strategy as the best way to provide consistent protection across disparate application architectures and environments, all while reducing costs.

Before you get to that elevated realization, take an inventory of your APIs. Once you finish a complete audit, create a plan to secure what’s on your system. Development teams and security teams should work together so whenever a new API gets created, they apply the appropriate risk status.

Don’t try to secure everything at once. Prioritize projects based on risk. Then march down the list. The unfortunate reality is that you’re going to get compromised. What you want to do is minimize the potential damage, and that comes from making sure that the data and systems that are most precious have the most protection first.

Then it’s a matter of lather, rinse, repeat.

Believe me, there will be a time when you are really glad that you are not still throwing spaghetti against the wall to see what sticks.

Read Fastly’s new report on securing web apps and APIs.

Feature image via Pixabay.