Nowadays it’s practically impossible to conduct business without SaaS applications. Still, their implementation involves more than just paying for a subscription. There are key issues to resolve before adopting a new solution, so that your business is not exposed to security risks or additional costs.
You hear a lot about SaaS applications, and about how software is eating the world. The truth is, it is! They are becoming (if they’re not already) increasingly common in our work.
Recently one of my friends, a freshly minted CEO of a consulting company, has shared his list of SaaS applications. His company is using 10 different solutions and spends around 2.5k EUR on them. Monthly. This is a small consulting shop with only a few people.
We at Predica, with 80+ people on board, are using lots of SaaS applications. Starting with Office 365 and Dynamics CRM, going through development tools and up to software that lets us work better like 7Geese or Wazoku.
Any company you’ll pick is using SaaS right now. Including yours. And the numbers are growing, every day!
You may ask: so what!?
So many applications! We’ve been there before as an industry. This is how we ended up with all the issues of account management, credentials, passwords… This time it is even more complex as anyone, literally anyone in your organization might start to use a new SaaS solution.
The thing is – we’ve have learned some lessons and technology has moved ahead. Today I will give you the playbook – the three crucial points you want to ask your SaaS providers from a security perspective, where at least some of them don’t want to hear them.
Use it as your guide, checklist or simply to verify applications before bringing them on board and drive the discussion with the vendors.
It must start somewhere. You need to onboard your user and close their access to an app when they leave the company.
How is your application provider going to make it easy for you and prepare it to integrate with your processes?
This generates added cost and over time it might add up both in operations and their outcome (increased risk, compliance issues).
If this is the case, consider dropping this solution and looking at some alternatives. If you’re still thinking of using this application (you may need it for some reason) – ask your SaaS provider:
We are far beyond the point where this could be a technical problem. The technology is there.
What you should require from your SaaS application provider in this area and questions you should ask are:
Now that we have provisioning covered, let’s move to another one.
The industry has worked hard over the years to get to the point where we have the working technology and services, enabling us to reduce the need for separate credentials for each service.
Simply put – we have the tools to enable SSO for SaaS applications. Yet, many vendors are ignoring this fact and often don’t give a choice to enable secure, enterprise-enabled SSO for their application.
What I personally find even more problematic, is when a vendor decides to charge additional money for enabling it! But sure, it’s their service and they can price it as they wish.
First, the user experience and your operating costs. The former requirement doesn’t have to be explained: if users are able to just to get to the new app without new credentials, they will love it. It will also lower your costs of operation.
Second, even more important – security! Using an authentication service means that you can enforce your own policies like MFA and conditional access across all the apps.
You can do it at authentication point. You don’t need the app to provide it and you don’t need to configure it there.
If the app provider does not allow you to Bring Your Own Security, they should provide a matching level of protection to you within their environment.
If not, send them back to the drawing board. Ask when they are going to provide it and make it part of the contract! Not using it means higher operations costs for you and a lower security level.
With SSO through your service, you are managing security. With local accounts and passwords, you can’t do this. You don’t want to learn that passwords leaked from the service.
Ask your provider how do they store and secure passwords? What are the procedures to detect password leaks and notifications of those to customers? You don’t want to find out from a HaveIBeenPwned notification.
Can you get similar statements from your SaaS provider? You should!
Support! Support is important, you don’t want to leave your users with “I don’t know” when the shiny new app is not working.
What I’ve learned so far is that with SaaS applications we are missing one crucial point to be able to effectively support our people – the other end.
You can check your environment, you can check what’s going over a wire, but you can’t check what is going on within the application. And in many cases, the answer is there.
If you can’t access those, you will always have to involve support on the provider’s side in troubleshooting. In that case, make sure that you have the right support coverage matching your SLA from their end.
If you use your identity service, you can audit user actions. This ends when they are entering the SaaS application’s realm.
Ask your provider if you can get these logs and if possible, can you get them through API to incorporate them into your auditing and monitoring tools?
Getting NO as answers should raise red flags for you!
This is definitely not a complete list of questions you should ask your SaaS provider. However, they should give you a good starting point to the discussion with them about the way you can manage and secure access to the service.
Let’s do some quick recap on the topics you should cover:
Don’t be afraid to raise these points. They should already have answers to them. If not – this is because their customers are not putting the right pressure on them to have those answers already.
And as customers, we should insist on having them discussed. This is the way we can move forward and not end up with SaaS applications’ (in)security problem we have created over the years on-premises.
If we have a chance to set the record straight and fix things – we should do it!
Need more advice? Get in touch!
Your ticket time resolution is taking too long, new issues are coming, but you are tied by a pile of incidents that are ...
I covered security in GitHub last time. But some of you likely use Azure DevOps for building your products, so let’s t...