The US National Institute of Standards and Technology (NIST) cybersecurity framework is one of the world’s most important guidelines for securing networks. It can be applied to any number of applications, including SaaS.

One of the challenges facing those tasked with securing SaaS applications is the different settings found in each application. It makes it difficult to develop a configuration policy that will apply to an HR app that manages employees, a marketing app that manages content, and an R&D app that manages software versions, all while aligning with NIST compliance standards.

However, there are several settings that can be applied to nearly every app in the SaaS stack. In this article, we’ll explore some universal configurations, explain why they are important, and guide you in setting them in a way that improves your SaaS apps’ security posture.

Start with Admins

Role-based access control (RBAC) is a key to NIST adherence and should be applied to every SaaS app. There are two types of permissions within a SaaS application. Functional access covers things like creating accounts and navigating the application. Data access permissions, on the other hand, govern which users can retrieve and modify data. The admin account (or the super-admin account in some apps) is the most sensitive within the app, as it has full access to both types of permissions.

For threat actors, breaching an admin account is akin to winning the lottery. They have access to everything. Organizations must do everything within their power to maintain control over these accounts. This control is managed through configurations and best practices.

Implement Limited Redundancy

It’s important to have a minimum of two admins for every application. This redundancy makes it difficult for an admin to act alone against the best interests of the organization, as admins can monitor each other for any signs of a breach.

However, each admin increases the application’s attack surface. Organizations must strike a balance between having enough admins to adequately service the application while limiting exposure. An automated review of the number of admins should trigger alerts when the number of admins is outside the preferred range.

Eliminate External Admins

External admins introduce a new layer of uncertainty into SaaS security. Because they sit outside the organization, the security team can’t control the password policies or authentication tools that they use.

For example, should a threat actor try to log into your application and click Forgot Password, there is no way to know whether the threat actor can breach the external admin’s email account. That lack of oversight of external users could lead to a deep breach of your SaaS application, which is why NIST advises against having external admins. Depending on the application, either block external admins from getting admin privileges or identify external users with admin rights and remove those privileges.

For companies that hire an external IT company or outsource to MSSPs, those individuals should not be considered external. However, they should continue to monitor for other external users being given admin permissions.

Require Admin MFA

To comply with NIST standards, all admin user accounts should be required to access the application using multi-factor authentication (MFA), such as a one-time password (OTP). MFA requires users to present a minimum of two forms of ID before it authenticates the user. A threat actor would need to compromise two authentication systems, increasing the level of difficulty of the compromise and reducing the risk to the account. Make sure to set MFA for admins as required (we also recommend MFA for all users, but it is a must-have for admins).

Download this checklist and learn how to align your SaaS security with NIST

Prevent Data Leaks

SaaS data leaks pose significant risks to organizations and their users, potentially compromising sensitive information stored within cloud-based applications. SaaS applications are marketed as collaboration tools. However, the configurations that enable users to work together can also compromise files and data. NIST, for its part, advocates monitoring the permissions of every resource.

A visible calendar can expose employees to socially engineered phishing attacks, while shared repositories can lead to a company’s internal source code being shared publicly. Email, files, and boards all contain sensitive data that should not be accessible to the public. While the following configurations are often called something different in each application, almost any app that stores content will have this type of control.

Stop Public Sharing

The difference between Share with All and Share with a User is profound. When items are shared with all, anyone with a link can access the materials. Share with a User, in contrast, adds an additional authentication mechanism, as the user needs to log in before accessing the material.

To reduce the content that is exposed, app admins should disable sharing over public URLs (“Anyone with the link”). In addition, some applications allow users to revoke access to URLs that have already been created. When available, organizations should be sure to toggle that setting to on.

Set Invitations to Expire

Many applications allow authorized users to invite external users to the application. However, most applications don’t implement an invite expiration date. In those circumstances, invites sent years prior can provide access to a threat actor who has just breached an external user’s email account. Enabling an auto-expiration date on invites eliminates that type of risk.

It’s worth noting that in some apps, configuration changes are retroactive, while others will only take effect moving forward.

Align your SaaS Security with NIST standards – download the full guide

Strengthening Passwords to Harden Application Security

Passwords are the first line of defense against unauthorized access. NIST advocates for a strong and well-managed password policy, which is essential to protect sensitive user data, confidential business information, and proprietary assets stored within the cloud-based infrastructure. The uniqueness, complexity, and regular updating of passwords are critical aspects of a robust security posture.

Passwords serve as a fundamental element in a layered security approach, complementing other security measures such as multi-factor authentication (MFA) and encryption. Compromised passwords can be a gateway for malicious actors to exploit vulnerabilities in the SaaS environment. The effective management of passwords enhances the overall resilience of SaaS systems, contributing to a more secure and trustworthy digital ecosystem for both businesses and their users.

Prevent Password Spray Attacks

In a spray attack, threat actors enter a username and common password terms, hoping to get lucky and access the application. Requiring MFA is the recommended way to prevent password spray attacks. For those that don’t insist on employees using MFA as part of the authentication process, many apps allow organizations to ban words from being used as passwords. This list of words would include terms like password1, letmein, 12345, and the names of local sports teams. Additionally, it would include terms like the user’s name, company products, partners, and other business terms.

Going into the configurations and adding a custom banned words list can significantly reduce the risk of a successful password spray attack.

Password Complexity

Most SaaS applications allow the organization to customize password complexity. These range from allowing any password to requiring alphanumeric characters, capital and lowercase letters, symbols, or a password length. Update the password requirements in the app to match your organization’s policy.

If your organization doesn’t have a password policy, consider following NIST guidelines:

1. Don’t make mandatory password changes, as users tend to choose easy-to-remember passwords.
2. Use long passwords over complex ones. Combinations of numbers, special characters and lower/upper case characters usually follow a format like this: Password1!. These are easy to brute force. A long password like MyFavoriteDessertIsPecanPie is easy to remember but with 27 characters, difficult to brute force.
3. Limit password attempts to no more than 10.
4. Screen passwords against published passwords and other easy to guess words with a banned words list.

Configurations Really Matter

Approximately 25% of all cloud-related security incidents start with a misconfigured setting. In addition to those mentioned here relating to access, password, and data leaks, which are fairly universal, configurations are used for key management, mobile security, operational resilience, phishing protection, SPAM protection, and more. Misconfigurations in any of those areas can lead directly to breaches.

It may seem unlikely that threat actors spend their time looking for misconfiguration that they can exploit. Yet, that is exactly what the Russian state-sponsored group Midnight Blizzard did when it breached Microsoft this year. If misconfigurations can happen at Microsoft, it’s worth reviewing to make sure that your applications are all secure.

See how you can apply NIST standards to your SaaS stack