MongoDB: Unauthorized Access and Data Exposure

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.


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.

Shiran Rachman

Product Lead

Back to list

New Relic Staging Environment Attack

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.


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.

Shiran Rachman

Product Lead

Back to list

Suridata Named Winner of the Coveted Top InfoSec Innovator Awards for 2023

Suridata Named Most Innovative in SaaS Security IN 11th Cyber Defense Magazine’s Annual InfoSec Awards during CyberDefenseCon 2023  

New York, New York – October 26, 2023 – Suridata is proud to announce we have been named the winner for the Most Innovative in SaaS Security award from Cyber Defense Magazine (CDM), the industry’s leading electronic information security magazine.

“We are immensely proud to be recognized by Cyber Defense Magazine as the winner of the Most Innovative in SaaS Security award. This accolade reaffirms our commitment to pushing the boundaries of security technology and providing our clients with the most advanced solutions. Suridata’s relentless dedication to innovation and excellence continues to drive us forward, ensuring that we remain at the forefront of safeguarding the digital landscape.” said Lee Kappon, co-founder and CEO of Suridata.

“We scoured the globe looking for cybersecurity innovators that could make a huge difference and potentially help turn the tide against the exponential growth in cyber-crime.  Suridata is worthy of being named a winner in these coveted awards and consideration for deployment in your environment,” said Yan Ross, Editor of Cyber Defense Magazine.

The full list of the Top InfoSec Innovators for 2023 is found here.

About Suridata

Suridata’s SaaS Security platform enables organizations to secure the use of SaaS applications. Companies rely on Suridata’s solution to identify risks of misconfigurations, third-party integrations, and users’ access. Once risks have been identified, the platform provides a remediation process according to best practices and security frameworks. The comprehensive point of view of Suridata’s solution ensures risk reduction across dozens of critical SaaS applications. For more information visit

About Cyber Defense Awards

This is Cyber Defense Magazine’s 11th year of honoring cybersecurity innovators, in this case the Top Global CISOs for 2023, on our Cyber Defense Awards platform. In this competition, judges for these and other prestigious awards includes cybersecurity industry veterans, trailblazers and market makers Gary Miliefsky of CDMG, Dr. Lindsey Polley de Lopez of VentureScope, Robert R. Ackerman Jr. of Allegis Cyber, Dino Boukouris of MomentumCyber and with much appreciation to emeritus judges Robert Herjavec of Cyderes, Dr. Peter Stephenson of CDMG and David DeWalt of NightDragon.  Top InfoSec Innovators for 2023 is found here and download The Black Unicorn Report for 2023 here, and Top Global CISOs Winners for 2023, here.

About Cyber Defense Magazine

Cyber Defense Magazine was founded in 2012 by Gary S. Miliefsky, globally recognized cyber security thought leader, inventor and entrepreneur and continues to be the premier source of IT Security information. We are managed and published by and for ethical, honest, passionate information security professionals. Our mission is to share cutting-edge knowledge, real-world stories and awards on the best ideas, products and services in the information technology industry. We deliver electronic magazines every month online for free, and limited special editions exclusively for the RSA, BlackHat and Cyber Defense Conferences. Learn more about us at Cyber Defense Magazine is a proud member of the Cyber Defense Media Group.

Suridata Media Inquiries:

Contact:                 Levona Simha, VP Marketing


CDM Media Inquiries:

Contact:                 Irene Noser, Marketing Executive


Levona Luna Simha

VP Marketing

Back to list

The Difference Between CSPM and SSPM

Years ago, a marvelous cartoon in The New Yorker featured one bearded college professor yelling at another, “Wait, all this time, I was talking macro and you were talking micro?” This is how conversations unfold when people talk about cloud security posture management (CSPM) versus software-as-a-service (SaaS) security posture management (SSPM). The two are similar and overlap to a certain extent. Yet, SSPM is quite different from CSPM. This article will explore those differences.

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.

Lee Kappon

Co-Founder & CEO

Back to list

SaaS Ransomware: Getting Ready for a New Generation of Threats 

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. 


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. 

Lee Kappon

Co-Founder & CEO

Back to list

SSPM vs. idP

Security managers typically conduct regular reviews of their solutions and assess whether they need to maintain, enhance, or replace what they currently use. As Software-as-a-Service (SaaS) applications become more prevalent and critical, concerns about SaaS security have grown increasingly urgent. In response, enterprises are considering the adoption of SaaS Security Posture Management (SSPM) tools to mitigate SaaS risk.
In some cases, however, the security team will reject the idea of SSPM because they are already using an identity provider, or idP. Their perspective seems to be, “We don’t need SSPM. We’re good. We have idP.” While understandable, this view is not correct. SSPM and idP are not the same. And, idP alone cannot provide the depth of SaaS security that today’s enterprises need.

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.


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.

Haviv Ohayon

Co-Founder & COO

Back to list


SaaS security posture management (SSPM) and the secure access service edge (SASE) don’t have a lot in common, but they do overlap. Hype about SASE has led to many organizations “doing SASE,” which can mean a lot of different things. There can be confusion about why an organization might need SSPM if it’s implementing SASE. As a result, it’s worth taking a moment to understand what each technology is about, how they are similar, and where they differ.

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.


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.

Haviv Ohayon

Co-Founder & COO

Back to list

SaaS and the Shared Security Model

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.


Haviv Ohayon

Co-Founder & COO

Back to list

SSPM vs. CASB: What Do You Need for SaaS Security?

If you have a Cloud Access Security Broker (CASB), do you also need a solution for SaaS Security Posture Management (SSPM)? Yes, you do, and this blog will explain why. CASBs have an important role to play in protecting Software-as-a-Service (SaaS) applications and their data. However, the CASB is only one element of strong SaaS security posture. A variety of other risks remain present, even with CASB’s protections. They include configuration errors, malicious code, deficiently secured third-party integrations, and more. An SSPM solution, which can integrate with a CASB, offers more complete SaaS security.

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.


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.

Lee Kappon

Co-Founder & CEO

Back to list

GitHub’s New Security Feature Made Available to Everyone

GitHub, the popular Internet hosting service for software development and version control, recently announced the availability of a new service that scans for secrets in developers’ code. It offers “push protection” that blocks the accidental publication of secrets that can cause security vulnerabilities. This is a significant advance in application security.

What Is a Secret?

For GitHub users, the word “secret” has a meaning that’s distinct from the general understanding of the word. In the context of GitHub and software development, a secret is any kind of private information, such as a token, password, or private authentication used by a service provider to enable interactions between applications. The development of software frequently involves the use of secrets and the embedding of those secrets in code.

With secrets, however, comes the risk that a secret has been compromised. A developer might commit a secret to a piece of code without noticing, and by doing so, reveal it publicly — rendering the secret to be insecure. In other words, the secret is not a secret anymore. Its ability to provide unique, private connections is no longer assured. A malicious actor can use the secret as a stolen credential to mount an attack.

GitHub’s New Secret Scanning Push Protection

To mitigate the risk of embedding secrets into code and making them public, it is necessary to scan the code for the existence of the secret prior to publishing it. A developer should not use a secret in the code, especially if the code is published on the internet. That sounds simple enough, but there are two challenges in this scenario. One is correctly identifying secrets within the code, as they vary in structure from one service to another. Then, there’s the prevention. How will the developer know if he or she has secrets in their code before publishing it?

GitHub offers a solution. It has offered a built-inservice that detects secrets and alerts developers if those secrets are in their code. This feature is useful, but it only scans code that has already been published. This is not ideal, because it makes application security reactive in nature. Inevitably, some leaked secret vulnerabilities would fall between the cracks. 

The new “push protection” feature, recently announced by GitHub, changes the dynamics of the situation. Push protection checks for more than one hundred types of tokens/secrets as developers push code into production. It blocks the push if it detects the presence of a secret. GitHub describes the process as scanning for what it calls “high-confidence secrets,” which has a low rate of false positives. 

Push protection has two goals. First, it stops secrets from getting into code. Second, it aims to keep code secure without disrupting the developer’s experience. The alerts are built into the developer’s integrated development environment (IDE) or command line interface(CLI). The alert may contain recommendations for remediating the problem. This approach enables developers to review alerts and remove secrets from their code before they push it again. If the suggested remediation does not work, or makes sense, the developer can move ahead with the push by resolving the secret as a test case or false positive. Or he or she can flag it as a real instance but fix the issue later. 

A developer can bypass the push protection.However, in that event, GitHub creates a closed security alert. If the developer flagged a secret as something to deal with later, GitHub generates an open security alert so the developer and repository admin can collaborate on remediation when they are ready to tackle the problem.

Why Push Protection is a Big Deal

It may not seem like push protection is a major advance in AppSec. It’s an incremental feature that adds to GitHub’s existing secret scanning capabilities. However, it is a significant development because it shifts code protection from being reactive to proactive. Now, instead of waiting for scans of published code to reveal the presence of secrets, developers can know about secrets before they commit and push the code into production. This makes the code more secure.  

Secret scanning’s push protection is already delivering results. Since its beta release in April 2022, when it was made available to GitHub Advanced Security users, push protection has prevented 17,000 potential secret leaks. This resulted in savings of over 95,000 hours that would have been spent revoking, rotating, and remediating exposed secrets.


The leak of a secret exposes applications to risk. Existing reactive methods of detecting and remediating secret leaks were deficient. They were not aligned with the way developers worked, and they allowed for too much time to elapse between the discovery of a leak and its correction, if in fact such a correction ever occurred. GitHub understood that developers had to be part of the solution, empowered to deal with secrets, but in a way that would not negatively affect their productivity or overall experience. Secret scanning’s push protection is the solution. It enables proactive detection and remediation of leaked secrets.

Suridata will make sure your GitHub configuration is set to enable the new push protection feature. For more information, contact us.

Haviv Ohayon

Co-Founder & COO

Back to list