Top 5 Configurations to Check When Setting Up a New SaaS App

Originally published by Adaptive Shield.

Written by Hananel Livneh, Adaptive Shield.

The old days of buying new software, installing it on the company servers, and making sure everything works is gone. All hail the new IT king - SaaS platforms. Ready to go from the start, no installation needed, no hardware involved, and easy to connect the organization and its users. An IT department haven of sorts. Yet the ease of connection should not create a false sense of security. Every SaaS platform’s settings need to be hardened to protect the company's assets. While the settings are built-in natively, configurations are not always enabled by default, and are critical for SaaS security.

The responsibility to ensure the SaaS app settings are set correctly falls on the shoulders of the security team who are already overburdened with work. This blog post aims to ease that burden by providing a basic SaaS security checklist to make sure the basics are covered. I do want to stress the importance of tightening all security configurations. This list is not all encompassing, and there are other configurations that need to be checked that are SaaS-app specific.

Connect SSO Where Possible

One of the most important tools to secure a SaaS platform, and sadly one of the least properly set up tools, is SSO.

Single Sign On, SSO, is a powerful tool for taking care of one of the biggest problems in the SaaS world - too many passwords and access control. Every employee has access to dozens of SaaS platforms, and each and every one requires a username and password. This is a security disaster waiting to happen with users recycling passwords, writing them down on post-it notes, and saving them on the computer in an insecure manner.

SSO enables you to avoid all of this, and just connect using the organization's SSO. As the name suggests, Single Sign On eliminates this to a single place to log into. Every organization should have an SSO, and that SSO should be connected to each new SaaS integration app used by the organization.

Now add to the SSO an IdP (Identity provider) / Federation where supported, and you are set to have a much easier life managing any SaaS platform. This allows your users to be managed and for you to control access to the different SaaS apps from one central point.

Set Up MFA

Multi Factor Authentication (MFA), previously known as Two Factor Authentication (2FA), is a critical security feature, necessary not only for organizations, but also for private accounts. MFA is a simple concept, requiring in a log-in to not only provide a password but also a second form of authentication such as a physical key, SMS, authentication app, and others. The reason for adding this second layer of protection is first and foremost the importance of not basing the whole security of an account on a single point of failure. The second reason is that passwords are not the best form of authentication. Users recycle passwords, use easy to guess or brute force passwords, write them down on pieces of paper, and other human behavior that can compromise the password. Therefore, adding an additional layer of security is very much needed.

Not all SaaS apps allow you to connect them to an SSO, and sometimes you’ll want to allow some users to bypass SSO. Admins, for example, should be allowed to bypass SSO so they can manage the SaaS app at all times, especially if there is an SSO failure. When you allow users to bypass SSO, or don’t use SSO at all - a strong password policy and adding MFA becomes your first line of defense.

The SSO is another place that needs special care. Since, of course, there is no SSO for the SSO app, the access to the SSO account needs MFA and a strong password policy. This is the key to the kingdom, and should be secured appropriately.

When deciding on the additional factor to use for MFA, it is recommended to avoid using SMS (and use instead a physical key or an authenticator app). The reason for this is that it is relatively easy to intercept and fake SMS messages. Attacks on the SS7 protocol that are used, among other purposes, for SMS are well documented and have been used for attacking accounts that use SMS for MFA.

Set Up a Strong Password Policy

A strong password policy sounds like a simple matter. Force 8 characters, upper case, lower case, number, special character, and rotate the password every 90 days. This is what most enterprises do, yet this is not usually the default of a SaaS integration, and therefore should be configured to match your organization's password policy. Setting up a strong password policy can help minimize security risks of an account breach. Together with MFA, it is an extremely good protection measure.

If your organization does not have a password policy, or is in a position to change it, we recommend following the updated recommendation of NIST, the US National Institute of Standards and Technology, which is well known in the security world as the leader in recommendations and standards. NIST recommends, based on the NIST Special Publication 800-63B, the following password policy:

Don’t Make Mandatory Password Changes

Users will recycle passwords, write them down, and choose easy passwords to brute force if they are forced to switch passwords frequently. It is better to have a very strong password, and change it only if there is a chance it was compromised.

Use Long Passwords Over Complex Ones

Combinations of numbers, special characters, and lower-upper cases usually follow the format of “Password1!”. This is easy to brute force. Much better to use a very long password that is easy to remember - such as “MyPetAlligatorAteMySchoolHomework”. Use a minimum of 8 characters, but consider forcing at least 12 and encourage users to have 16 characters for their passwords. The example above is 33 characters long but extremely easy to remember and very hard to brute force (entropy of roughly 150 bits).

Limit Password Attempts

Don’t allow a user to endlessly try to put in the correct password. This is usually a brute force attempt. Or just a really hard password to remember. In any case, it shouldn’t be allowed. We recommend limiting it to no more than 10 attempts.

Implement Screening of New Passwords

Screen new passwords against published passwords, dictionaries, the name of the user, and other easy to brute force. Many SaaS providers already have such tools available to enforce.

Limit Privileged Roles and Admins (General Governance)

Another important aspect of setting up a SaaS app in your organization is planning the governance scheme. Many times this is ignored, and then all users get very high privilege roles and scopes. This is a major security and privacy risk, since it only takes one highly privileged account to be breached, and then the whole SaaS tenant is at risk.

It is recommended to use the principle of least privileged access needed. This mindset and security policy is one that is practiced wherever sensitive information is to be found. The idea is that every user should get exactly the role and scopes needed to perform his or her work, and nothing else. If an employee does not need admin access, they shouldn’t receive such a role.

Yet it is important not to go on the extreme with this philosophy. Every organization should have at least 2 org admins for each SaaS. This allows continuity in case one of the admins has a problem with accessing the SaaS. Also, it is recommended that the bigger the tenant is, the more admins are added to help monitor the SaaS and assist users where needed. It is difficult to strike the balance between too few admins to manage the account and too many that there is a security risk. The key way to deal with this is to continually monitor the amount of admins, and have at least an annual review of all admins and decide what the limit should be.

Set Up Continuous Monitoring and Connect to SIEM

Well done. You set up the SaaS app, all is working, hardened, and ready to go. But how do you know your SaaS security posture will stay secure overtime? Configurations can be changed, privileged roles granted, extra scopes given, data exposed and many other disastrous changes to the SaaS settings, you put so much effort into securing. The solution for this is to set up continuous monitoring for the SaaS, often called an Audit Trail. Make sure it is configured to record any security related change in the system. Then make sure alerts are set up so you don’t need to review the logs every day of every SaaS app that you have. With an SSPM solution like Adaptive Shield, your security team can continuously monitor their SaaS security posture and receive real-time alerts when configuration drifts happen.

Finally, it is recommended to send all the logs to a central source, such as SEIM. This allows you to monitor all the SaaS apps from one plane of glass. Also, it allows you to keep an independent source of truth regarding what has happened in your SaaS. This is very important if there is a breach, since it allows you to understand how this happened, when, and how the SaaS was affected.