---

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.

---

What is SaaS compliance?

To understand what SaaS compliance is, it’s worth stepping back and considering the relationship between technology and compliance in general. While certain kinds of compliance are not specifically about technology at all, such as financial controls in Sarbanes-Oxley, in reality nearly every aspect of compliance connects to some type of information technology. Given that businesses use computers for virtually all operational and financial processes, whatever software, infrastructure, and data that affects those processes is subject to compliance. 

SaaS is no exception. Just as consumers’ personal identifiable information (PII) is regulated by privacy laws when it’s stored in on-premises data systems, it is also subject to those laws when it is stored on a SaaS application. It does not matter that the SaaS app runs on the SaaS vendor’s infrastructure. You are still responsible for ensuring compliance. The difference with SaaS is that some of the compliance is your job, while other things, like security of infrastructure, is the duty of the SaaS vendor. 

In practice, this means ensuring that your business meets the criteria set by a compliance certifying organization. For example, with Payment Card Industry Data Security Standard (PCI DSS), your SaaS vendor will have to pass a PCI DSS certification audit. And, whatever systems you have that integrate with that SaaS app will need to possess controls that can pass a PCI DSS certification audit.

---

Examples of SaaS compliance

Here are some of the more common areas of compliance that bear on SaaS applications:

The General Data Protection Regulation (GDPR) — This European Union (EU) law is intended to protect individuals’ privacy. It ensures data rights for EU residents, which translates into compliance obligations on the part of businesses. Violating GDPR can result in serious fines. The law gives EU residents a great deal of control over their personal data. For example, they can access their data, erase it, or correct errors in it. SaaS comes into play if a business is storing EU residents’ private data on the SaaS app, e.g.,through a customer relationship management (CRM) system. To be SaaS compliant, the SaaS vendor has to provide the kind of data access and reporting that the law requires. On a related front, some European laws require “data sovereignty,” which calls for storing a Citizens’ data in their country of residence e.g., German citizens’ data must be stored in Germany, and so forth. In this case, a SaaS vendor must be able to store data in the right country—and be able to demonstrate to auditors that it has done so. 

Service Organization Control 2 (SOC2) — SOC2 is an audit process based on the American Institute of Certified Public Accountants (AICPA) Auditing Standards Board’s Trust Services Criteria (TSC). SOC2 verifies if a company’s IT systems follow TSC principles, which mostly have to do with secure management of customer data. Becoming SOC2 certified means developing and enforcing stricture data security policies. Many popular SaaS applications, particularly those that deal with business transactions, have passed a SOC2 audit. 

The International Organization for Standardization (ISO) ISO/IEC 27001 — This is nota regulation or industry-specific set of rules. Rather, ISO/IEC 27001 is a standard, a collection of guidelines for information security. In terms of SaaS, ISO/IEC 27001 recommends policies for entrusting data to a third party, such as a SaaS vendor. 

Health Insurance Portability and Accountability Act (HIPAA) — This 1996 US law requires certain kinds of healthcare data, such as patient medical records, to be stored on infrastructure owned by the healthcare provider. The provider must pass aHIPAA audit, which may involve demonstrating that the provider is not storing patient data in a SaaS system. 

PCIDSS — this multi faceted security standard was developed by The PCI Security Standards Council, which represents the payment card industry. It is not a law like GDPR, but it is required for businesses that process payment card transactions.Any SaaS vendor that wants to handle payment cards must pass a PCI DSS certification. For SaaS customers, the PCI DSS audit process may examine how a SaaS provider handles customer card information. It looks at security management, software design, policies, and procedures. 

Other regulatory schemes that can affect how SaaS vendors operate, as well as how their customers interact with SaaS, include the New York Cybersecurity Regulations, which deal with financial services firms’ cybersecurity, and rules from the Federal Financial Institutions Examination Council (FFIEC).

---

Getting SaaS compliant

Making sure your company’s SaaS is compliant need not be a major undertaking. In some cases, it will merely involve checking that your SaaS vendors are compliant with relevant compliance requirements. On your end, you have to understand where SaaS apps handle data that’s applicable to compliance. For example, if you have a SaaS-based enterprise resource planning (ERP) system, you need to know what financial and customer data it stores. You may also need to map out how a SaaS ERP handles controls over accounting procedures, if that is necessary for compliance.

Getting SaaS compliant tends to be across-organizational process. Stakeholders from IT, security, audit, and legal need to get involved and collaborate. This is true for many areas of compliance, but with SaaS there is the added risk of business units arranging for SaaS on their own, without telling IT or security. The potential exists for accidental lapses in compliance due to such “shadow IT” situations. An open dialogue about SaaS compliance can avoid these risks.

---

Conclusion

Use of SaaS can affect compliance. SaaS apps may store data that’s subject to compliance rules, such as GDPR and EU residents’ private information. It is essential to know what data is being handled by SaaS vendors in your organization—and that they are able to pass compliance audits or certifications. Getting to success involves including SaaS in existing compliance preparation and audit processes, which may necessitate cross-organizational cooperation.

---

SaaS is software, but its security parameters are different from those of traditional, on-premises software. A SaaS app is cloud-based, with access rights that are sometimes unclear. Third-party integrations can create vulnerabilities, as well. And, governance of SaaS apps can be spotty or nonexistent—especially when “shadow IT” takes over and business units purchase SaaS for themselves without notifying the IT department or their partners in cybersecurity. The article explores these issues and discusses the top three SaaS security challenges: access management, misconfigurations, and regulatory compliance.

---

1-Access Management

Access management is an essential element of any cyber security program. Indeed, managing who can access what is a fundamental control in all major cyber security frameworks. SaaS introduces some unusual challenges to access management, however. SaaS users can be anywhere, on almost any device. They can access the SaaS app, which may contain sensitive data, from outside the corporate network. These factors make it imperative that security teams and identity managers establish who is who, and what each user is authorized to do on the SaaS app.

User authentication, which is the verification of a user’s identity prior to granting access, can be challenging with SaaS. If a user tries to log in to a SaaS app, how can system owners be confident that it’s the real user, rather than an attacker impersonating the user? Multi Factor Authentication (MFA) is essential to reduce the risk of unauthorized access. Rigorous monitoring of identities is also a wise practice to stop malicious actors from gaining access to SaaS apps.

Third-party integrations create a related access risk. In some cases, plugins that connect one SaaS app to another make the plugin into an unmonitored “user” of the app. If an attacker takes over the plugin, which can occur easily when plugins are not maintained properly by developers, he or she can gain access to connected SaaS apps. 

Once a user has accessed a SaaS app, what is he or she allowed to do? This is a matter of authorization. Most SaaS apps enable multiple levels of access privileges. The more senior the user, the greater the access privileges, generally speaking. An executive user might be able to see all customer data, while a sales rep can only see his or her accounts. Administrative users may have the right to delete or export data, which makes their accounts attractive takeover targets for hackers. 

Geography is yet another aspect of SaaS access management. It is a good policy to restrict SaaS access rights by country or region. This will mitigate the risk of external threats to some degree, because hackers tend to be outside of the country hosting the SaaS app. There can be regulatory issues, too, with potential compliance risk arising out of users moving consumers’ private data out of its country of origin.  

---

2-Misconfigurations

Each SaaS app enables extensive custom configuration. This is usually a great benefit. Individual users can set up their SaaS apps the way they want them. Administrators can adapt SaaS apps to suit company-wide use cases and policies. The scope of configuration options, however, also creates security risk. 

Part of the problem is again, simply the scale of the SaaS estate in the average business. If a company has deployed a hundred SaaS apps (that it knows of), and each app has dozens of “knobs” users and admins can toggle for their specific configuration needs, the result is an environment with thousands of potential configurations. Any one of them could be insecure. Manual management is not a realistic option.

For example, some SaaS-based storage services enable universal file access by default. That means that virtually anyone in the world can access a company’s sensitive data on the Internet, without anyone even knowing. If users are not aware of this problematic default setting, data exfiltration risk will follow. 

A further difficulty comes from the frequency with which SaaS apps update themselves. While it is a great advantage to have an application that automatically makes new features available to users, this is also a driver of risk. A SaaS update might reset configurations to default, for instance. It will then be up to users and admins to set configurations back to match security policies—a task that is effectively impossible to perform thoroughly without automation.

---

3-Regulatory Compliance

SaaS apps can expose companies to regulatory compliance risks, which have a peculiarly synergistic relationship with security risks. For example, poor management of role-based access controls (RBAC) can result in breakdowns of “segregation of duties” controls needed for compliance with laws like Sarbanes-Oxley. Specifically, a segregation of duties control is supposed to do things like prevent a single user from being able to approve a purchase order as well as a payment to a vendor. Without the control, a user could commit fraud. 

If the company in question uses a SaaS-based accounting system, then it will be up to SaaS administrators to ensure that their access privileges they cover the segregation of duties control they need for Sarbanes-Oxley, e.g., User A is permitted to access the purchase order (PO) module of the software, but not the check approval module. User B is permitted to use the check module, but not the one for POs. This may not be a big problem, but given the breadth of SaaS configuration possibilities available, it’s an easy control to overlook.

---

Conclusion

SaaS can translate into security problems.Areas of risk exposure include access management, configuration, and regulatory compliance. Manual approaches to addressing these three areas of challenge are inevitably deficient. Intelligent, automated solutions are the best approach. With new SaaS security management tools, it is possible to stay on top of access, configuration, and compliance risks across even the broadest and most multi-faceted of SaaS environments.

---

It’s easy to understand why SaaS is so popular. The technology frees customers from many of the total cost of ownership  of provisioning and supporting software and infrastructure. At the same time, SaaS also exposes its customers to new types of risk, especially from third-party integrations using SaaS plugins.

---

SaaS Plugins: What They Are and How They Work

A SaaS app typically works through a web browser. There is no software client required, and the data and application functionality occur in the cloud. Most SaaS apps allow third-party vendors to build plugins that provide additional capabilities to the SaaS.

For example, a customer relationship management (CRM) SaaS app might allow plugins from productivity suites like Microsoft 365 or Google Workspace. In these SaaS-to-SaaS integrations, data from the CRM can flow directly into the productivity suite, e.g., automatically updating an email address in the CRM from the latest data in the productivity suite.

For the plugin to work, the SaaS user has to grant permissions to the third-party plugin. The plugin acts on behalf of the user within the SaaS app, a capability made possible through the use of authentication tokens. 
This has ramifications for security. The third-party plugin, built by a developer who has nothing to do with the CRM app, can gain access to its data and operate on behalf of the user.

---

Why SaaS Plugins Can Be a Source of Risk

SaaS plugins expose their users to cyber risk. There are a number of reasons for this, but the foundational problem has to do with how SaaS plugins act on the user’s behalf. The SaaS app sees the plugin as the user. 

Permissions and configurations are another source of security trouble with SaaS plugins. A plugin can require the user to agree to a wide scope of permissions that are not really needed for the plugin to do its job. This can be for reasons ranging from developer laziness to malicious activity.

For instance, a customer service representative might have access privileges that allow him or her to see customers’ tickets, financial transactions, customers’ credit histories and the like. There presentative can have a pre-installed SaaS plugin, installed by the admin, for sending email notifications whenever new tickets are opened. Yet, the plugin asks for far broader data access than just the tickets status. This is almost always not a deliberate choice, but rather an administrative oversight. Given that the average organization has 110 SaaS apps running, it’s not hard to see how admins could make this kind of mistake. 

Going further, if SaaS users are allowed to install plugins on their own, and/or grant access to any plugin they want, they may install malicious plugins or legitimate ones that have no business need for the company. This is a security policy issue, but one with potentially serious repercussions. 

It may be a surprise to some that a SaaS plugin can be malicious. Aren’t they “official” plugins if they are available at the SaaS app’s store? One might be surprised at the vulnerabilities embedded in plugins that are available for easy download and installation. In fact, not all app stores properly scrutinize the plugins uploaded to them. It could be a simple case of abandonment. If the plugin-vendor no longer supports the plugin and updates it with security patches, the plugin will soon become a source of risk. Or, some untrustworthy party buys a once-legitimate plugin and modifies it, perhaps maliciously, and the end-client has no knowledge of the change.

---

The Top 5 Risks From SaaS Plugins

With these factors in mind, consider the potential impacts that a malicious plugin could have on a business. Here are the top five risks:

1.  User impersonation — If an attacker can convince a user to install a malicious plugin to its SaaS, they can than act within the SaaS as the user itself.  He or she can impersonate that user and interact with other employees or even customers, while impersonating the user. They may view sensitive data, perhaps taking advantage of overly generous permissions in the process, and manipulate data, delete it, or steal it. 

2.  Data breach — A SaaS plugin can form the attack path for a data breach. With access to the SaaS via the plugin, the attacker controlling it can exfiltrate data through it.

3.  Business disruption — If a SaaS plugin is vulnerable to a take over, it can be commandeered by hackers and made into a vehicle for accessing the SaaS data. This can be disruptive to the SaaS customer, potentially even threatening to shut down their operations until the attack can be mitigated. 

4.  Abuse of resources — SaaS applications are not cheap, so an attacker might want to take advantage of free, improper access to perform tasks like data analytics or file storage on the SaaS customer’s account. 

5.  Compliance Risk — A data breach can lead to compliance penalties if, for example, it results in violations of privacy laws. A compliance audit that reveals deficient controls over SaaS access can also trigger problems for companies that need to comply with frameworks like NIST CSF, SOC 2 and so forth.

---

Addressing Third-Party Integration Risk From SaaS Plugins

It is possible to reduce third-party integration risk from SaaS plugins. Suridata, for example, provides deep visibility into SaaS application risk, including automated monitoring of SaaS plugin permissions. The solution can identify third-party integration risks and automatically remediate them with workflows that orchestrate the complex steps required to make SaaS plugins safe.

---

Conclusion

SaaS apps, which are becoming increasingly popular due to their favorable IT economics and ability to speed up adoption of useful software, expose companies and users to cyber risks. SaaS plugins, in particular, create third-party integration risks. Attackers can exploit excessive permissions and malicious or out-of-date plugins to impersonate users and perpetrate data breaches, among other negative security impacts. Solutions are available however, that can automatically scan SaaS plugins for security weaknesses and then provided automated remediation.

---

A Growing Area of Risk Exposure

The scale of SaaS activity is one reason why risks can be such a challenge with SaaS apps. According to Vendr.com, the average organization uses 130 SaaS apps.Each app has hundreds of unique controls and settings that are subject to adjustment at will. Users have expectations for SaaS apps that may run counter to what security teams want. It can get tricky to balance security with functionality, a problem that can get more difficult to address as SaaS apps interact with one another.

---

The Impact of a Dynamic Environment

The dynamic nature of SaaS apps is a further factor complicating their security. SaaS apps seldom sit still. Their makers update them frequently—in some cases every day. This is one of the great things about SaaS. Users don’t have to wait for new versions. They appear automatically in the browser, usually as the result of Continuous Integration/Continuous Delivery (CI/CD) pipelines that push new code into production. The difficulty with this process is that new code often affects security settings. 

Security teams may struggle to keep up, leading to a situation known as “configuration drift.” Additionally, because frequent updates to SaaS features usually result in a need to change security settings, security teams may let users change their own settings – granting excessive permissions to users so they can perform this task. The problem is that the security team may then fail to revoke those permissions at a later time. This creates risk exposure.

---

A Brief Note about Shared Responsibility for SaaS Security

SaaS apps work on a shared security model. This means that the vendor covers certain areas of security, such as the protection of the vendor’s physical infrastructure, networks, application security, and server operating systems. The customer is responsible for its own data security and user access controls, along with numerous security settings.This model makes sense, because the vendor cannot possibly know how to assign access privileges for the customer, to name but one example. However, the shared model can lead to confusion and omissions in security practices on the part of the customer.

---

Drivers of Common, but Serious SaaS App Risks

SaaS apps are exposed to risk through a variety of factors. Some of the most common include:

Misconfigurations — SaaS apps offer users and admins many configuration options, some of which can expose the user to risk. For example, Google Drive shares are available to anyone by default. This means that sensitive data could accidentally be exposed to virtually any malicious actor if this default configuration is not changed.

Deficient access management controls — Most SaaS apps allow access based on just a user name password pair. This is not secure, given the prevalence of credential stuffing attacks and comparable threats. A better practice is to implement multi-factor authentication (MFA). Risks can also arise out of misconfigured single sign on(SSO) solutions, which can accidentally allow unauthorized users to access SaaS once they have signed in elsewhere.

Third-party risks — Some SaaS apps can integrate with other, third-party SaaS apps, e.g.,using a plugin to connect a SaaS to a SaaS-based storage app, and so forth.These plugins can create risk because they may be given access permissions that are not aligned with security policies.

In attention to regulatory compliance factors — The customer is responsible for many important aspects of regulatory compliance, e.g., protecting consumer data privacy, abiding by “data sovereignty” laws, and so forth. If SaaS owners do not pay adequate attention to compliance, they can increase risks of compliance penalties and costly remediations.

Data management oversights — The SaaS vendor is not responsible for data management.It is up to the customer to define and enforce the necessary data security policies, e.g., encryption, data retention and lifecycle, and privacy controls.Without such policies, storing data in a SaaS app creates data security risk.

Lack of strong password policies — Deficient password policies can lead to excessive risk of breach, e.g., if users can choose simple passwords, and are not required to change them periodically, it becomes easier for a malicious actor to gain entry to the system, especially if MFA is not in use. It’s worth noting that not all security professionals agree that strong passwords lead to better security. Ina great example of unintended consequences, a requirement to maintain strong (i.e., difficult-to-remember) passwords can cause users to employ the same password for multiple systems, which creates risk exposure. 

In attention to account statuses — When users leave their jobs, or switch to departments where they will no longer need access to a SaaS app, it is essential to switch off their access. This does not always happen, which leads to the risk of unauthorized access. The web-based nature of SaaS makes this risk particularly acute, as a former employee can access the SaaS from home and access data to which he/she has no permission to access. These are sometimes called “zombie accounts.” Sharing of accounts is a related risk, one that exposes the organization using the SaaS app to risk of unauthorized access.

---

Detecting and Mitigating SaaS App Risks

What can be done to mitigate such SaaS app risks? The simple answer is that the SaaS client must constantly monitor and correct the SaaS security settings to properly protect it. However, considering the number of SaaS apps at the average business, it becomes obvious that any manual processes for monitoring and correction of security settings is going to be unfeasible. There are simply too many apps and too many variables to keep track of, especially in a dynamic environment. Undetected risk exposure is a virtual certainty.

The mitigation of SaaS app risks will require automated risk detection and remediation processes. Specialized solutions, now on the market, can continually scan SaaS apps and flag potential security risks. They can then automatically address risks caused by misconfigurations, zombie accounts, and so forth. These tools can be set to conform with an organization’s unique security policies.

---

Conclusion

SaaS app risk is, or should be, a main area of focus for cybersecurity teams and their partners in IT operations. The potential for data breaches and system outages looms if SaaS security weaknesses are not discovered and addressed. It can be a daunting subject, though, given the number of apps in question and the range of security configurations present in each app. Solutions are available, however. They leverage automation to overcome the administrative burden of detecting and mitigating SaaS app risks.

---