Forbes Tech Council: Most Companies Underestimate their SaaS Exposure—Don't Be One of Them

This article was originally posted on Forbes as part of their Forbes Technology Council series.

‍

Whether we want to admit it or not, the way we work in 2024 shares a striking amount of similarities to the terminal-mainframe model in the days when computers first entered the general public's eye.

In those days, users would log into computers that served as access points to larger, more powerful, centralized mainframe computers that handled the processing, users, and access. The users would receive the outputs from those larger mainframe computers on their local machine's screens.

In today's world, users log into computers and browsers that serve as access points to larger, more powerful, centralized computers that handle the actual processing, users, and access of the application. Users then receive the outputs from those larger computers on their local machine's screens.

Of course, in modern terms, this is now known as Software-as-a-Service (SaaS), only instead of one mainframe computer we're connecting to many, many other machines that are also connected to many other machines. And instead of needing to access these endpoints from a computer lab or office, we're connecting to them from all over the world. It just goes to show: everything old is indeed new again.

Almost every business-critical application is now cloud-based and offered as a service. And while this adoption of SaaS applications has been great for collaboration, remote work, and dispersed workforces, our collective stomach for securing this new way of working has been lagging. Unfortunately, threat actors have noticed.

Fundamentally, if we're trusting outside companies to process our data – which is, essentially, what logging into a SaaS application is – we're also trusting they are keeping it safe. Often those vendors are relying on other vendors to do the same, creating a spidering effect of interdependencies and nodes of failure. Threat actors love these nodes of failure that give threat actors access to the crown jewels of not just one organization, but many. This is why third-party breaches increased by 68% last year with no signs of slowing down.

Most of us can agree that adoption of SaaS applications – which include various types of AI – isn't going away. (At least not for now, despite AI-generated content constantly reminding us we're in an "ever-changing digital/threat/business landscape.") So instead of trying to fit the round peg of legacy security frameworks into the square hole of conducting business via SaaS applications, let's look at what companies need to do to make sure their environments are not just moving at the speed of business but are protected, too.

To protect your SaaS, you have to know your SaaS

If you ask most company IT/security teams how many SaaS applications are in their environment, the most common answer is that they don't know. The second most common answer is a number that ends up being about half of the actual amount. These answers need to change.

Most of these applications are installed by users in good faith. Think: someone in marketing who connected to a SaaS design tool and – like almost all of us – gave it all the permissions it asked for because more access often means faster output. Once a project is done or a tool is no longer needed, very few people will ever go back in and remove access or users to these tools, either. (How often do any of us go back after a project is over to manually review and remove permissions of a shared document or folder after it's over and we've moved onto the next? I can assure everyone it's not just the marketing department who is guilty of this.)

On average, most businesses actually have 500 business applications connected to their environment, all with varying – and often troubling – permissions. However, most IT/security teams have no visibility into what those applications are, let alone what kind of access they're granted and who in the environment is connected. That means companies often have over 250 applications (on average) running in their environment they have no idea about!

This is exactly why this step of visibility into your SaaS environment is so critical. If you can't see your entire SaaS environment, you can't protect it.

Stop giving SaaS apps permission just because they ask for it

Once you have a full understanding of your SaaS environment the next step is implementing the principle of least privilege on these users and applications. This includes continuous monitoring for old accounts or former employees as well.

We are no longer in the Wild West of connecting SaaS applications, where we can gleefully agree to whatever access they request. This is because these applications will always ask for the maximum amount you'll give them to ensure they'll work as quickly as possible after signup, leading to higher customer satisfaction.

This will be an adjustment for your users. Adding friction to processes that were previously almost mindless tests anyone's patience. They might (read: will) complain about extra steps and permissions. However, they will adjust, just as they did when you implemented MFA or any other previous security policy in the past thirty years. This one step can be the difference between one of your SaaS applications exporting terabytes of proprietary customer data or simply reading it, making this one of the most important pieces of SaaS security you can implement.

The new SaaS paradigm

The wide and fast adoption of SaaS applications isn't something we can secure with legacy architecture or methodologies. If we want to conduct business in this new paradigm, we have to secure it, too.

If the recent breaches associated with Snowflake's cloud storage service showed us anything, it's that threat actors understand what to target to get the most out of their attacks. They are the ultimate "work smarter, not harder" types, and in this case, working smarter means attacking SaaS services and breaching multiple organizations at once for bigger payouts. When the temptation is there, threat actors are ready. It's time to be ready, too.