We’ve made a point of shoring up security for infrastructure-as-a-service clouds since they are so complex and have so many moving parts. Unfortunately, the many software-as-a-service systems in use for more than 20 years now have fallen down the cloud security priority list.
Organizations are making a lot of assumptions about SaaS security. At their essence, SaaS systems are applications that run remotely, with data stored on back-end systems that the SaaS provider encrypts on the customer’s behalf. You may not even know what database is storing your accounting, CRM, or inventory data—and you were told that you should not really care. After all, the provider runs the entire system for you, and users and admins just leverage it through some web browser. Indeed, SaaS means that you are abstracted much further away from the components than other forms of cloud computing.
SaaS, as indicated in most marketing studies, is the largest part of the cloud computing market. This is not well understood since the focus these days is on IaaS clouds such as AWS, Microsoft, and Google, which have drawn attention away from the largely fragmented world of SaaS clouds, which are mostly as-a-service business processes you access through a browser. But SaaS also now includes backup and recovery systems and other services that are more IaaS-like but are delivered using the SaaS approach to cloud computing. They remove you from dealing with all of the nitty-gritty details, which is what cloud should be doing.
I suspect that SaaS cloud security will become more of a priority once a few well-published breaches hit the media. You can bet these are indeed occurring, but unless the public is affected directly, breaches usually don’t make it to a press release.
What do we need to look out for when it comes to SaaS security?
Core to SaaS security problems is human error. Misconfigurations occur when admins grant user access rights or permissions too frequently. The people who perhaps should not have been granted rights can end up misconfiguring the SaaS interfaces, such as API or user interface access. Although this is not much of an issue if rights are restricted, too often people who need only simple data access to a single data entity (such as inventory) are given access to all the data. This can be exploited into devastating data breaches that are highly avoidable.
This is normally an issue with data access that the SaaS vendor provides via user interfaces and API access. However, problems also arise with data integration layers that the SaaS customers install to sync data in the SaaS cloud with other IaaS cloud-hosted databases or, more likely, back to legacy systems that are still held in-house. These data integration layers are often easily breached for the reason just mentioned—mishandling of access rights. The data integration layers themselves, much of which are also SaaS-delivered, may have vulnerabilities. Either way, your data is still breached.
Other security issues are easier to understand. An employee decides to take out some frustrations on the company and copies most of the SaaS-hosted data to a USB drive and removes it from the building. Much like granting more access privileges than someone needs, this is easily addressed with restrictions and more education.
On the SaaS providers’ side, issues include a lack of transparency, such as their own employees walking out of the building with customer data, or breaches that have gone unreported. It’s impossible to know how many of these situations have occurred, but if you’ve had zero reported to you, it may be an indication that your SaaS provider is holding back information that might be damaging to them.
SaaS security is both an old and a new approach and technology stack. It was the first cloud security I worked on, and we’ve come a long way since then. However, SaaS security has not received as much funding, love, or education as other areas of cloud security. We may pay for that at some point unless we get things fixed now.
Copyright © 2022 IDG Communications, Inc.
