How the New NIST 2.0 Guidelines Help Detect SaaS Threats

Article written by Hananel Livneh, Head of Product Marketing at Adaptive Shield.

The SaaS ecosystem has exploded in the six years since the National Institute of Standards and Technology’s (NIST) cybersecurity framework 1.1 was released. Back in 2016-2017, when version 1.1 was initially drafted, SaaS held a small but significant place in the software market. 

Today, the economic benefits coupled with pandemic-induced work-from-home culture have led to SaaS becoming the primary way businesses purchase and use software.

Not surprisingly, NIST’s just-released Cybersecurity Framework (CSF) 2.0 seems to have SaaS security in mind.

Throughout CSF 2.0, NIST recommendations dovetail with SaaS security needs. Govern, the new function, addresses issues relating to the democratization of SaaS, misconfiguration management, external users, risk management, and security posture.

SaaS security demands the combination of two types of monitoring. The first, which is best covered by a SaaS Security Posture Management (SSPM) platform, handles prevention. The second, which requires log monitoring and anomaly detection, detects threats.

The updated version of the framework pushes organizations to ensure that both prevention and detection are adequately covered.

Read about how to apply the NIST 2.0 guidelines to your SaaS stack

NIST and Recent SaaS Breaches

Recently, Proofpoint’s Cloud Security Response Team identified an ongoing cyberattack campaign targeting Microsoft Azure environments. The account takeover attacks have compromised hundreds of user accounts, including those of senior executives.

This access can enable threat actors to access confidential corporate information, approve fraudulent financial transactions to their own accounts, and access critical systems for future attacks.

In another recent SaaS breach, threat actors breached the HR software of an US telecom operator, exposing data of over 63,000 employees. One contributing factor to the breach may have been the complexity inherent in SaaS HR permissions structures.

HR systems use a complex mix of security groups, domains, organizations, and roles to grant permissions. Administrators rarely have a clear picture of individual users and their full permission set.

Had NIST’s standards been adhered to, breaches like these could have been avoided. The ongoing Microsoft Azure breach is based on phishing attacks that provide threat actors with access to an application. Leaving aside the recommendation of requiring MFA, which would have prevented access to threat actors, applying the principles of the detect function to the application would have alerted security teams to the threat.

Adverse Event Analysis, a NIST category, charges security teams with looking for anomalies, indicators of compromise, and other adverse events. It also recommends that information be correlated from multiple sources.

Effective SaaS threat detection would have scanned logs from across the entire SaaS stack. When threat actors log in to SaaS applications using their victim’s credentials, they share enough bits of information for an effective Identity Threat Detection & Response (ITDR) to detect anomalies.

For example, if they are using a different computer operating system, browser version, or location, the threat detection tool in place should pick up on the anomaly and regard it as an indication of compromise (IoC). If there are multiple IoCs, it should trigger an alert that leads to an account’s access being temporarily suspended. 

Figure 1: Two IOCs indicate a threat in the SaaS application

Applying NIST standards could have protected the telecom operator as well. The Protect function stresses limiting access to authorized users. As part of that function, organizations must have a clear understanding of the access granted to each employee.

When threat actors gained entry into the telecom company’s HR system, they may have had extended reach due to the poorly understood permissions in the account they breached.

NIST 2.0’s Alignment with SaaS Security

At nearly every critical juncture, SaaS security when conducted through an SSPM and ITDR are aligned. The new Govern function centers on monitoring. This includes oversight, communication, and understanding roles in cybersecurity.

These functions are all integral pieces of any modern-day SSPM. 

Figure 2: The Adaptive Shield platform provides a dashboard view of SaaS security posture

The Identify function, which focuses on understanding current cybersecurity risks to assets and users, is covered through robust asset and user inventories. Identify also includes  managing users from a centralized location, identifying all non-human accounts and their permissions, and monitoring the permissions of every resource.

The Protect function tasks organizations with developing configuration management practices, generating log data, and managing access.  In practice, this means authenticating users and services, controlling access through role-based access control following the principle of least privilege, and limiting access by external users.

Monitoring devices that access applications and detecting third-party integrating apps are essential to this function.

The Detect, Respond, and Recover functions find their place in threat detection. In addition to scanning logs for anomalies, it involves monitoring, taking actions when incidents are discovered, and restoring SaaS applications so they are up and running following an account compromise. 

Figure 3: SSPMs use security checks to identify misconfigured setting

Securing SaaS applications using an SSPM platform with ITDR capabilities is the most effective way to protect your SaaS stack. It also helps keep your SaaS security measures aligned with the latest NIST framework recommendations.

Download Adaptive Shield’s newest NIST-SaaS checklist

Sponsored and written by Adaptive Shield.