Questions For Saas Applications Provider Crucial Questions To Ask Your Future SaaS Applications Provider

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!?

Is there a problem?

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.

Ready? GO!

#1 How will you handle onboarding and offboarding of my users?

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?

Here are some answers you don’t want to hear:

1. This process will be manually executed by your service desk administrators
2. You need to give and upload a CSV file (again!) to their system on a regular basis.

Both answers mean that:

1. You will have yet another step in your process which needs manual effort and is error-prone
2. You will have to introduce some steps to make sure it is working.

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:

1. How are they planning to offset these costs for you?
2. What is their roadmap for fixing it? Make sure this roadmap is a part of your contract!

We are far beyond the point where this could be a technical problem. The technology is there.

Solution

What you should require from your SaaS application provider in this area and questions you should ask are:

1. Are you giving support for provisioning protocol like SCIM (System for Cross-domain Identity Management)? It is the right solution to this problem. Modern Identity as a Service platforms (like Azure AD) or identity management software (like Omada Identity Suite) support SCIM as protocol. SCIM allows automation and identity information provisioning across cloud applications and it will make your life easier.
   Familiarize yourself with this name and ask about it when buying a new application.
2. If not SCIM support, do you provide a user management API with your product which lets us automate management? And believe me – a CSV file is not the answer to the API question! The right API coverage will allow you to integrate this application into your process. This will require some work and time.
   Make sure you have this included in your total cost of ownership calculation!

Now that we have provisioning covered, let’s move to another one.

#2 Where’s my SSO and security?

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.

Why does it matter? Why insist on SSO to a service?

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.

Here are the questions you should ask here before jumping on a given service:

1. Will you provide us with the ability to use our existing SSO service (be it IdaaS as Azure AD or on-premises like ADFS or Ping) with yours?

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.

2. If you use passwords, how are they stored and protected?

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.

3. How do you protect our data and service? Can you show us reports on it?
   A good example of such an approach is what the Azure AD team has recently provided on their blog: a short description of how they manage service provided for others from a security perspective. This is backed by the  Trust Center documents with all the reports and certifications.

Can you get similar statements from your SaaS provider? You should!

#3 How we can troubleshoot access to your application?

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.

What to ask your SaaS provider?

1. Are you sharing auditing and diagnostic logs from our users tenants for our access?

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.

2. Are you giving a security audit log showing user login and activities in the app?

If you use your identity service, you can audit user actions. This ends when they are entering the SaaS application’s realm.

• What are the user activities there?
• When do they log on?
• Who logged on?
• What actions were taken?

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!

Be ready to ask for answers

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:

1. You will have to handle user onboarding offboarding:
   • Does your SaaS provider support standards like SCIM for it?
   • If not SCIM, are they giving easy to use API for this purpose?
   • If not, how are they going to make this easy for you? Remember, a CSV upload is not the right answer!
2. Handling authentication at your end gives better user experience and allows you to manage security:
   • Do your SaaS vendors support standard protocols like OpenID Connect or SAML to provide SSO?
   • If not, how are they protecting passwords stored in the service?
   • How do they protect and verify service security?
   • What are the procedures for detection and notification of a security breach?
3. Being able to audit and monitor user actions is important for support and security:
   • Does your SaaS provider deliver audit and activity log for this application?
   • Can you access diagnostic information which will allow you to troubleshoot problems with it?
   • Is auditing information available over API to use in your monitoring schema?

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!