One of the most crucial standards for network security in the world is the US National Institute of Standards and Technology’s ( NIST ) cybersecurity framework. SaaS is just one of the many applications to which it can be used.
The various settings present in each application present a challenge for those tasked with securing SaaS applications. While adhering to NIST compliance standards, it can be challenging to create a configuration policy that will apply to HR apps that manage employees, content management apps for marketing, and software version management for R&, D apps.
However, almost every app in the SaaS stack has a number of settings that can be used. In this article, we’ll go over some common configurations, explain their significance, and give you advice on how to set them up to enhance the security of your SaaS apps.
begin with administrators
Every SaaS app needs to use role-based access control ( RBAC ), which is essential for adhering to NIST. A SaaS application has two different kinds of permissions. Account creation and application navigation are examples of functional access. On the other hand, users are limited in their ability to retrieve and edit data by data access permissions. Since it has complete access to both types of permissions, the admin account ( or super-admi account in some apps ) is the most sensitive part of the app.
Breach of an administrative account is comparable to winning the lottery for threat actors. Everything is available to them. To keep control over these accounts, organizations must exert every effort. Best practices and configurations are used to manage this control.
Use limited redundancy
For every application, there must be at least two administrators. Due to the redundancy, administrators can keep an eye out for any indications of a breach, making it challenging for them to act independently against the organization’s best interests.
However, the attack surface of the application grows with each administrator. Organizations must strike a balance between limiting exposure and having enough administrators to adequately support the application. When the number of administrators exceeds the preferred range, an automated review of that number should sound an alarm.
Remove External Administrators
SaaS security gains a new layer of uncertainty thanks to external administrators. The security team is unable to influence the password procedures or authentication tools they employ because they are located outside the organization.
For instance, it is impossible to determine whether a threat actor can access the external admin’s email account if they attempt to log into your application and click Forgot Password. NIST advises against having external administrators because doing so could result in a serious breach of your SaaS application. Depending on the application, you can either deny access to admin privileges to outsiders or recognize and remove admin rights to external users.
These people should n’t be regarded as external by businesses that outsource to MSSPs or hire an outside IT firm. They should still keep an eye out for admin permissions being granted to other external users, though.
Need an administrative MFA
All admin user accounts must use multi-factor authentication ( MFA ), such as a one-time password ( OTP), in order to access the application in accordance with NIST standards. Before MFA authenticates a user, they must provide at least two forms of ID. Two authentication systems would need to be compromised by a threat actor, which would make the compromise more challenging and lower the account’s risk. Set MFA for administrators as required; while we also advise all users to use it, admins must have it.
Learn how to integrate your SaaS security with NIST by downloading this checklist.
Stop Data Leaks
SaaS data leaks put organizations and their users at serious risk because they could compromise sensitive data kept in cloud-based applications. Applications for SaaS are promoted as tools for teamwork. However, user collaboration configurations can also jeopardize files and data. For its part, NIST promotes keeping an eye on each resource’s permissions.
Employees could be the target of socially-engineered phishing attacks if there is a visible calendar, and shared repositories might allow for the public disclosure of an organization’s internal source code. Sensitive information that should n’t be made public is contained in emails, files, and boards. Almost any app that stores content will have this kind of control, even though the following configurations are frequently referred to as something different in each application.
Stop Sharing in Public
Share with a User and Share With All are very different from one another. Anyone with a link can access the materials when items are shared with everyone. As the user must log in before accessing the material, sharing with a user adds an additional authentication mechanism.
App administrators should turn off sharing over public URLs (” Anyone with the link” ) in order to reduce the amount of content that is visible. Additionally, some applications let users revoke access to already-created URLs. Organizations should make sure to turn on that setting when it is available.
Set ExpirationsInvitations
Many applications let authorized users invite outsiders. The majority of applications, however, do not include an invite expiration date. In those situations, invitations sent years in advance may give a threat actor access to an email account that was recently breached by an outside user. That kind of risk is eliminated by allowing an auto-expiration date on invites.
It’s important to note that while some apps ‘ configuration changes go back in time, others wo n’t.
Download the complete guide to align your SaaS security with NIST standards.
Passwords that are strengthened to increase application security
The first line of defense against unauthorized access is a password. To protect sensitive user data, private business information, and proprietary assets kept within the cloud-based infrastructure, NIST advocates for a strong and well-managed password policy. A strong security posture depends on passwords ‘ uniqueness, complexity, and regular updating.
In a layered security approach, passwords are an essential component that complements other security measures like encryption and multi-factor authentication ( MFA ). Malicious actors may be able to access SaaS environment vulnerabilities through compromised passwords. A more secure and reliable digital ecosystem for businesses and their users is made possible by the efficient management of passwords, which also improves the overall resilience of SaaS systems.
Avoid Spray Attacks with Passwords
Threat actors enter a username and common password terms during spray attacks in an effort to gain access to the application. The suggested method to stop password spray attacks is to requireMFA. Many apps enable businesses to forbid using words as passwords for those who do n’t require employees to use MFA as part of the authentication process. Terms like password1, letmein, 12345, and the names of nearby sports teams would be included in this list of words. Terms like the user’s name, business products, partners, and other business terms would also be included.
The likelihood of a successful password spray attack can be significantly decreased by modifying the configurations and including an additional custom banned words list.
Complexity of the password
The majority of SaaS applications let businesses alter the complexity of passwords. These can include requiring a password length, alphanumeric characters, capital and lowercase letters, or symbols. Change the app’s password requirements to reflect the policies of your company.
Consider adhering to NIST recommendations if your company does n’t have a password policy:
- Avoid making mandatory password changes because users frequently opt for simple-to-remember passwords.
- Long passwords are preferable to complex ones. Password1! is a common format for combinations of numbers, special characters, and lower/upper case characters. These are simple to use forcefully. MyFavoriteDessertIsPecanPie is a lengthy password that is simple to remember but challenging to brute force because it has 27 characters.
- No more than 10 password attempts are allowed.
- Check published passwords and other simple-to-guess words with a list of forbidden words to see if they are valid.
Configurations are crucial.
A misconfigured setting is the root cause of about 25 % of all cloud-related security incidents. Key management, mobile security, operational resilience, phishing protection, SPAMprotection—among others—use configurations in addition to those mentioned here in relation to access, password, and data leaks, which are fairly common. Any of those areas ‘ configuration errors could result in breaches.
Threat actors may not spend their time searching for opportunities to take advantage of misconfiguration, which may seem unlikely. However, when Midnight Blizzard, a Russian state-sponsored organization, breached Microsoft this year, that is precisely what it did. It’s important to review your applications to ensure that they are all secure in case Microsoft makes mistakes.