Author: Admin Suridata

MongoDB, a leading database management system, recently experienced a significant security incident. On December 16, 2023, MongoDB reported unauthorized access to their corporate systems, resulting in the exposure of customer account metadata and contact information. This breach occurred despite MongoDB’s robust security measures and highlights the ever-present risks in managing and securing data in any SaaS application.

---

What happened?

• Security Breach Timeline: MongoDB detected suspicious activity on December 13, 2023. The breach involved unauthorized access to MongoDB’s corporate systems, affecting customer account metadata and contact information.
• Customer Impact: While MongoDB’s primary database service, MongoDB Atlas, was not directly compromised, the incident raised concerns regarding the potential misuse of exposed customer data.
• Response Measures: MongoDB responded by activating its incident response process, advising customers to be vigilant against social engineering and phishing attacks. They also recommended the use of phishing-resistant multi-factor authentication (MFA) and regular password rotation.

---

Why is it this dangerous?

• Exposure of Sensitive Data: The unauthorized access led to the exposure of customer account metadata and contact information, which could be exploited for malicious purposes.
• Risk of Phishing and Social Engineering Attacks: With access to customer contact information, attackers might launch targeted phishing campaigns, leveraging the trust in MongoDB’s brand.
• Potential Long-Term Security Implications: The breach indicates that MongoDB’s systems were vulnerable for a certain period, suggesting a need for more proactive security measures.

---

How can Suridata come to the rescue?

• Enhanced Visibility and Monitoring: Suridata’s SSPM solution could provide continuous visibility into the MongoDB SaaS application, enabling earlier detection of unusual user activities across the application, along with detecting and viewing unauthorized access attempts.
• Configuration Management: Suridata’s solution could check that the Mongo SaaS application is configured in line with the latest security best practices, including MFA that will be enforced at the application level, and not only at the user level. The platform would alert system owners if configurations did not align with SaaS security best practices. Moreover, implementing a hygienic password environment in the MongoDB environment would reduce the risk of sensitive data being exploited.
• Comprehensive Security Posture Assessment: Suridata’s SSPM could offer a thorough assessment of SaaS applications and third parties’ security posture, identifying potential weaknesses and suspicious behaviors before they are exploited.

---

Summary

In December 2023, MongoDB suffered a serious security breach involving unauthorized access to its corporate systems. This breach exposed customer account metadata and contact information, posing risks of phishing and social engineering attacks. Suridata’s SSPM could have mitigated the risks of this attack by offering critical capabilities in terms of enhanced monitoring, threat detection, and proactive security measures—potentially preventing such incidents or mitigating their impact. As MongoDB continues to investigate and strengthen its security measures, integrating an SSPM solution like Suridata can be a strategic step toward enhancing overall security resilience and protecting sensitive customer data.

---

It’s December 2023, and unauthorized users are still accessing staging environments without being noticed.

Don’t believe me? Check out the report New Relic shared regarding the latest attack on their environment.

Wait, who is New Relic?

New Relic is a software company that provides observability solutions for cloud-based businesses. The company’s platform helps businesses collect, analyze, and visualize data from their applications, infrastructure, and user interactions. This data can be used to identify and resolve performance issues, improve user experience, and optimize resource usage.

---

What happened?

• The staging environment contained data about how customers use New Relic and certain logs, but not actual telemetry or application data.
• Two weeks prior to their December 1st update, an unauthorized actor gained access to New Relic’s staging environment through stolen credentials and social engineering.
• A small number of customer accounts were accessed with similar indicators of compromise (IOCs), potentially indicating stolen credentials from a separate attack.
• New Relic immediately responded by rotating passwords and removing user API keys for the affected accounts.

---

Why is it dangerous?

• Potential access to customer accounts: The attacker used stolen credentials to access several customer accounts. It’s a concerning matter, as it indicates that the attacker may have obtained access to other customer accounts through other means.
• Unauthorized access to staging environment: The attacker gained access to New Relic’s staging environment, which contains data about how customers use New Relic and certain logs. This data could be used to gain insights into customer usage patterns and identify potential vulnerabilities.
• Potential for data exfiltration: The attacker may have tried to exfiltrate data from the staging environment or customer accounts.

---

How would an SSPM like Suridata potentially prevent such an incident?

New Relic integrates with numerous SaaS applications, acting as a third-party provider. This creates a complex and potentially vulnerable ecosystem.

Suridata could have helped prevent or mitigate the New Relic security incident in several ways:

Visibility and monitoring:

Suridata’s solution provides continuous and comprehensive visibility into the third-party applications that are connected to the core corporate applications. This could have helped New Relic’s customers detect unauthorized access much sooner and take action to prevent or control the incident.

Automated threat detection and response:

• Suridata’s solution utilizes advanced machine learning and analytics to detect suspicious activity and potential security threats. These capabilities could have helped New Relic’s customers identify if a malicious user or third-party app was accessing their data and take steps to mitigate the damage.
• Suridata’s automated response capabilities can help to contain the attack quickly and revoke access to the new relic plugin or application.

Improved Configuration Management:

Suridata’s solution can help ensure that all SaaS resources are properly configured and comply with security best practices. This could have helped to prevent the attacker from exploiting vulnerabilities in New Relic’s configuration.

---

Summary

In December 2023, New Relic, a software company offering observability solutions, experienced unauthorized access to its staging environment due to stolen credentials and social engineering. This exposed data about customer usage patterns and certain logs, prompting immediate action from New Relic, including password rotations and API key removal. While this incident highlights the persistent danger of unauthorized access, solutions like Suridata’s SSPM offer enhanced visibility, monitoring, automated threat detection and response, improved configuration management, and security posture insights which could have potentially prevented or mitigated this attack.

---

---

First, Some Definitions

Security posture, in general, is about how well an organization is prepared to defend itself against cyber threats. Typically, posture amounts to being able to detect threats and respond to them effectively—and quickly. In specific terms, security posture deals with guarding networks and protecting an organization against malware, ransomware, denial of service (DoS) attacks, data breaches and other serious threats.

CSPM applies the principles of security posture to instances of cloud computing. It involves automating the detection and remediation of risks across infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS).

SSPM realizes security posture goals with software-as-a-service (SaaS) applications. It combines tools, people, processes, and policies with the goal of reducing cyber risk exposure for SaaS apps. For example, an SSPM solution might monitor and remediate insecure SaaS configurations or third-party integration plugins.

Why CSPM and SSPM Are Important

CSPM is essential because traditional security processes and countermeasures don’t work very well in the cloud. The cloud is exposed to risks that do not affect on-premises infrastructure. For one thing, there’s no perimeter. The very flexibility and ease of access that makes the cloud so useful, in business terms, makes it vulnerable to threats that you don’t run into in traditional IT environments. Nor is there the kind of centralized management that’s common with on-premises infrastructure. Manual processes don’t scale well in the heterogeneous landscape of the cloud, either. After all, in addition to encompassing IaaS, SaaS, PaaS, and other “as-a-service” technologies, a cloud environment can also be public, private, or hybrid.

Like CSPM, SSPM is an important element of an overall security program because it addresses SaaS apps’ unique risks. A SaaS app can be accessed, in theory, by anyone, from anywhere, on multiple device types. This is great for operational agility but terrible for security. Countermeasures, such as multi-factor authentication (MFA) are critical for protecting SaaS apps and the sensitive data they contain, if they are turned on, which they often aren’t. The problem is partly one of scale. The average organization uses over a hundred SaaS apps, each of which has its own unique custom security settings that can be modified by individual users. The security team cannot keep up without SSPM tooling. 

How CSPM and SSPM Differ

CSPM and SSPM both address themselves to the parts of the IT estate that live in the cloud, which are outside the standard zone of security policies and operations. They overlap, to some extent, with CSPM potentially monitoring access to SaaS apps, for example.

Similarities and overlap aside, CSPM and SSPM are different, but also complementary. CSPM is concerned with cloud infrastructure, while SSPM deals with applications.  It’s the micro to CSPM’s macro, if we go with the cartoon’s theme. CSPM is broader in scope than SSPM. For instance, CSPM might include the integration between software development and cloud operations, while SSPM does not.

SSPM, conversely, deals with a level of detail in SaaS security that CSPM does not touch. An SSPM solution, such as Suridata’s SSPM platform, monitors the configurations of all SaaS apps. It flags, and can automatically remediate, insecure configurations. SSPM inventories third-party plugins and alerts security managers to integrations that may expose the organization to risk.

An SSPM solution identifies all of the places in the SaaS ecosystem where corporate data is stored, and identifies any security risks that arise from such data storage. An SSPM platform monitors SaaS user sessions and flags suspicious activity, such as excessive file downloading, which can signal a ransomware attack in progress. An SSPM platform prioritizes SaaS security alerts and recommends remediation of the most urgent issues first.

---

Conclusion: You Probably Need Both CSPM and SSPM

If you have cloud assets and SaaS, which would make you like most organizations, you probably need both CSPM and SSPM. On their own, they each provide part—but not all—of the cloud security you need. CSPM protects your cloud infrastructure, with possibly some defense of SaaS. To get thorough SaaS security, however, you need SSPM in addition to CSPM. You have to talk micro as well as macro.

---

Last month, a new SaaS ransomware had been seen “in the wild” for the first time. The attack, which affected Microsoft SharePoint software, did not come from a compromised endpoint. This fact has alarmed SaaS security experts. Nor is it good news for security managers. However, there are ways to defend against such threats.  

---

The Attack  

Until now, ransomware attacks on SaaS applications have followed a pattern wherein the attacker first compromises an endpoint such as a laptop or server. After encrypting the data on the endpoint, the encrypted data synchronizes across all the storage/backup services, rendering it unusable, and the attacker demands a ransom for it to be decrypted. However, that is not what happened in this case. 

In this attack, a hacker compromised a Microsoft global admin service account’s credentials. The attacker was able to compromise the credentials because the service account did not have MFA/2FA enabled. Therefore, the account could be accessed over the public internet simply with a password. Specifically, the attacker accessed the service account from a virtual private server (VPS) host. Even though the VPS had an anomalous IP-geolocation, vis a vis “normal” access patterns, the attacker was still able to access the account. 

From there, the attacker set up a new Active Directory (AD) user called “Omega” using the compromised service account. The attacker then used the compromised service account to grant, and then elevate, the Omega account’s permissions—to roles that included Global Administrator, SharePoint Administrator, Exchange Administrator, and Teams Administrator. (Wow!) The compromised service account also granted Omega site collection administrator capabilities for multiple SharePoint sites and collections.  

The attacker proceeded to remove the other 200 admins from the system within two hours. The stage was set for a massive data breach, and at that point, the attacker was able to exfiltrate files. 

Implications for SaaS security 

The SharePoint ransomware attack “in the wild” presents a new twist on an old(ish) attack. What stands out is the fact that the attack did not involve compromising an endpoint like a server. With hackers no longer needing to gain access to an endpoint, they can focus instead on SaaS services. In this case, they used an admin account to lock out other users and breach the target’s data. They could have also encrypted the data and demanded a ransom to decrypt it. While most SaaS vendors are able to help victims restore their access and possibly recover lost data, the process tends to take a long time to complete, and it will not necessarily be able to restore all the affected data. 

The attack makes it clear that SaaS applications are now targets for ransomware attacks. It also shows the importance of defining and enforcing clear and effective policies regarding administrative accounts. The SharePoint attack would not have worked if MFA/2FA, along with better geo anomaly detection and response, had been operational. 

Mitigating This New Type of SaaS Risk 

This attack is a sign of what the future holds. It may have been the first known SaaS ransomware “in the wild,” but it will not be the last. The method of the attack underscores the importance of setting up, maintaining, and monitoring SaaS security controls. Though this idea is simple enough, its execution can be quite challenging. 

For most organizations, which on average employ more than 100 SaaS apps, each with their own unique configurations and settings, the task of defending against ransomware in the wild is going to be a daunting prospect. There are simply too many opportunities for security measures to fall apart. Individual users may be able to change their security settings without anyone knowing. Admin accounts may not be configured securely, e.g., without MFA/2FA. Third-party plugins might grant access to unauthorized users, and so forth. 

A SaaS security posture management (SSPM) platform, such as Suridata, offers a way to mitigate these new risks. Suridata comprises a single, unified solution for SSPM. With this SSPM platform, it becomes possible to achieve secure configurations of all SaaS apps in an organization—and then monitor those configurations for changes that reflect a change in security posture. The SSPM platform can also tightly control access by users and plugins, while monitoring for abnormal behavior. As it works, it is able to prioritize the security problems it detects, and in some cases, automatically remediate them. 

Conclusion

A new era is dawning in SaaS security. Ransomware attacks are lurking in the wild. It’s time to be prepared to defend against them. An SSPM platform is arguably the best technology available to mitigate threats that exploit weaknesses in access control, configuration, and anomaly detection.  

To learn about the Suridata SSPM platform, contact us now. 

---

A brief overview of SaaS security

SaaS applications have a distinctive risk profile. They’re comparable to but different from other kinds of digital assets. A SaaS app typically contains sensitive or valuable corporate data, but it can be accessed from virtually anywhere on any kind of device. Controls over user access are therefore critical to maintain strong security. Third-party plugins represent a potential threat vector, as well. In addition, each SaaS app—and the average company now uses dozens if not hundreds of them—has its own security settings and unique configuration. The volume and variety of SaaS apps, and their respective configurations create a broad attack surface.

What is an idP?

An idP stores users’ digital identities and enables their management. Sometimes implemented as a commercial solution, sometimes built using open-source components, an idP typically checks user identities using a combination of username/password pairs and other factors, such as a PIN code or device characteristic. An idP may be part of a single sign-on (SSO) solution. It may also be a component of a broader identity and access management (IAM) solution. idPs often work together with multi-factor authentication (MFA) solutions, as well.

idPs verify user identities, a foundational cybersecurity control. Knowing who is who, and confidently authenticating their identities, are essential steps to the effective realization of many other controls. For example, it is impossible to enforce access privileges without being certain of a user’s actual identity. idPs perform this task.

For an idP, a “user” does not necessarily have to be a human being. It could be a device or another software application. The OAuth token, for example, a common ingredient in idPs, authenticates machine users in app-to-app interactions. This capability is relevant to SaaS security because a SaaS app may treat a third-party plugin running in another app as a user.

What is SSPM?

Posture, the “P” in SSPM, refers to the quality of an organization’s preparation to defend its digital assets from cyber threats. This usually means being able to detect threats and respond to them thoroughly and efficiently. Going further, security posture relates to how well an organization is guarding its networks and protecting itself against malware, ransomware, denial of service (DoS) attacks, data breaches and so on.

SSPM brings security posture principles to SaaS. SSPM combines tools, people, processes, and policies to reduce SaaS apps’ inherent cyber risks. For instance, SSPM is aimed at preventing a breach of data stored inside a SaaS app. To accomplish this goal, SSPM tools monitor and remediate insecure SaaS configurations. They detect threats to SaaS apps, while also monitoring third-party integrations and bolstering regulatory compliance, where relevant.

Tracking security issues related to SaaS app users is part of SSPM. For this reason, SSPM solutions generally integrate with IAM solutions. They can monitor user access attempts and behavior to detect activity that might indicate the presence of a threat.

Do you need both an idP and an SSPM solution?

To some extent, the identity functionality of an SSPM solution overlaps with that of an idP. However, the SSPM solution does not have the depth of identity management and security features present in the idP. For example, an SSPM tool cannot enable SSO.

Does this mean you need both an idP and an SSPM solution? You probably do, especially if you want to enforce strict identity authentication policies as part of your SaaS security. An idP on its own does offer some powerful identity management and security capabilities, assuming it’s correctly implemented and managed. However, the idea that “you’re good” for SaaS security if you have an idP, but not an SSPM, is worth rethinking.

An idP cannot analyze SaaS configurations and security settings. It cannot examine third-party plugins, except perhaps to the extent that the plugin is treated as a user. It cannot remediate vulnerabilities. These are what an SSPM solution does. For optimal SaaS security posture, you probably need both.

---

Conclusion

Keeping control over user identities is essential for SaaS security. That said, an idP is not enough to deliver robust SaaS security posture on its own. An SSPM solution complements the idP, adding automated monitoring, analysis, and remediation of security weaknesses in SaaS configurations, settings, and third-party integrations. Together, idP and SSPM can provide the high level of SaaS security posture that most organizations need to stay secure in today’s threatening cyber environment.

---

---

What is SASE?

The “E” in SASE is the key to understanding what it’s all about. E is for edge. SASE enables endpoints, such as mobile devices or Internet of Things (IoT) sensors to connect securely to applications and data at the edge. The user does not have to connect through a data center, which adds latency and creates network congestion.

SASE is not a product, at least not at this point. As defined by the Gartner analyst firm, SASE is an architecture that combines a software-defined wide area network (SD-WAN), zero trust network architecture (ZTNA), secure web gateway (SWG), cloud access security broker (CASB), firewall as a service (FWaaS) and centralized management. That’s a lot of technology to implement, integrate, and manage. Even if the components are all from the same vendor, it’s still a big job.

SASE, or something just like it, has become a necessity, however. Enterprises need it to support modern work scenarios—where users are accessing cloud and on-premises assets from pretty much anywhere. Allowing users to connect at the edge, via a cloud-based service, is an effective solution.

What is SSPM?

SSPM concerns itself with the collective security posture of an organization’s software-as-a-service (SaaS) ecosystem. This can be a sprawling, complicated environment, with the average organization using 130 SaaS apps as of 2022, up from 110 in 2021. To protect those SaaS apps, and the data they contain, SSPM combines tools, people, processes, and policies to reduce SaaS apps’ inherent cyber risks.

For example, SSPM might monitor SaaS apps for insecure configurations—and remediate configuration problems when they are discovered. Other SSPM tasks include monitoring user sessions for anomalies, examining data access rules to prevent data breaches, tracking third party integrations between SaaS apps, and so forth.

SSPM is a unique, coherent solution, in contrast to SASE, which is basically an architectural pattern. It is comparatively easy to implement. (Realistically, at this point, almost anything is easier to implement than SASE, which requires installing six different products and making them work together…)

Where SSPM and SASE overlap?

SSPM and SASE overlap with a common goal of protecting SaaS apps from malicious users. SASE does provide a number of defenses for SaaS. With SASE, for example, the CASB serves as a policy enforcement point that sits between users and cloud service providers, including SaaS apps. It can handle tasks like authentication, encryption, and threat detection. ZTNA helps ensure that only authorized, verified users, can access SaaS apps. The SWG component of SASE also offers some protections for SaaS apps. For example, an SWG can execute data loss prevention (DLP), by detecting and blocking unusual data transfers out of SaaS apps.

Do you need SSPM if you’re implementing SASE?

On the surface, it seems like SASE mitigates SaaS risk for the enterprise. Going a little deeper, however, a number of significant gaps emerge. Unlike SSPM, SASE does not inspect SaaS configurations, for instance. Its components do not monitor SaaS security settings and flag insecure situations. SASE does not track the use of third-party plugins that integrate one SaaS app with another. Nor does SASE monitor SaaS user sessions with the goal of detecting anomalous behavior.

Without SSPM, SASE leaves SaaS apps exposed to risks related to configuration and third-party integration, among others. And, SSPM solutions, such as Suridata, offer risk prioritization and automated remediation. SASE is a connection paradigm. It’s not a cybersecurity toolset. It does not have built-in SaaS risk remediation capabilities.   

Now, it may not be entirely fair to say that SASE can’t perform these tasks. Some SASE components are highly customizable and come with advanced developer kits. It’s probably possible to program a SASE solution to perform most SSPM processes. That would be a huge, unnecessary investment of time, however.

Making SSPM part of SASE

There is a way to resolve SASE’s gaps in SaaS security: make SSPM part of a SASE architecture. SASE already involves acquiring and integrating six or more technologies. Adding SSPM to the mix is not a huge extra step. One reason is that SSPM could operate independently from SASE, though an SSPM platform could feed data into a centralized SASE management tool, as well as related security operations (SecOps) solutions.

---

Conclusion

SASE and SSPM cover different aspects of SaaS security. SASE protects SaaS apps from unauthorized access and enforces security policies related to data loss, and so forth. Any organization that has people and IoT devices operating remotely is going to need some sort of SASE solution. SASE does not provide complete SaaS security, however. It doesn’t track SaaS configurations and third-party integrations. Nor does it manage SaaS risk remediations. For optimal SaaS defense, the two technologies should ideally be deployed together.

---

Who is responsible for securing digital assets in the public cloud, the customer, or the cloud service provider (CSP)? Most of the time, it’s both. CSPs require their customers to agree to what’s known as a Shared Security Model, sometimes called the Shared Responsibility Model. In this approach to cloud cybersecurity, the CSP is responsible for securing their own infrastructure, but the customer is on the hook for almost everything under its control, such as application security and identity management. The Shared Security Model makes a great deal of sense, especially when the division of control is clear, such as in the case of Infrastructure-as-a-Service (IaaS). With Software-as-a-Service (SaaS), things get a little more complicated. This article looks at how SaaS security works under the Shared Security Model.

What is the Shared Security Model?

The Shared Security Model is embedded in the “fine print” of the contract the customer signs with a CSP. In fact, the word “model” is not quite right. It should really be called the shared security responsibility agreement. When you sign up with a CSP, you’re assigning yourself several critical security duties, with disputes potentially ending up in court. So, pay close attention here…

Briefly, the Shared Security Model holds that the CSP is obligated to protect its data centers, internal networks, and the hardware that supports its cloud platform. This means securing internal software development workflows and complying with security standards. It also involves monitoring infrastructure for threats, mitigating those threats, and responding to security incidents.
The SaaS provider is responsible for protecting its way of using of the applications and data it hosts on the CSP’s infrastructure.

It’s a good practice to develop a sophisticated, detailed understanding of just what is, and isn’t covered by the CSP’s side of the model. Think of the cloud platform stack. With IaaS, the CSP secures all infrastructure components on its side, including servers, network switches, and so forth. The customer may be on the hook for the operating system (OS), database server, application software and identity and access management (IAM). With Platform-as-a-Service (PaaS), the CSP usually secures the platform software, such as Linux, because that’s part of the service they’re providing. Always check, however. It is not wise to make assumptions about the CSP’s specific areas of responsibility.

The Shared Security Model comprises a logical set of rules sense for both the CSP and the customer. The CSP has little to no control over the way its customers deploy and configure their systems. Nor can the CSP control the customer’s endpoints. If the customer does not regularly patch its OS, for example, that is a deficiency the customer has to address.

SaaS and the Shared Security Model

The Shared Security Model for SaaS is different from those utilized for IaaS and PaaS, for several reasons. With SaaS, the vendor is the application provider and the cloud provider. In some cases, the SaaS vendor runs the SaaS application on a CSP like Microsoft Azure. In that scenario, the CSP is obligated to the SaaS vendor under the Shared Security Model, but the SaaS customer still has its share of security responsibilities.

The SaaS vendor is responsible for application security. This includes protecting the data stored by the SaaS app. However, the customer is responsible for data security, as well. This may sound confusing but remember that a threat to SaaS data can come from an attack on the cloud infrastructure or through the SaaS interface or application programming interface (API). In the latter attack surface, the customer is responsible.

With SaaS, the customer is also responsible for its endpoint security and user security. It is up to the customer to protect itself by preventing unauthorized access to the SaaS application. In practice, this means the customer takes care of IAM, user security and credentials, configuration, APIs and middleware.

How to Manage SaaS Security in the Context of the Shared Security Model

Managing SaaS security under the Shared Security Model requires attention to detail. It’s essential to do a careful review of the terms of the agreement and any Service Level Agreements (SLAs) it contains. The customer is protected by the legal agreement, but it’s wise to keep in mind a basic fact of life in IT: If you end up in a lawsuit, even a lawsuit you win, you are not succeeding. The best approach is to understand your responsibilities and translate the most urgent of them into clear assignments for all relevant teams and stakeholders.

Data security should be a priority, for instance. Know what data you have in your SaaS application, how it’s protected, and who has access to it. This means implementing IAM that defines and enforces cloud access policies. Privileged Access Management (PAM) needs to be part of this thought process, too.

It’s also smart to know where your SaaS application is integrating with other SaaS applications, as well as with other parts of your IT estate. The SaaS attack surface can be quite a lot larger than you realize, once you start factoring in all the ways a malicious actor can access a SaaS application beyond its front-end user interface.

A security partner can help, too, as can solutions for SaaS security posture management. Keeping track of number of SaaS configurations can be overwhelming, especially with the added burden of figuring out what is your responsibility and what is covered by the SaaS vendor. Technologies that automate SaaS security posture management can be quite helpful in minimizing risk to SaaS applications.

Conclusion

---

How CASBs work and why enterprises use them

The CASB has been around for a decade. It came into existence to help security managers deal with risk exposure from SaaS that did not exist when apps and data were only on-premises. Traditional firewalls can do little to protect SaaS apps and data. Indeed, with SaaS and Bring Your Own Device (BYOD) policies, users could be almost anywhere on the public Internet, on any device. This environment increased the likelihood of unauthorized access and data breaches.

CASB mitigates these risks by functioning as a point of visibility and control. As its name suggests, it brokers SaaS access requests and resulting user sessions—enforcing security policies in the process. A CASB typically works through a cloud proxy architecture. It intercepts requests for SaaS access, regardless of where they originate, blocking the ones that don’t match the rules and routing the rest to the right place. In the meantime, the CASB monitors traffic and access requests, checking for malware and suspicious behavior, among other factors. It sends alerts to system admins if it detects threats or policy violations.

---

The limits of CASBs in the bigger picture of SaaS security posture

CASBs contribute significant risk mitigation to SaaS security. However, they cannot help in every area of risk. When a CASB is part of a Secure Access Service Edge (SASE)architecture, it combines with Zero Trust Network Access (ZTNA),Firewall-as-a-Service (FWaaS), Security Web Gateway (SWG) and aSoftware-Defined Wide Area Network (SD-WAN) to enable even better cloud security. Yet, even with SASE, certain aspects of SaaS security posture remain neglected. 

Weaknesses in SaaS security posture that continue, despite CASB or SASE, include SaaS configuration problems, deficient access management controls, and third-party risks. Configuration errors, for example, are internal in nature. A CASB cannot help when SaaS file shares are open to public access by default, to name one common configuration scenario. Regarding access management controls, CASB will do its job even if a SaaS customer allows overly simple passwords or password sharing.Third-party risks, such as those created when one SaaS app can access another, bypass CASB’s policy enforcement point. 

Compliance is another area of SaaS security posture that is not addressed by CASB. A SaaS customer might have to abide by regulations covering data sovereignty or consumer privacy. CASB does not have an impact on such compliance requirements.

Poor accountmanagement is also a problem that cannot be alleviated by CASB. If a SaaScustomer does not stay on top of user accounts, closing them when an employeeleaves the company, for instance, CASB will still let them through.

---

How SSPM solutions complement CASBs for SaaS security

An SSPM solution addresses the gaps in SaaS security posture left by a CASB operating on its own, or as part of a SASE architecture. These solutions work in various different ways, but in general, they thoroughly and regularly scan SaaS instances with the goal of identifying and prioritizing SaaS security problems. Using automated processes, augmented by Artificial Intelligence (AI), they can spot misconfigurations, questionable third-party integrations, and external sharing that may violate security policies. 

Some SSPM solutions, such as Suridata, enable system owners to monitor SaaS security posture across multiple SaaS applications. This is an increasingly important need, given that the average mid-sized enterprise runs more than 185 SaaS apps. Keeping track of configurations and third-party integrations in such a broad, complex environment is nearly impossible using manual processes. The solution may also provide unified management and monitoring capabilities, which simplifies SaaS security operations. 

An SSPM solution can also monitor SaaS user behavior to detect suspicious events that might reveal a cyber-attack in progress or the presence of a malicious user. Here, the SSPM solution starts to overlap with the CASB. As the solution detects problems, it may be able to orchestrate their remediation. This process could be automated and continuous enabling the ongoing strengthening of SaaS security posture. 

As products evolve, some CASBs are starting to offer functionality that incorporates that of SSPM solutions. Alternatively, the two solutions can be integrated. Connecting a CASB with an SSPM solution helps the CASB do its job better. The SSPM solution can ingest data and alerts from the CASB into its SaaS security monitoring, and respond accordingly, for example.

---

Conclusion

CASBs do a lot for SaaS security, but they cannot address all the elements of SaaS security posture on their own. Certain areas of risk, such as SaaS configuration, remain open. An SSPM solution can fill in the missing pieces, monitoring configurations, third-party integrations and more. Together, a CASB and an SSPM can deliver a fuller, more robust SaaS security posture.

---