The cybersecurity framework from the US National Institute of Standards and Technology (NIST) is one of the world’s most important guidelines for protecting networks. It can be applied to any number of applications, including SaaS.
One of the challenges faced by those tasked with securing SaaS applications is the different settings found in each application. This makes it difficult to develop a configuration policy that applies to an HR app that manages employees, a marketing app that manages content, and a R&D app that manages software releases, all while aligning with NIST compliance.
However, there are several settings that can be applied to almost any app in the SaaS stack. In this article, we’ll explore some universal configurations, explain why they’re important, and walk you through setting them up to improve the security of your SaaS apps.
Start with administrators
Role-based access control (RBAC) is critical to NIST compliance 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, determine which users can retrieve and modify data. The administrator account (or super administrator account in some apps) is the most sensitive within the app, as it has full access to both types of permissions.
For threat actors, hacking into an administrator account is like winning the lottery. They have access to everything. Organizations must do everything in their power to maintain control over these accounts. This control is managed through configurations and best practices.
Implement limited redundancy
It is important to have at least two administrators for each application. This redundancy makes it difficult for an administrator to act alone against the interests of the organization, as administrators can monitor each other for signs of violations.
However, each administrator increases the attack surface of the application. Organizations must find a balance between having enough administrators to adequately manage the application and limiting exposure. An automated review of the number of administrators should trigger alerts when the number of administrators falls outside the preferred range.
Eliminate external administrators
External administrators introduce a new level of uncertainty into SaaS security. Because it is outside the organization, the security team cannot control password policies or authentication tools used.
For example, if a threat actor tries to log in to the application and clicks Forgot Password, there is no way to know whether the threat actor can breach the external administrator’s email account. This lack of oversight of external users could lead to a profound breach of your SaaS application, which is why NIST advises against having external administrators. Depending on the application, prevent external administrators from gaining administrator privileges, or identify external users with administrator rights and remove those privileges.
For companies that hire an outside IT company or outsource to MSSPs, such individuals should not be considered external. However, they should continue to monitor whether other external users are granted administrator permissions.
Apply for MFA Admin
To comply with NIST standards, all administrator user accounts should be required to log in to the application using multi-factor authentication (MFA), such as a one-time password (OTP). The MFA requires users to present at least two forms of ID before authenticating the user. A threat actor would have to compromise two authentication systems, increasing the difficulty level of the compromise and reducing the risk to the account. Be sure to set up MFA for administrators as required (we also recommend MFA for all users, but it’s a must for administrators).
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, setups that allow users to work together can also compromise files and data. NIST, for its part, supports monitoring the permissions of each 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. Emails, files and message boards all contain sensitive data that should not be accessible to the public. Although the following configurations are often called differently in each application, almost all apps that store content will have this type of control.
Stop public sharing
The difference between Share with everyone and Share with one user is profound. When items are shared with everyone, anyone with a link can access the materials. Share with a user, on the other hand, adds an additional authentication mechanism, since the user must log in before accessing the material.
To reduce exposed content, app administrators should disable sharing to public URLs (“Anyone with the link”). Additionally, some applications allow users to revoke access to URLs that have already been created. When available, organizations should ensure that they enable this setting.
Set the invitation deadline
Many applications allow authorized users to invite external users to the application. However, most applications do not implement an invitation expiration date. In such circumstances, invitations sent years ago can provide access to a threat actor who has just compromised an external user’s email account. Enabling an automatic expiration date on invitations eliminates this type of risk.
It’s worth noting that in some apps, configuration changes are retroactive, while others will only take effect in the future.
Align your SaaS security with NIST standards: download the complete guide
Strengthen passwords to strengthen application security
Passwords are the first line of defense against unauthorized access. NIST supports a strong, well-managed password policy that is essential to protecting sensitive user data, confidential company information, and proprietary assets stored in cloud-based infrastructure. Uniqueness, complexity and regular updating of passwords are critical aspects of a strong level of security.
Passwords are a key element in a layered security approach, complementing other security measures such as multi-factor authentication (MFA) and encryption. Compromised passwords can provide a gateway for attackers to exploit vulnerabilities in your SaaS environment. Effective password management improves the overall resilience of SaaS systems, contributing to a more secure and reliable 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 gain access to the application. Requiring MFA is the recommended way to prevent password spray attacks. For those who don’t insist that employees use MFA as part of the authentication process, many apps allow organizations to prohibit the use of words as passwords. This list of words would include terms such as password1, letmein, 12345, and the names of local sports teams. Additionally, it would include terms such as your name, company products, partners, and other business terms.
Going into your configurations and adding a custom list of banned words 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, uppercase and lowercase letters, symbols, or a password length. Update the password requirements in the app to match your organization’s policies.
If your organization does not have a password policy, consider following the NIST guidelines:
- Don’t make mandatory password changes, as users tend to choose passwords that are easy to remember.
- Use long passwords rather than complex ones. Combinations of numbers, special characters, and lowercase/uppercase characters usually follow a format like this: Password1!. These are easy to use with brute force. A long password like MyFavoriteDessertIsPecanPie is easy to remember but at 27 characters, difficult to brute force.
- Limit password attempts to no more than 10.
- Compare passwords with published passwords and other easy-to-guess words against a list of banned words.
Configurations really matter
Approximately 25% of all cloud-related security incidents begin with a misconfigured setting. In addition to the ones mentioned here related to login, password and data leakage, which are quite universal, configurations are used for key management, mobile security, operational resilience, phishing protection, SPAM protection and more . Configuration errors in any of these areas can directly lead to violations.
It may seem unlikely that threat actors spend their time looking for misconfigurations they can exploit. Yet, that’s exactly what the Russian state-sponsored group Midnight Blizzard did when it hacked Microsoft this year. If misconfigurations can occur at Microsoft, it’s worth looking into them to make sure your applications are all safe.
Learn how to apply NIST standards to your SaaS stack