SaaS Compliance via the NIST Cybersecurity Framework

Cybersecurity Framework

The U.S. 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 faced by those charged with securing SaaS applications is the different settings that exist in each application. It makes it difficult to develop a configuration policy that applies 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 the NIST Compliance Standards.

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 guide you through setting them up in a way that improves the security posture of your SaaS apps.

Start with administrators

Role-based access control (RBAC) is a key to NIST compliance and should be applied to every SaaS app. There are two types of permissions within a SaaS application. Functional access includes 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 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, hacking into an administrator account is like winning the lottery. They have access to everything. Organizations must do everything they can 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, because administrators can monitor each other for signs of a breach.

However, each administrator increases the attack surface of the application. Organizations must find a balance between having enough administrators to adequately operate the application and limiting exposure. An automated assessment of the number of administrators should trigger alerts when the number of administrators falls outside the desired range.

Eliminate external administrators

Third-party administrators introduce a new layer of uncertainty in SaaS security. Because they sit outside the organization, the security team has no control over the password policies or authentication tools they use.

For example, if a threat actor tries to log into your application and clicks Forgot Password, there is no way to know whether the threat actor can compromise the remote administrator’s email account. That lack of oversight of external users could lead to a deep breach of your SaaS application. Therefore, NIST does not recommend using third-party administrators. Depending on the application, you can prevent external administrators from gaining administrative privileges, or identify external users with administrative privileges and remove those privileges.

For companies that hire an external IT firm or outsource to MSSPs, these individuals should not be considered external. However, they should continue to check whether other external users are granted administrative rights.

Requires admin MFA

To comply with NIST standards, all administrative user accounts must access the application using multi-factor authentication (MFA), such as a one-time password (OTP). 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 of the compromise and reducing the risk to the account. Make sure you set up MFA for administrators as desired (we also recommend MFA for all users, but it’s a must-have for administrators).

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

Prevent data leaks

SaaS data breaches pose significant risks to organizations and their users, potentially compromising sensitive information stored in cloud-based applications. SaaS applications are marketed as collaboration tools. However, the configurations that allow users to collaborate can also put files and data at risk. NIST, in turn, advocates monitoring the permissions of each source.

A visible calendar can expose employees to socially designed 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. Although the following configurations are often called something different in each application, virtually every app that stores content has this type of control.

Stop sharing publicly

The difference between Share with everyone and Share with a user is big. When items are shared with everyone, anyone with a link can access the materials. Sharing with a user, on the other hand, adds an additional authentication mechanism because the user must log in before accessing the material.

To reduce the content shown, app administrators should disable sharing via public URLs (“Anyone with the link”). In addition, some applications allow users to revoke access to URLs that have already been created. If available, organizations should enable this setting.

Set invitations to Expired

Many applications allow authorized users to invite external users to the application. However, most applications do not implement an expiration date for invitations. In those circumstances, invitations sent years ago could provide access to a threat actor who just compromised a remote user’s email account. Enabling an automatic expiration date on invitations eliminates that type of risk.

It’s worth noting that in some apps, configuration changes are retroactive, while others won’t take effect until the future.

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

Strengthen passwords to improve application security

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

Passwords serve as a fundamental element in a layered security approach and complement 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 increases the overall resilience of SaaS systems and contributes to a more secure and reliable digital ecosystem for both companies 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 on employees using MFA as part of the authentication process, many apps allow organizations to prohibit words from being used as passwords. This list of words includes terms such as password1, letmein, 12345, and the names of local sports teams. Additionally, it would include terms such as the user’s name, company products, partners, and other business terms.

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

Password complexity

Most SaaS applications allow the organization to adjust the complexity of passwords. These range from allowing any password to requiring alphanumeric characters, upper and lower case 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:

  1. Don’t make mandatory password changes, as users often choose easy-to-remember passwords.
  2. Use long passwords instead of complex passwords. Combinations of numbers, special characters and lower/uppercase letters usually follow the following format: Password1!. These are easy to brute force. A long password like MyFavoriteDessertIsPecanPie is easy to remember, but difficult to brute force at 27 characters.
  3. Limit password attempts to no more than 10.
  4. Shield passwords from published passwords and other easy-to-guess words with a list of banned words.

Configurations are really important

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

It may seem unlikely that threat actors spend their time looking for misconfigurations to exploit. Yet that’s exactly what Russian state-sponsored group Midnight Blizzard did when it breached Microsoft this year. If misconfigurations can occur at Microsoft, it’s worth checking that your applications are all safe.

See how you can apply NIST standards to your SaaS stack

The hacker news



#SaaS #Compliance #NIST #Cybersecurity #Framework

Total
0
Shares
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
Previous Post
ConnectWise ScreenConnect Software

Critical flaws found in ConnectWise ScreenConnect software

Next Post
Learn How to Build an Incident Response Playbook

Learn how to build an incident response playbook against dispersed spiders in real time

Related Posts