Authomize Blog

Listen to this Post

A lot of (digital) ink has been spilled about how the cloud is going to change the way that we work — and for once, the marketers have really undersold how big the impact is going to be.

Don’t get me wrong, some parts of our businesses are going to stay on-prem for a while, but they will be negligible. Even before COVID-19 made most of us remote workers by default, we had already been hurtling towards a reality where all of our work (computing, storage, platforms, and the rest of the “X as a Service) is essentially done on someone else’s computer.

For most organizations, this shifting of their IT infrastructure to Amazon, Google, Microsoft, and the million other cloud services providers has been a good thing. It allows them to do more without growing their IT teams, making the job of keeping everything running like it should someone else’s responsibility.

However, when it comes to security, the question of who is responsible for what is far less clear and leaves many organizations potentially exposed to leaks or attacks.

Who Owns Security in SaaS?

The question of who is responsible for security when it comes to SaaS, PaaS, IaaS, et al is a tricky one, and probably the subject of nearly as many marketing posts after the “Why you need to move to the cloud” genre. For our purposes, and in the interest of length, let’s focus on SaaS.

In short, the answer is that security is everybody’s responsibility, and you need to take it seriously. The problem is that as an industry of service providers and consumers, we have generally done a bad job of defining who is responsible for which aspects of managing security in this arrangement.

Personally, I like this graphic representation of the shared security responsibility model taken from the folks at Microsoft’s Azure Security team. Not only is it clear about when the responsibility is wholly supposed to be owned by the cloud provider or customer, but it also highlights examples where they share responsibility.

For instance, we see here below that matters of identity and directory infrastructure are shared between the customer and the provider without a clear delineation of who is that actual owner here.

source: Microsoft

Challenges to Getting SaaS Security Right

The SaaS environment is by definition highly distributed and easily accessible from nearly anywhere. Managing who can access what requires constant tracking of permissions. Especially in larger organizations where people join, move within, and leave, this can become a difficult challenge to overcome.

There is also a visibility challenge in that the more services we use, the more we grow our threat surface and slip into permission chaos. Part of the problem is that we are not doing a very good job of keeping track of what we are using and where. In practical terms, this means that we might be exposed or vulnerable to attack and not even be aware of the threat vector.

But for an attacker that is putting in the work of scanning for an opening, that hole through the side door is just as good as going in through the front.

To be fair to all parties, SaaS security is hard to manage. A leap of faith is required to hand over so much control to an outside provider that theoretically can make changes to important settings and controls without your involvement.

A SaaS vendor can unwittingly make changes to your app and create an exposure that your team needs to deal with. These changes can also alter the way you monitor and control your security, and that should remind us of the compromise that comes with shifting responsibilities.

So what does a good SaaS security overview have to take into account if we want to do this better?

A few Tips for Working More Securely with SaaS

For starters, take the time to understand who is responsible for what in your relationship with your SaaS provider. I suggest starting with an assumption of TRUST NO ONE.

In the event of a breach or leak, it is your organization that will feel the brunt of the blame for any damages. So even if your SaaS vendor promises you the moon and the stars, it is still your responsibility to double-check and triple-check (and continuously monitor) to the best of your ability, even if control rests in someone else’s system.

With skepticism as your starting point, do your own risk assessment of your exposure with the vendor and address it with them. You should still be setting expectations with them for what they are supposed to be responsible for — even if you don’t fully trust them.

After you have done your assessment, take your findings and start hardening your organization to the extent possible. While never foolproof because everything can and will be hackable, denying an attacker the low hanging fruit with a bit of hardening now can go a long way in avoiding heartache later.

Finally, make security a part of the process of onboarding and managing new SaaS applications or the use of IaaS. Stick to the principle of least privilege wherein you grant just enough permissions to allow your people to do what they need to do, but stop short of it becoming a liability. Chances are that you are probably giving out way more authorizations than you need to or can realistically keep track of.

The way to make this successful is to empower your team by making it as easy as possible for them. Automate where available, especially those that will help them track and monitor who has what authorizations are out there in use. Authorization management, which is key to limiting your exposure, will always be your responsibility to manage and monitor, so take it easy on yourself and use the right tools for the job.

Thinking Big Picture

SaaS is simply the way that businesses will continue to operate in the years to come, so it is up to us to work with it responsibly.

This means knowing what we are using and utilizing technology to manage it better, but also implementing the right kind of policies that will help us to avoid forehead-smacking mistakes.

Yes, the SaaS providers should simplify their management systems, especially around security. Current measures often require the admin to be a human compiler in order to understand what’s going on.

But we in the industry need to think about how we are granting access to people in our organizations. Are we asking questions like if the employee really needs access to as many systems as they do? Or how often do we require that those permissions be reauthorized, thus preventing zombie accounts from living on long after they have any right or reason to?

At the end of the day, we are the owners of our own security, so we’d better act like it.