In a decisive move to strengthen the security of financial markets, the U.S. Securities and Exchange Commission (SEC) has mandated that public companies must swiftly disclose any significant breaches that could impact investor trust and market stability. This directive highlights the critical need for ongoing transparency and robust cybersecurity measures, especially as the reliance on cloud services and SaaS applications grows. With cyber threats on the rise and SaaS platforms becoming integral to operations, companies are required to adopt a more strategic approach to their cybersecurity practices.
Navigating these new SEC regulations presents significant challenges, particularly due to the rapid nature of required, detailed reporting, along with the differences in SaaS products. To be ahead of those challenges, SaaS security should be implemented as an ongoing approach, and managing the SaaS eco-system is the game changer when it comes to the detection and accurate reporting of security incidents.
The Suridata Difference
This is where Suridata steps in as an indispensable partner in the SaaS security landscape, providing the solution that allows organizations to effectively meet the SEC’s stringent cybersecurity disclosure rules. By enhancing visibility into entire SaaS ecosystems, including shadow and third-party applications, Suridata enables a proactive cybersecurity approach. More than just aiding in immediate reporting requirements, Suridata strengthens the overall SaaS security measures through detailed management of third-party app risks, thus ensuring ongoing compliance with SEC standards.
As the cybersecurity landscape continues to evolve, the complexity of adhering to regulatory standards intensifies. Vigilance in security practices, particularly concerning the widespread use of SaaS applications, is crucial. Partnering with Suridata equips organizations to face these challenges head-on, protecting their critical assets and reinforcing their commitment to investor trust and regulatory compliance.
Read the whitepaper and download the checklistto understand how to implement a SaaS security practice, that will not only help you prepare the report the day after but to prevent you from writing it in the first place.
Snowflake, a leading cloud-based data warehousing company, recently faced a wave of attacks targeting its enterprise customers, resulting in the leakage of millions of sensitive records. Here’s a closer look at what happened and how companies can protect themselves.
Attack Path and Methodology
The attack spree against Snowflake customers began in mid-April 2024 and was officially acknowledged by Snowflake on May 23, 2024.
The attack did not stem from a vulnerability within Snowflake’s platform. Instead, it was an identity and misconfiguration-based attack that exploited weak identity and access controls, as well as the absence of multifactor authentication. Here’s a breakdown of the attack path:
Initial Compromise: Attackers used credentials stolen by info-stealing malware, probably using Lumma Stealer malware.
Accessing Accounts: The attackers gained access to Snowflake environments using these stolen credentials. Notably, many of the compromised accounts lacked multi-factor authentication (MFA), making them easy targets.
Data Exfiltration and Extortion: Once inside, the attackers stole data from the compromised databases. They further pressured organizations by warning they would sell the stolen data on the dark web if their demands were not met.
Widespread Impact: The attack campaign affected several major companies, leading to high-alert advisories from cybersecurity authorities like the Cybersecurity and Infrastructure Security Agency (CISA).
Security Recommendations
In response to these incidents, Snowflake and the cybersecurity community have issued several recommendations to mitigate such identity-based threats:
Enforce Multi-Factor Authentication (MFA): Implementing MFA across all accounts is crucial to prevent unauthorized access, even if credentials are compromised.
Set Up Network Policy Rules: Restrict network access to trusted locations and ensure only authorized users can access critical systems or sensitive SaaS accounts.
Reset and Rotate Credentials: Regularly update and rotate credentials to limit the potential damage from stolen credentials. This will reduce the time window during which stolen credentials can be used by malicious actors, disrupt attackers ongoing access and reduce the ‘Risk of Credential Stuffing Attacks’ (Credential stuffing attacks involve using stolen username and password combinations from one breach to gain access to accounts on other services).
Monitor for Unusual Activity: Continuously monitor for signs of unusual user activity, such as unauthorized access attempts from unfamiliar IP addresses.
How Suridata Can Help
Suridata offers robust features to help organizations secure their SaaS environment, including Snowflake. Here’s how Suridata can assist:
Comprehensive Security Analysis: Suridata conducts comprehensive security assessments of SaaS configurations, identifying potential weaknesses and exposures. Preventive measures that can be taken include:
Restrict public access and enforce IP whitelisting.
Restriction of network policies that are too permissive.
Identify users not enrolled in MFA and enforce mandatory enrollment.
Identity and Access Management: Suridata enhances identity and access management by ensuring that authentication mechanisms, including MFA, are in place and properly configured for all users. It also detects user anomalies, that can provide insights into suspicious activities, potentially preventing threats before they can escalate.
On-demand User Remediation: Suridata offers remediation capabilities, enabling organizations to swiftly address user misconfigurations and enforce best practices across the Snowflake environment. From Suridata’s platform, risky users can be blocked from an application, their permissions can be revoked, or they can be deleted.
Conclusion
The recent attacks on Snowflake customers highlight the critical importance of robust identity and access controls in the SaaS environment. By implementing preventive measures, organizations can significantly reduce their risk of falling victim to similar identity-based threats. Suridata conducts thorough security checks of misconfigurations, identifying potential weaknesses. Key preventive recommendations include:
Implementing network policies that restrict access based on the user’s IP address.
Identifying and tightening overly permissive network policies to ensure access is granted only to authorized users.
Identifying users not enrolled with MFA and ensuring they are promptly secured.
Not sure if you are using Snowflake? Suridata offers free application scanning to help you identify and prevent attacks in your SaaS environments.
If you’re a malicious actor in cyberspace, you could do much worse than targeting a Workday instance at a large corporation. As one of the world’s leading Human Capital Management (HCM) applications, Workday holds valuable data from employees and businesses worldwide.
The scale of Workday’s user base hints at the level of risk: 50 million users in over 170 countries. Over a million users access Workday every hour, executing 365 billion transactions annually. The platform’s scale and inherent risks prompt a strict security approach.
Workday has rigorous security controls protecting its infrastructure. However, the problem is that much of the risk exposure inherent in Workday exists outside of what the company provides.
Workday security is a series of security steps, protocols, and information security controls to mitigate risks in the complex Workday environment. Workday runs in highly secure data centers with network and infrastructure security operations. The company enforces strict application security (AppSec) policies, and all data is encrypted and subject to segregation by the client to protect the multi-tenant architecture.
Passwords are “native login,” always hashed—never stored or transmitted in their actual forms. However, it’s worth paying attention to the type of password hashing algorithm used, as older methods may be inefficient. Modern algorithms like bcrypt or Argon2 are adaptive and more resistant to attacks, making passwords significantly more difficult and time-consuming to track. A modern, customizable hashing method is crucial to protect your Workday passwords.
But Workday offers other crucial security features. The whole application is subject to a single security model, so all user interactions are subject to the same policies and enforcement mechanisms. The platform also offers single-sign-on (SSO) using security assertion markup language (SAML) and multi-factor authentication (MFA).
Consider what’s going on inside a typical Workday instance. You might have salary and benefit information for thousands of employees worldwide. Employees can see their salary and benefits, not anyone else’s. Administrative users may have greater visibility into this private information and be able to define access controls and security configurations.
This power ensures that no one sees what they’re not supposed to see and that no outsider can view, exfiltrate, modify, or delete any data. Still, Workday is a SaaS app like any other, so it suffers from the same SaaS security challenges. Just like you would secure your Salesforce environment to protect customer data, you should apply extra security measures to your Workday platform to protect employees’ private information.
Why Should You Care About Securing Your Workday Platform?
Workday’s extensive user base and dynamic functionality make it vulnerable to cyber threats. At most Workday companies, virtually every employee can access the software, subject to a broad and often complex range of permissions. The software integrates with other systems, too, which further expands the attack surface.
Despite having its robust security features, Workday still faces various risks. Most of these risks stem from using and integrating this SaaS app with other apps, but they can be mitigated with the proper SaaS security best practices. As a Workday client, here are the common security threats you should be concerned about:
Phishing attacks—Malicious actors can trick employees into sharing their Workday login credentials or other information that lets them gain unauthorized access to the application.
Credential stuffing attacks—If attackers have stolen passwords, such as those on the dark web, they can try to access Workday by pairing known user emails with possible passwords. This attack can work if MFA is not switched on and users use the same password for personal accounts.
Insider threats—Employees may abuse their access to the application for many reasons, ranging from curiosity to disgruntlement and greed. Privileged users comprise the most severe insider threat.
API threats/integrations—Workday connects with many popular enterprise applications through its application programming interface (API). The same API can be the basis for integration with virtually any software. Depending on how you configure the API, it may be vulnerable to threats like broken access control or injection attacks. Left un-remediated, vulnerable APIs can leak data to unauthorized parties.
Supply chain attacks—Workday offers an integrated development environment (IDE) so developers can build custom add-ons and integrations for the software. By allowing custom code from outsiders, Workday could enable insecure software development processes. This exposes Workday customers to supply chain attacks like malicious code injections, social engineering, and compromised dependencies.
It is possible to let some Workday accounts become overprivileged, even if accidentally. For example, if a user has an admin role but then switches to a new job that does not require admin access and that access is not revoked, the user has excessive privileges. Bad actors can exploit these to access and steal sensitive data, manipulate settings, or approve financial transactions.
2. Complexity of roles, hierarchies, and organizational structures
Workday allows you to create highly complex user roles with access rights that map to organizational structures and hierarchies. This level of detail is excellent because you can set up your access how you want it. However, organizations are dynamic, and over time, the role definitions you set up will become obsolete, creating risk exposure in the process.
3. Lack of visibility over access controls
The complexity of roles and their respective privilege leads to a situation where security admins may lack visibility into access controls. Workday does provide an interface with a view of access controls, but when there are thousands of users to manage, with varying and ever-changing permission levels, admins struggle to parse who can do what on the software.
6 Steps to Improve Workday Security
1. Monitor security configurations
Security admins’ flexibility and discretion can lead to insecure configurations, such as overly permissive bring-your-own-device (BYOD) policies or a lack of MFA. These misconfigurations allow attackers to enter your systems and can be very challenging to spot. To monitor security configurations properly, you should use an automated monitoring tool like Suridata, which scans configurations continuously and flags problematic ones.
2. Create a privileges inventory and regularly update it
Keep your Workday access model simple and map it clearly to your organizational model and role definitions. The result will be an inventory of privileges that identifies what every type of user can see and do on Workday. This inventory should include the privileges granted to Workday integration system users (ISUs) and Integration Security Groups (ISSGs). Keeping this inventory up to date has to be someone’s job, and executive sponsorship may be necessary to ensure the budget to cover this cost.
3. Deploy API security and third-party security countermeasures
The Workday API is a potential attack surface, so deploying countermeasures that mitigate API risk is a best practice. Firstly, it’s worth familiarizing yourself with the top 10 risks for OWASP API security. This list gives you a comprehensive overview of the threats to look out for and how attackers exploit these gaps. Then, using a dedicated API security solution, you can scan your environment for “rogue” APIs that may have been abandoned but expose Workday data to external API clients. These tools can also monitor API security settings and flag insecure APIs.
4. Employ Secure DevOps practices
If your organization uses the Workday IDE and leverages DevOps, you should employ AppSec methods in your development process. One key component of AppSec is code scanning, for which you can employ SAST and DAST tools to identify vulnerabilities early. Integrating “shift left” security remediation can also help you embed the proper security controls during development, preventing you from having to fix vulnerabilities while your Workday app is running.
The personnel data on Workday is subject to several laws regarding consumer privacy, depending on where you operate. If you have employees in California, you must comply with CCPA, for example. If you’re in Europe, it’s GDPR. Violations of these laws can be costly and time-consuming to remediate.
You can reduce your compliance risk by continuously monitoring for compliance (for instance, checking that data is in the correct sovereignty and no data about German citizens is stored in France).
6. Continuously scan for insecure data
Workday is likely just one element in your broader SaaS ecosystem. It’s also likely to be connected to other SaaS apps you use, such as online storage solutions. One risk in these conditions is that users will move data from Workday to another app, such as an online storage platform. This data storage can be highly insecure, leading to the risk of breach, exfiltration, and all the expensive remediation actions that follow such an event.
SaaS security solutions like Suridata can continuously scan for personnel data across the entire SaaS ecosystem, automatically flagging data that needs to be removed and providing detailed insights into the issue so you can activate the proper remediation workflow.
Making Workday SaaS Secure
Workday has many security features, but the software remains vulnerable to threats like phishing attacks, API attacks, and brute force. Complex access rules compound the problem. To make Workday more secure, you must implement countermeasures addressing these risks. Suridata can make securing your Workday platform and data much more manageable. The Suridata tool scans your entire SaaS ecosystem (Workday and beyond, no matter how many SaaS apps you have), monitoring Workday’s security configurations, spotting any abnormal user behavior, and accurately identifying data that might have been mistakenly or maliciously exported from Workday. Interested in seeing it in action? Schedule a demo with our team.
Is it a coincidence that the mascot for GitHub, the world’s largest source code host, is cat? Probably not, given that managing software developers is often likened to herding cats. Although now owned by Microsoft, GitHub is at the core of most open-source software development projects, with over 400 million code repositories and 100 million developer users. Thousands of major enterprises rely on GitHub as a developer platform.
In functional terms, think of GitHub as a software-as-a-service (SaaS) application, albeit one that comes with some serious security challenges. Hackers love GitHub because it contains so many keys to so many different kingdoms. It’s home to all sorts of login credentials for sensitive networks. Mostly, though, GitHub represents an amazing platform for launching supply chain attacks. By implanting malware-laden code components in GitHub, a malicious actor can easily seed thousands of development projects with unseen trap doors.
Attacks on GitHub have become common, but uncommonly sophisticated and potentially devastating. GitHub leaked more than 12 million authentication secrets and keys in 2023 alone. Then, just last month, attackers used stolen cookies to hijack GitHub accounts and gained the ability to inject malicious code into trusted repositories.
What is GitHub security?
Given the value of GitHub as a target, it should make sense that you need to take steps to defend your GitHub instance. GitHub itself offers numerous security features to help in this workload. Third-party tools can be useful, as well. Most importantly, however, it’s necessary to recognize the risks inherent in using GitHub and plan carefully to mitigate them.
GitHub should be a priority for investments in security due to the central role it plays in application development. Not only is GitHub usually home to all sorts of valuable source code and internal documents, and credentials, it’s also ground zero for supply chain attacks on your organization. And, multiple teams typically access and collaborate on GitHub for version control—a formula for cyber vulnerability. 7 GitHub Security Best Practices for 2024 | Suridata
GitHub may already be part of your security program, especially if your organization has implemented application security (AppSec) countermeasures at the development stage or if it is doing DevSecOps. Even if you are “shifting left” in this way, though, you might still want to pay extra attention to GitHub, given its potential for risk exposure at the development stage.
Indeed, it might be better to think about GitHub in terms of SaaS security. It’s most likely one of hundreds of SaaS apps that your organization is using, but perhaps you haven’t thought about it that way. It’s deep in the recesses of the IT organization, not a production app like Salesforce or Microsoft 365. So, you may not apply SaaS security to GitHub, but you might want to consider doing so.
Securing GitHub environments brings its share of challenges, especially considering the integrated, collaborative nature of the platform and the many different people and teams who use it. The fact that most users are developers compounds the challenges. They may de-emphasize security as a concern or neglect to follow security policies that interfere with their personal productivity (See: Cats, herding).
Challenges include:
Staying on top of access controls and permissions—Who can access GitHub, and what can they do once they’re on the platform. GitHub may not integrate/federate with your identity and access management (IAM) solution, so it can be hard to know who is who and who can do what.
Keeping third-party integrations secure—GitHub integrates with hundreds of other applications, from IT ticketing systems to work tracking tools and beyond. These third-party integrations can expose GitHub to risk, particularly the risk of unauthorized access.
Protecting the organization from GitHub-based phishing and social engineering attacks—The community-centric nature of GitHub users, who may span different entities, makes phishing and social engineering a serious risk. Will you be able to tell if one of your user accounts has been compromised?
Avoiding misconfigurations that affect security—GitHub configurations can affect security. For example, applying proper Branch Protection Rules to ensure that new code is integrated only after it was checked and reviewed. Or, enabling GitHub built-in capabilities for scanning, identifying, by alerting on vulnerable dependencies within your code, as well as on possible secrets (i.e. passwords, tokens, etc.) that were accidentally placed within your code.
Protecting sensitive data stored in GitHub repositories—Are GitHub users storing data that hackers want, like log in credentials and keys? How would you know if they did?
7 Essential SaaS Security Best Practices for GitHub
There are a number of SaaS security best practices you can adopt If you want to be serious about securing GitHub, either on its own or as part of a broader AppSec or DevSecOps initiative. Some are based on GitHub’s own extensive built-in security features. Others use third-party solutions. Others, still are policy or process based.
Here are 7 to consider:
#1: Enable MFA for GitHub Accounts
MFA is an excellent countermeasure that cuts down on the chances of an unauthorized person gaining access to your GitHub environment. GitHub is on this, requiring two-factor authentication (2FA) using a time-based one-time password (TOTP). Many third-party solutions can also make this work, including Duo and Google Authenticator. One recommendation is to use an authenticator app versus SMS/Text messages for TOTP, due to the risk of simswap attacks that let hackers breach a GitHub environment even with MFA in place.
#2: Enforce Strong Passwords and Regular Updates
Strong passwords will help reduce the risk of unauthorized logins based on brute force attacks. Overall, though, GitHub requires a set of password policies, such as requiring regular password updates and strict rules against sharing passwords. It may be optimal to implement single sign on (SSO) and make access to GitHub subject to organization-wide access control policies and password rules.
#3: Activate GitHub Secret Scanning
GitHub enables you to scan your repository and search for secrets that should not have been stored there. For example, a GitHub user might add a security token or private key in a repository to make his or her life easier when dealing with application integration. However, this practice leaves these secrets vulnerable to breach, leading to more potential risk exposure. The GitHub Secret Scanner reviews the entire Git history on all branches and scours it for secrets.
The GitHub scanner has a relatively narrow focus, however. It mostly looks for known string structures like API Keys—possibly missing password, admin URLs, and so forth. A third-party tool like Suridata’s SaaS security solution can be configured to scan for a much wider range of data hidden in massive GitHub repositories. A further best practice, which should ideally be a policy, is to replace any secret that has been made public. You should assume that it was discovered by someone and that is has been compromised.
Code in GitHub is vulnerable to manipulation by malicious actors, e.g., implanting malware-laden code into your codebase, it is a good practice to limit access privileges by default. The fewer places in GitHub a user can go, the better. This means putting the principle of least privilege (PoLP) into effect. GitHub offers five levels of access privilege: Read, Triage, Write, Maintain, and Admin. By applying PoLP, you can limit users to the lowest level of privilege they need to do their jobs. As a result, your repositories will have less risk of accidental exposure of sensitive data as well as intrusions by hackers.
#5: Monitor Access Logs for Suspicious Activity
The sophistication of the March, 2024 GitHub attack, which involved inserting malware-infused copies of the popular Colorama tool in GitHub, shows how difficult it can be to detect attacks and prevent hackers from penetrating GitHub. To mitigate this type of risk, the best practice is to monitor GitHub’s logs, including access logs, for suspicious activity. Anomalies in access, such as users logging in from foreign countries or stolen cookies appearing on two devices at the same time, could signal the start of an attack.
#6: Implement Branch Protection Rules
This is not a SaaS security practice, per se, but it’s still quite important for the security of code that resides in GitHub repositories. When a user can create a branch, that enables him or her to create a new version of a code component. This may not sound like much of a risk, but if the user is a malicious insider, he or she can implant malware into the new branch, which can then go into production. GitHub has a variety of branch controls, including the ability to lock branches, restrict the merging of branches, and restricting branching privileges to certain users.
Your GitHub data is precious. It represents intellectual property, many person-hours of work, and, in some cases, the digital core of your entire business strategy. You need to protect that data from attack, especially ransomware attacks. Even a simple outage can cause serious problems. GitHub has its own backup feature, Git CLI, but third-party vendors like Veeam support GitHub backups as well and make GitHub backup part of a broader enterprise backup process. One challenge to deal with, however, is the risk that a backed-up version of a GitHub repository will itself become a target of attackers.
Onward to a More Secure GitHub
GitHub may not seem like it’s part of your SaaS ecosystem. It’s not an operational app or software your people use for general business productivity. However, structurally, and in all the most important senses, GitHub is very much a SaaS app. It’s web based. It’s accessible by browser from anywhere, on any device. It contains valuable, often sensitive data. As such, it should be subject to SaaS security countermeasures and controls.
SaaS security best practices for GitHub encompass standard SaaS security controls like MFA and strong passwords. It’s also wise to apply best practices that are specific to GitHub, such as secrets scanning and enforcing policies that limit the risks of branching. If you approach GitHub with these best practices, you should be able to improve your application security posture by making your software development processes more secure.
To learn more about how Suridata’s SaaS security solution can help with GitHub security, visit www.suridata.ai or book a demo.
Salesforce has been so successful that we tend to forget what a breakthrough it was when it debuted 25 years ago. At the time, people were skeptical that they could get enterprise-grade functionality on a browser. They were mistaken.
As the leading customer relationship management (CRM) platform, Salesforce is a testament to the innovation and agility SaaS apps bring to businesses. However, there are still risks, particularly when it comes to security.
39% of companies that use SaaS have experienced data breaches. Salesforce’s extensive integration capabilities, massive partner marketplace, and customization through purpose-built programming languages further exacerbate its cyber vulnerabilities.
Why you need to invest in Salesforce security
Salesforce is a highly professional organization that takes security seriously. However, the platform embodies several vulnerabilities, some of which are standard for SaaS and some particular to Salesforce. CRM apps like Salesforce hold sensitive data such as customers’ personally identifiable information (PII), financial details, and geolocation. Failure to secure SaaS data increases the risk of it being compromised by malicious actors and insiders.
This problem is not different from what happens with other SaaS apps, but Salesforce’s deployment is usually so broad and interconnected in an organization that it amplifies the risk. Likely, every sales, marketing, and customer support person and their respective managers have access to Salesforce. That’s a large number of accounts that attackers can hijack. Plus, any extra person accessing this data increases the risk of insider threats.
Salesforce security should, at a minimum, be part of your SaaS security best practices. However, Salesforce deserves extra attention because of the potential business impact of a security incident in this app.
Salesforce customers like Ohio’s Huntington Bank and the State of Vermont are dealing with the reputational fallout and expense of data leakage from the Salesforce Communities they set up. Securing your Salesforce app can prevent large-scale data breaches that often result in reputational damage, financial loss, and legal consequences.
The most common security risks of Salesforce
Custom code vulnerabilities
Salesforce customers can create custom-coded functions with its Java-like Apex programming language. Apex enables developers to build apps that call on the Salesforce backend database. While useful, Apex classes potentially expose sensitive Salesforce data to unauthorized database calls through its application programming interface (API). This is of particular concern if Apex is configured “without sharing,” a setting that ignores the user’s permissions, allows access to records, and offers the ability to change them.
Configuration weaknesses
You can configure Salesforce in ways that expose data to overly broad access. For example, the Salesforce Community module, which enables customers to set up public sites for their customers, can be configured to allow database access for guest users. Done wrong, this can easily lead to serious security misconfiguration vulnerabilities that facilitate data leakage.
Integration risks with third-party applications
Salesforce is usually integrated with email systems, enterprise resource planning (ERP) platforms, and accounting systems, making it a gateway for attacks. The platform integrates with thousands of applications, many created using Salesforce developer tools and APIs. As a result, the potential for improper access and malicious activities on the platform is extremely high.
Social engineering attacks
This threat is not unique to Salesforce. However, the breadth and scope of the app in most organizations makes it vulnerable to hackers who impersonate work colleagues to pry loose access credentials, commit account takeover and other data from unsuspecting users.
API vulnerabilities
Salesforce publishes numerous APIs that give other applications access to data and functionality on the Salesforce platform. While beneficial in business terms, the APIs create risk. One example is problems with object and file level security, where developers might generate an API call that does not consider the specific fields accessible, updatable, or deletable on the object invoked by the API. Significant risks also arise with the creation of third-party applications that invoke the Salesforce API but are themselves security deficient.
13 Essential Steps to a Secure Salesforce Environment
User Management & Permissions
1. Adopt the principle of “Least Privilege”
A Salesforce user should have the fewest possible access privileges. Applying this principle requires thinking and planning about user roles and what each role can access and clearly defining this in an Identity Governance framework. The “Least Privilege” principle should apply to system admins and developers working on custom Salesforce apps.
2. Implement strong passwords & MFA
The ability for Salesforce users to log in from anywhere, on virtually any device, is great for productivity but disastrous for security. Requiring strong passwords and multi-factor authentication (MFA) can help reduce the risk of malicious actors gaining access by guessing passwords or using stolen login credentials. Salesforce has its own native MFA feature, but customers can also use third-party solutions like Okta and Duo for this purpose.
3. Disable inactive users
Inactive user accounts are ripe for takeover by attackers. It’s wise to purge former employees or people who no longer need access to Salesforce from their user rolls. This should not be a manual process but take place automatically through integration with identity management solutions that manage the provision/de-provision of all system access for employees.
4. Integrate Salesforce with IAM solutions
Salesforce has its self-contained user management system. However, you shouldn’t let Salesforce be an identity silo, with a Salesforce admin taking care of provisioning/deprovisioning access.
Instead, integrate Salesforce with your organization’s identity and access management (IAM) solution, such as Microsoft Active Directory. This integration lets you switch Salesforce access on or off centrally when employees join or leave the company or change roles.
Allowing single sign-on (SSO) is a variant of this approach, enabling users to log in once and then automatically be signed in to Salesforce and other apps. Salesforce enables SSO through integrations with Okta, Duo, and many other SSO solutions.
5. Map organizational structure and roles to Salesforce access rules
Salesforce functionality and access privileges are hierarchical. For example, a Sales Manager can see the activities of her direct reports. It is a good practice to map your organizational structure carefully to Salesforce role definitions and privileges.
Data and Application Security
6. Implement field-level security
If you are using Apex code or Salesforce APIs, it’s wise to implement field-level security. This control forces you to decide which fields are exposed to access by the API or Apex classes. It is a countermeasure against exposing sensitive data to breaches.
7. Implement Data Loss Prevention (DLP)
Data Loss Prevention (DLP) for Salesforce can take various forms. Still, it mainly involves policies and processes like role-based access control (RBAC) and regular backups, which you can do using tools like Veeam. You should also implement data encryption as part of your DLP plan. Salesforce offers the Shield Platform Encryption feature, which encrypts data at rest on the Salesforce platform.
8. Mitigate third-party application risk
Third-party apps pose a significant threat to Salesforce, partly because it has little control over the quality of development and security of the third-party integration plugins that connect to its platform. SaaS security solutions like Suridata can scan for third-party plugins and flag integrations that may create risk in the Salesforce environment.
9. Engage in secure app development
If you’re developing applications for Salesforce using Apex or other developer tools, you should use secure development practices by leveraging approaches like the DevSecOps methodology. You should also review any AppExchange app for security before allowing anyone to implement it in your Salesforce environment.
10. Build an IP allowlist
Salesforce enables IP allowlisting natively. This countermeasure allows you to restrict the range of Internet Protocol (IP) addresses that can access Salesforce, e.g., only IP addresses in North America.
11. Focus on API security
APIs are a significant attack surface for Salesforce, so you should define and enforce security policies that reduce API-based vulnerabilities. This process may align with your organization’s existing API security and governance programs, so it may not be necessary to spin up API security just for Salesforce.
Possible countermeasures include:
Scanning for “rogue” or abandoned Salesforce API integrations.
Managing API access.
Using IAM and privileged access management (PAM) solutions.
Using API security tools to discover APIs vulnerable to injection attacks.
Monitoring & Logging
12. Create audit trails
Audit trails may not be a priority if you’re a small to medium company. However, generally, it’s helpful to create audit trails for review by stakeholders that range from executives to internal auditors and external regulators. Salesforce enables this capability natively in its Audit Trail Tab.
13. Develop and test incident response processes
Salesforce security incidents are not that uncommon, so it pays to be prepared. An incident response process for Salesforce might be the same as you have for other SaaS apps. SaaS security solutions like Suridata offer SaaS detection and response (SSDR) capabilities, so you can leverage those to automate your incident response workflows and solve vulnerabilities promptly.
Making Salesforce Secure
In a perfect world, your SaaS security measures would cover all risks affecting your Salesforce environment. However, the reality is that Salesforce is so far-reaching in the average organization and so profoundly interconnected that it embodies a unique level of risk. For this reason, you should review your Salesforce security, taking concrete steps to manage user access and permissions, protect data, and monitor Salesforce for signs of attack.
Suridata’s SaaS security solution can help you here. Suridata monitors user activities, checks for insecure configurations across all systems layers, and conducts granular vulnerability assessments. Plus, you get real-time alerts and in-depth vulnerability information to activate the correct workflows. Learn more here.
Have you ever managed to extract a file folder from a locked filing cabinet? Most likely not. That lock is a simple example of an information security control. Computers are no different, except that information security controls today are significantly more sophisticated.
And they need to be, as cyber threats are causing massive disruptions worldwide. Ransomware incidents increased by a staggering 60% from 2022 to 2023. There was also a 49% jump in overall cybercrime losses, from $6.9 billion in 2021 to $10.3 billion in 2022.
Information security controls help detect cyber threats, prevent them from damaging information assets, and correct damage if it occurs.
The 3 Principles of Information Security
Understanding information security controls must begin with understanding the purpose of information security. The term “Information Security” (InfoSec) dates back to old-school nerdiness in the era of crewcuts and pocket protectors. As prehistoric as these people may have been, they had a clear and still extremely useful way to define the purpose of InfoSec.
They came up with three core goals for information security:
Confidentiality—Information security efforts should endeavor to keep information private, ensuring that only those with permission can access a given data set.
Integrity—The information in computer systems should have integrity, meaning that users can be confident that it has not been modified or selectively deleted by accident or malicious act.
Availability—Information should be available to users to the greatest extent possible, ideally 100% of the time.
The three goals are known as the “CIA Triad.” They underpin nearly every aspect of cybersecurity and form the foundation for information security controls. Today, the CIA Triad applies to software, data storage, networks, cloud-based systems, SaaS security, and virtually any other digital asset in cyberspace.
What are Information Security Controls
Information security control is a safeguard that realizes some aspects of the CIA Triad. For confidentiality, for example, you might implement a control that uses an identity and access management (IAM) system to block unauthorized users from data you want to keep confidential.
Some organizations set up their controls under a control framework, such as the National Institute of Standards (NIST) Cybersecurity Framework (NIST CSF) or ISO 27001. These frameworks suggest dozens of controls, and consultancies and auditors work with organizations in their implementation.
Each information security control has a “Control Objective,” which states the purpose of the control. For example, NIST CSF has a control for “Identity Management and Access Control (PR.AC),” whose objective holds that “Access to physical and logical assets and associated facilities is limited to authorized users, processes, and devices, and is managed consistent with the assessed risk of unauthorized access.”
Following the control objective, each control has a set of control activities that realize the objective. PR:AC, for instance, has six sub-categories of control activity that support fulfilling the control objective. One of these sub-categories is PR.AC-1, which requires an organization to deploy a solution so that “Identities and credentials are issued, managed, revoked, and audited for authorized devices, users, and processes.” In practice, this means some sort of IAM system.
It may seem overly elaborate to require a control objective and a list of control activities to operationalize the CIA Triad. A small organization might not need to go through the whole hassle. However, working off an information security controls framework is beneficial for most organizations. The framework provides a coherent and complete approach to implementing controls that make the CIA Triad do its job of protecting your data.
Without the coherence and thoroughness of a framework and its associated objectives and activities, you’ll likely have control gaps that create risk exposure.
10 Types of Information Security Controls
Getting more granular, there are three categories of control functions: Preventive, detective, and corrective. These control functions deal with preventing attacks on information assets, detecting attacks, and correcting the effects of attacks, respectively. Controls also vary by type, with some controls being physical, such as locks; technical, such as web application firewalls; and administrative, such as data access policies.
Effective cybersecurity posture comes from deploying a well-thought-through and balanced mix of these functions and types. Controls may be layered, supporting a “defense in depth” security strategy. With that in mind, here are ten types of information security controls that are common across the three control functions:
Preventative Controls
1. Access controls
Access controls prevent the wrong people from accessing data, networks, SaaS apps, and other system components. They are crucial because unauthorized access is one of the most common cyber risks. Many IAM tools can help you build a robust identity governance framework and implement comprehensive access controls such as multi-factor authentication (MFA) or behavior analytics.
2. SaaS security controls
SaaS apps are new territory for information security controls, mainly because traditional controls don’t cover SaaS well. For example, you can have a practical set of access controls for your network, but they won’t do much to prevent a malicious actor from logging into a SaaS app.
SaaS apps have their own built-in access management features. These apps will remain vulnerable unless you deploy specialized SaaS security tools that map the established access control list to SaaS.
Other preventive cyber security controls specific to SaaS include monitoring and remediating misconfigured SaaS apps exposed to threats and policy-based controls that govern who has administrative back-end access to SaaS apps.
3. Data protection controls
Cyber attackers tend to be after data to steal, spy on, or ransom it. Data protection controls like data monitoring and data encryption are, therefore, among the more critical information security controls in force at an organization. Data encryption, for instance, makes data unusable to attackers, preventing the worst outcome of a data breach.
Ransomware protections, such as immutable backups and logical air gaps, are preventive data protection controls. They make it harder for a ransomware attacker to achieve his objective of encrypting data and ransoming it.
4. Patch management
Some of the worst cyber attacks exploit vulnerabilities that could have been fixed with software patches but weren’t. A patch management regimen is a preventive policy-based control to reduce the likelihood of this outcome. It is usually implemented through a combination of processes and tools. For example, the policy may require you to apply all software patches as they are announced. In practice, this encompasses patch testing and patching prioritization.
Detective Controls
5. Intrusion detection controls
Intrusion detection controls aim to discover when an attacker is trying to gain unauthorized entry into a system—and then alert the right people or even mitigate the threat automatically. Many intrusion detection systems (IDSs) can fulfill the control objective, though some suffer from false positives and excessive alerting. The new generation of IDSs uses AI to improve accuracy by flagging only actual intrusion attempts.
6. Anomalies and events detection controls
It may be possible to detect an attack by analyzing events occurring in the IT estate and flagging anomalies for investigation. For example, suppose a user located in the United States appears to be logging into a SaaS app from Europe. In that case, that anomaly might indicate that an attack is underway.
Detective controls in this category may monitor device logs (think of network firewalls or endpoints) and flag suspicious activities for security analysts to examine. Some advanced threat detection tools will automatically mitigate the threats they detect, such as quarantining a device.
7. Vulnerability and misconfiguration scanning
Devices and applications must be configured for security. For example, you can “harden” a server by limiting who can install new software. It is very possible, unfortunately, for a device or application to be misconfigured, making it vulnerable to threats.
This is a particular concern with SaaS because each SaaS app has its security configurations, and in many cases, individual end users can change these configurations. They can, for example, make data accessible to anyone, not just employees of the organization.
SaaS security platforms like Suridata can facilitate the implementation of this control by enabling system owners to scan multiple SaaS apps and detect security misconfiguration vulnerabilities that expose the apps to risk.
Corrective Controls
8. Incident response plans
An incident response plan is a corrective control that counteracts the impact of a cybersecurity incident. Like most corrective controls, it works in tandem with a detective control. When a detective control signals that an incident has occurred, that triggers the incident response plan, which corrects the incident by quarantining compromised endpoints, reinstalling infected software, or notifying key stakeholders.
9. Disaster recovery plans
Disaster recovery plans are a vital part of any cyber threat intelligence framework. The control objective of disaster recovery (DR) plans is to support the availability of systems and data. A good DR plan restores data and system functionality in a cyberattack or any other event that causes an outage.
10. Data backups
A data backup serves as a corrective control in case of a data breach or outage affecting data availability. By backing up data and providing the ability to restore it in the wake of an attack, the control mitigates the effect of the breach and realizes the control objective of data availability.
Getting The CIA Triad Under Control, Everywhere
Information security controls are essential for preventing, detecting, and correcting security incidents that adversely affect data and systems’ confidentiality, integrity, and availability. Whether you implement them ad hoc or endeavor to operationalize a large-scale controls framework like NIST CSF, you will always be dealing with the same issues: What is the control objective, and what activities will it take to attain it?
SaaS can be a challenging environment for information security controls. Apps are freestanding and delivered by external entities. Individual end users may be able to set their controls—often at odds with organizational security policy and even common sense.
New SaaS security solutions like Suridata can improve this risky setup. By monitoring the entire SaaS environment and flagging data at risk and insecure misconfigurations, they provide the basis for defining and implementing information security controls for SaaS apps. Learn more about Suridata.
If your organization is like most, you probably use over a hundred SaaS applications. SaaS apps offer convenience, instant access to pre-built and easily deployable features, and flexibility to meet changing business needs. However, the more SaaS apps you connect to, the bigger your security gaps.
58% of organizations estimate their current SaaS security solutions only cover 50% or less of their SaaS applications. Even if you have robust controls and cybersecurity technologies on-premises and in the cloud, they are unlikely to cover the usage of your SaaS apps.
What is SaaS security?
SaaS security comprises a collection of controls, policies, and practices to protect SaaS data and systems. Each SaaS app typically has its own security controls, many of which end users can configure. This flexibility opens the door to various security gaps and misconfigurations, which can be used to launch cyberattacks. This challenge is exacerbated by the fact that users can access SaaS apps from devices anywhere in the world.
Until recently, companies have been able to live with the SaaS tradeoff: you get the benefits of SaaS, but security can be a troubling afterthought. However, rising SaaS threats like ransomware, Cross-Site Scripting (XSS), and Man-in-the-Middle (MitM) attacks are pressuring IT managers to improve their SaaS security strategy.
SaaS security in 2024: The top challenges
1. Shadow SaaS
Shadow SaaS, a subsegment of Shadow IT, refers to employees using SaaS apps without IT approval or awareness. For example, employees may set up a SaaS account using a credit card and add corporate data to that app without notifying the IT department or security team.
It’s a highly problematic occurrence, as it can lead to data breaches, loss of confidential data, and exposure to cyber-attacks. Plus, because the relevant teams are unaware of the usage of this app, response to potential vulnerabilities may be delayed.
2. Insecure SaaS configurations
Each SaaS app is hosted and managed by a separate company, so it can be configured separately. The end user can often choose how to configure their security settings. Without appropriate security training, employees may unintentionally set up the wrong configurations and open doors to data exposure or unauthorized access. Other misconfiguration risks include not updating the app’s default settings, permitting easy-to-guess passwords, and not requiring Multi-Factor Authentication (MFA).
3. Lack of visibility into third-party risks
SaaS apps are often integrated with third-party systems, including other SaaS apps. These integrations, typically done with plugins, are a significant source of SaaS risk. Malicious actors can use vulnerable plugins to penetrate SaaS apps, steal data, or damage the system.
Gaining complete visibility into your vendor’s systems and other connected third parties is challenging. However, companies can remediate this lack of transparency by implementing robust third-party risk management. This strategy ensures vendors have the tools and processes to restrict user access, protect user data, and comply with relevant regulations such as GDPR, SOX, HIPAA, or CCPA.
4. Insider threats
Employees can pose a threat to your SaaS security as they can to other digital assets. The difference is that with SaaS, it can be much harder to track who is doing what, and insiders can exfiltrate data before anyone finds out. Sometimes, the threat is accidental, such as when an employee moves data to a SaaS app without realizing it’s against the company’s policy. In more extreme and infrequent cases, disgruntled employees may misuse their access to seek revenge and sabotage systems.
5. Potential compliance violations
If your organization doesn’t have visibility into corporate data stored on SaaS apps, it risks violating regulations and industry frameworks that protect consumer privacy. Some of the most notable regulations, like GDPR, CPPA, and PIPEDA, require proof that you have the security tools and systems to protect user data.
6. Poor access control management (IAM)
Without centralized identity and access management (IAM), SaaS users log into each app’s separate access control system independently. You can quickly have a situation where a hundred SaaS apps comprise a hundred different access management systems, and it becomes impossible to know who has access to what. One of many risks inherent in this scenario is unintentionally enabling former employees to still log in to your apps and get their hands on confidential data.
7 Essential SaaS Security Best Practices
1. Implement Centralized User Authentication and Access Controls
Your SaaS security posture will improve dramatically if you can control who has access to each SaaS app and what privileges they have once logged into it. Integrating your IAM solution into each SaaS app will enable you to build a unified identity governance framework and centrally define access rights and privileges. For example, you could integrate Microsoft Active Directory with Salesforce.com, Workday, or HubSpot. Alternatively, you could deploy a purpose-built solution.
2. Scan (and train) for Shadow SaaS
Shadow SaaS creates risk exposure across multiple dimensions. Employees may place sensitive data on SaaS apps without proper controls, or they may not set up adequate security protections, like MFA and data encryption. Worst of all, no one in IT or security knows about it.
Training can help reduce the potential for Shadow SaaS to occur. While it isn’t a bulletproof solution, it is wise to make employees aware that setting up their own SaaS accounts is a bad practice. Continuously scanning for Shadow SaaS is an even better solution. Using specialized tools like the Suridata SaaS security platform, you can monitor endpoints for activities that reveal the presence of Shadow SaaS accounts. The platform can then alert the right people and recommend remediations.
3. Include SaaS in Your Security Incident Response and Recovery Plans
Suridata’s research revealed that 88% of organizations have had a SaaS security incident. Even if you’re part of the lucky 12%, you should still adopt preventative cybersecurity controls and ensure you can respond and recover from a security incident should it occur.
The Security Operations Center (SOC) team should create an incident response playbook for a SaaS security incident. The playbook, which could be entered into a Security Orchestration Automation and Response (SOAR) solution, might include steps like isolating affected endpoints, contacting the SaaS provider to determine the cause of the incident, tracking the vendor’s recovery efforts, and notifying internal stakeholders like your legal department.
4. Conduct SaaS Vendor Security Assessments
Subscribing to a SaaS app is more than just a technology integration- it’s a business relationship. You’re working minute by minute with another company, often with your most critical information assets at stake. You want to work with the right SaaS vendors and trust them to protect your assets.
For this reason, it’s a best practice to conduct a SaaS vendor security assessment as part of the procurement process. You could ask the vendor for specifics on securing their data centers and infrastructure, encryption and MFA options, or whether they have passed a SOC2 audit and other key certifications.
5. Vet Your Third-Party SaaS Integration Plugins
Third-party integration plugins are a potential source of vulnerability, so it’s wise to vet these plugins for security. You will want to look at factors like the level of support, security features like data encryption, and data storage and retention practices.
Sometimes, a software company releases a SaaS plugin but then abandons it. Eventually, this plugin will get outdated and insecure. Even just looking at a plugin’s age may inform your decision on whether or not you should integrate it into your software. If a new version of this plugin hasn’t come out in about three years, it may be best to raise some questions and consider your decision further.
6. Continuously Monitor Your Entire SaaS Environment
One of the biggest problems in SaaS security is a lack of visibility into what’s happening across multiple SaaS apps. A vital best practice is to implement continuous monitoring of the entire SaaS environment. This might mean monitoring user sessions to detect suspicious activities and verifying that third-party integration plugins are secure or that security configurations are not creating risk exposure.
Due to the extensibility of your SaaS apps, it’s virtually impossible to monitor this activity manually. Therefore, you should consider using a comprehensive SSPM platform or equivalent.
7. Map SaaS to Your Compliance Programs
SaaS must be part of any compliance process involving financial transactions, health information, and privacy. Compliance teams should know where SaaS apps store data relevant to regulations and industry compliance frameworks like PCI-DSS.
SaaS system owners also need to understand where their apps intersect with compliance. For example, a SaaS-based Enterprise Resource Planning (ERP) application may be subject to rules regarding financial controls, which prevent the same user from issuing a purchase order and approving a payment to that vendor. In that case, the SaaS owner must show that user permissions on the app adhere to such controls.
Getting Started in Securing Your SaaS Apps
The risks of a data breach or comparably bad incident are too high for SaaS security to be neglected. Centralizing user authentication and access controls, continuously monitoring the entire SaaS environment, and protecting your SaaS data through encryption are just some of the steps you can take today to fortify your SaaS security posture.
Tools like Suridata can help you gain visibility across all your SaaS apps, enabling you to spot hidden misconfigurations and vulnerabilities and address these in real-time. By automating SaaS monitoring, threat detection, and response, you can take a proactive approach to SaaS security and develop a sustainable and efficient remediation plan. Request a demo here.
Hackers are all diabolical geniuses, clad in hoodies, who sneak past our best defenses like ninjas… or not. Their job is actually a bit dull. Most hacking involves automated software looking for easy break-ins enabled by security misconfigurations.
11% of successful breaches result from cloud misconfigurations. These mishaps are not just widespread but deceptively dangerous. Based on OWASP’s Top 10, “security misconfiguration” is the 5th most critical vulnerability worldwide, having moved up from 6th place in the previous edition.
It’s not just about spotting misconfigurations but being quick at spotting them. With hackers taking as little as one minute to exploit a weakness, your team can’t afford to take weeks to discover and respond to it (if it ever discovers it at all).
What is a security misconfiguration vulnerability?
A security misconfiguration vulnerability is any system setting that causes exposure to cyber threats.It often originates from a lack of security controls and processes. For instance, it may be caused by not switching on recommended app security settings, enabling unnecessary features like legacy encryption protocols, incomplete hardening of servers, or allowing default passwords. These vulnerabilities can affect operating systems, web servers, databases, applications, and cloud services.
SaaS applications present a distinct challenge when it comes to misconfiguration risks. For example, a SaaS system user might be granted temporary privileged (administrative) access, but the person who added the privilege forgets to revoke it. If a malicious actor compromises that user’s account, he now has administrative access. The average company uses over a hundred SaaS apps, so the attack surface is vast.
The impact of security misconfiguration vulnerability attacks
Attacks that exploit security misconfiguration vulnerabilities can take many forms. Ransomware, data breaches and exfiltration, impersonation of employees, and phishing attacks are among the most impactful.
Compliance problems are also a related risk. If a malicious actor can access and exfiltrate consumers’ Personal Identifiable Information (PII), that could result in penalties and legal liability for violating privacy laws such as GDPR and CCPA.
Common challenges in spotting security misconfigurations
Spotting security misconfigurations is inherently challenging because these are often easy-to-miss errors. Vulnerabilities may emerge from seemingly minor lapses like failing to require periodic password changes or allowing anonymous file shares.
Then there’s the extra complexity we’re all dealing with today—a high level of interconnectivity between apps and systems. With SaaS, this takes the form of third-party integration plugins that link SaaS apps to one another, creating risk exposure.
Configurations also tend to be dynamic, and as the landscape continually changes, it is increasingly difficult to keep up with new integrations and settings. If detailed documentation is unavailable, it becomes all the more challenging to see misconfigurations because you don’t know what the configurations should look like.
A step-by-step guide to spotting a security misconfiguration vulnerability
Step #1: Enforce security policies
The best scenario is one where you have as few security misconfiguration vulnerabilities as possible. That will mean less work spotting them and less risk. This is easier said than done, but investing in process and technology can pay dividends.
For example, adopting repeatable hardening processes for applications and servers can help you avoid misconfigurations at the outset.Automating repetitive admin tasks can also help in this regard, as can rapidly deploying software patches.
Step #2: Understand your complete architecture
Spotting misconfigurations depends on knowing what you have in your IT estate. The best practice is to develop a comprehensive architecture map and commit to keeping it updated. This map should include SaaS apps, which may integrate with productivity apps, storage systems, and other platforms.
For example, it is common for SaaS-based CRM solutions to link with order management systems. You should track all such connections. If a SaaS vendor discloses that its third-party plugin has a security problem, your architecture map will tell you where it could be causing a vulnerability.
The reality of today’s highly complex IT environments is that manual processes for detecting security misconfigurations are doomed to failure. Automated tooling is essential for scanning the entirety of the network, the SaaS landscape, applications, databases, and operating systems.
For example, a SaaS Security Posture Management (SSPM) platform like Suridata can automatically scan all your organization’s SaaS apps and identify misconfigured apps, creating risk. For example, the SSPM platform might discover that a user has decided to allow anyone in public to access files on a SaaS storage drive and automatically alert your team.
Step #4: Review IAM practices
Many insecure configurations involve Identity and Access Management (IAM). For instance, if your users can access SaaS apps without MFA, you risk hackers accessing your SaaS data with stolen credentials.
Hackers also look for Broken Access Controls (BACs). This OWASP Top 10 vulnerability results from a poorly configured web application. Specialized security tools can detect such vulnerabilities and flag them for remediation.
Most cyberattacks target data. Therefore, hackers tend to look for misconfigurations that expose data to breach. Examples include unencrypted data and Structured Query Language (SQL) messages that inadvertently reveal sensitive information.
SSPM can be helpful in this context. These tools will scan all your SaaS apps and discover where sensitive data is stored and who can access it. The results of such scans may surprise you, as your data is often stored in more places than you’re aware of, but it’s best to be surprised at this stage than later when your data has already been exploited.
Step #6: Check for unused features and default settings
An unused feature hidden from view can allow access that doesn’t conform to policies and become a breeding ground for misconfigurations. Similarly, default settings might violate any number of security policies. For instance, they could allow access by people with Gmail addresses or permit access from insecure IP addresses. It’s a good practice to audit your systems for unused features and default settings and update these as soon as possible.
Step #7: Review your SaaS vendor for compliance certifications
Your SaaS vendor’s approach to security can significantly impact your security, positively or negatively. From cryptographic failures to cross-site scripting (XSS) risks, the SaaS software can present itself with many insecure configurations. Compliance certifications such as SOC2 or PCI-DSS show that a SaaS vendor has demonstrated adherence to rigorous security frameworks. By reviewing your SaaS vendors’ compliance certifications, you can make sure you’re working with vendors that take your security seriously.
You can never stop looking for security misconfiguration vulnerabilities
Misconfigurations are a significant source of cyber risk, so you have to be able to spot them and resolve them promptly. This must be an ongoing process, however. Given the pace at which systems and connections evolve, new security misconfiguration vulnerabilities will arise continuously.
Automation is your best friend in spotting misconfiguration vulnerabilities, helping you gain visibility across all layers of your SaaS apps. Suridata combines SSPM and SSDR, enabling you not just to gain visibility over your misconfigurations but to activate the proper response workflows as soon as a misconfiguration is spotted.Book a quick demo to see how it works.
The word “compliance” is one of those migraine triggers you probably don’t want to hear at work. It sounds simple: all you must do is adhere to relevant regulations or frameworks. However, compliance is a recurring workload that usually involves auditors, certifications, and laborious processes.
SaaS compliance can be particularly challenging because you have little control over how users handle SaaS corporate data. While 43% of organizations added a new SaaS app that stores sensitive data in 2022, 25% had security violations, and 12% had to pay compliance-related penalties.
Dealing with SaaS compliance is not optional. The stakes are high, with non-compliance adding to costs and legal liability while creating risks to customer trust and brand reputation.
Compliance is about following government regulations and industry frameworks that are mandated or strongly recommended for your business. Most of the time, SaaS compliance means developing, implementing, and checking cybersecurity controls and policies that protect your and your customers’ sensitive data, such as financial and Personal Identifiable Information (PII).
SaaS compliance varies by location and industry. For instance, if you do business in the European Union, you will be bound by the EU’s General Data Protection Regulation (GDPR) and data sovereignty rules.
It sounds simple enough, but the SaaS “shared responsibility model” can complicate things. With shared responsibility, the SaaS vendor is responsible for compliance regarding its infrastructure. They have to have controls that protect your consumers’ data from breaches in their data centers.
You, on the other hand, are responsible for compliance regarding your SaaS user. If a hacker steals your SaaS login and exfiltrates consumer data, you are on the hook for this compliance violation, not your SaaS vendor.
Why Should You Care about SaaS Compliance?
A business that does not take care of SaaS compliance is at increased risk of SaaS data breaches, which can lead to loss of reputation and tarnished customer relationships. Breaches resulting from a failure to comply with frameworks can also result in fines, penalties, or litigation.
When following regulations and frameworks, avoiding an understandable but counterproductive “box-checking” mindset is wise. Best practices that strengthen SaaS data security must be instilled across the company and followed as part of the broader security culture – regulatory compliance is a by-product.
However, as the regulatory landscape grows and more SaaS apps are connected to your infrastructure, it’s easy to lose touch with the specific regulations that affect your business. A general understanding of these regulations is crucial to stay compliant.
Compliance covers different regulations and frameworks developed by governmental institutions or industry associations. Some are legally required, while others are voluntarily complied with to demonstrate trustworthiness. Below are some prominent regulations and the entities that control them.
Data Protection Regulations
Protecting consumer privacy is a priority for many governments, which have taken steps to prevent the misuse of PII. Two regulations currently predominate in this category.
GDPR
GDPR was established by the European Union (EU). It covers responsibilities for entities that handle EU citizens’ PII in the EU and European Economic Area. GDPR is under the control of the European Data Protection Board, but data protection authorities (DPAs) enforce it in each of the EU’s 27 member countries.
CCPA
The California Consumer Privacy Act (CCPA) became California state law in 2018. Implemented by the California Privacy Protection Agency (CPPA), this law dictates how companies must protect California consumers’ data. It mandates that companies (SaaS-based companies included) provide total transparency about data management and storage practices, update their privacy policies, and enable customers to opt out of the sale of their data.
Complying with security standards involves applying the specified controls and policies and passing an audit to achieve certification.
ISO/IEC 27001
The International Standards Organization (ISO) develops and promulgates the ISO 27001 international standard for information security. It is a broad standard, mandating a wide range of controls, many of which are relevant when using SaaS applications.
SOC2
Security Organization Control 2 (SOC2) is a standard that covers how organizations manage their customers’ information. SOC2 compliance is voluntary, but achieving it and passing a SOC2 audit represents a commitment to information security that many companies are eager to demonstrate. It was developed by the American Institute of CPAs (AICPA), which still oversees it today.
Industry-Specific Regulations
Some industry-specific compliance frameworks are based on laws, while others are private and theoretically voluntary but have the force of law.
PCI DSS
The Payment Card Industry Data Security Standards (PCI DSS) is a strict set of controls companies must adopt to accept payments from credit and debit cards. PCI DSS compliance requires extensive control implementation and the passing of an audit. The Payment Card Industry Security Standards Council and the industry trade group for the payment card industry oversee this standard.
HIPAA
If you are a healthcare company, you must comply with HIPAA. The Health Insurance Portability and Accountability Act (HIPAA) is an American federal law that is overseen by the Office of Civil Rights (OCR) of the Department of Health and Human Services (HHS).
How to Achieve SaaS Compliance: The Essential Guide
Understand each regulation’s applicability and draw a “heat map” for SaaS
Full compliance with all security standards is seldom possible, even for large enterprises. Too many rules and controls (and sub-controls) exist, so companies are selective about what they enforce. The best approach is to understand the applicability of a particular regulation or control to your specific business and SaaS landscape.
From there, you can narrow down the most relevant regulations based on the probability of falling out of compliance and the impact of that non-compliance on your business. Some compliance professionals call this a “heat map” that shows which regulations deserve the most time and resources. Once you’ve established your “hottest” controls related to SaaS, you can work on implementing these.
Map overall compliance and information security controls to SaaS
Your SaaS compliance efforts do not exist in a vacuum. For example, PCI DSS compliance requires companies to “prohibit direct public access between the Internet and any system component in the cardholder data environment.” This control affects all system components, not just SaaS. Determine how you comply with the regulation in general and then map that control to relevant SaaS applications.
Monitor SaaS compliance across the organization
Most organizations use dozens of SaaS apps. Not all are relevant to compliance, but for those that are, it is essential to monitor them regularly for adherence to required controls. This process may involve a formal audit or automated SaaS Security Posture Management (SSPM) platforms like Suridata.
Suridata’s SaaS security platform combines SSPM with robust detection and response capabilities, helping you monitor usage across your SaaS apps and instantly detect and respond to any vulnerability.
One of the significant advantages of SaaS risk compliance is the ease with which you can provision SaaS apps in an organization. It is a good practice to include compliance controls and safeguards into the SaaS lifecycle, such as ensuring that any SaaS app used by the company is subject to secure and compliant configurations and third-party integrations. An SSPM platform can ensure that SaaS users and system owners follow this approach.
Add SaaS to corporate data governance policies
A great deal of compliance concerns consistent, secure, and effective data management. SaaS should be no exception. If compliance with relevant regulations means encrypting customers’ PII, your SaaS apps must also do that. The same goes for retaining data for time periods determined by compliance policies and deleting data according to those policies.
Getting on the Path to SaaS Compliance
The regulatory landscape includes SaaS, even when you aren’t sure what data your SaaS environment contains. Getting SaaS compliant is difficult, but it’s not mission impossible. You probably already have the foundation for SaaS compliance in your existing controls and policies. The challenge is to port those controls easily to your SaaS apps. This is where SaaS Security platforms like Suridata can help, offering automated monitoring, policy enforcement, detailed real-time insights, and remediation suggestions for any new SaaS vulnerability. Schedule a demo to learn more.
The classic 1960s TV comedy “Get Smart” featured a fictitious spy agency called CONTROL locked in an unending battle against a devious enemy. Even at that time, when a small computer was about the size of three Coke machines, the concept of control was top of mind.
Today, as we experience a deluge of devastating cyber attacks, we are more focused than ever on the effectiveness of our cyber security controls. Indeed, the fact that 55% of organizations reported a security incident involving SaaS in the past two years reveals that SaaS controls are not working as well as they could be.
Every successful cyber attack is, after all, the result of a control failure. It could be a deficient control or one that didn’t exist in the first place when it should have. The growing use of cloud computing and SaaS applications also challenges the traditional approach to information security controls, making these increasingly difficult to map out and implement.
What Are Cyber Security Controls in SaaS?
Generally, a control is a safeguard that reduces risk to an asset. Every control has an objective and an activity related to it. For instance, a lock on a cash register aims to reduce the risk of losing cash to a thief, and the “activity” encompasses purchasing the lock, installing it, and locking it.
Cyber controls in SaaS are no different – they detect or prevent threats like ransomware attacks from impacting a SaaS asset and its data. Controls are essential in any digital environment but critical for SaaS. The average company uses more than 100 SaaS apps, each with its security options—many of which are at the discretion of end users. The potential for a breach is high without controls that can mitigate cyber risk.
Cyber controls vary in design and execution, but we can divide them into three main categories:
Administrative controls – Organizational policies that help secure how your users access SaaS data. They include Identity Governance, such as managing identities’ lifecycles, reviewing access controls, and monitoring user behavior.
Technical controls – Deployment of technologies and security tools to protect SaaS data, including implementing encryption and Web Application Firewalls (WAF).
Physical controls – Security controls that protect the physical infrastructure that hosts software. In the case of SaaS, your SaaS vendor is responsible for implementing controls such as fences and locks to secure its hosting infrastructure.
The 7 Must-Have Cyber Security Controls You Can’t Neglect
A large organization could employ hundreds or thousands of controls in its IT estate, so they can quickly get overwhelming. A handful of critical controls are deemed vital in SaaS, as they meet the unique security risks affecting SaaS apps.
1. A Software Asset Inventory that Includes SaaS
Building and maintaining a complete inventory of software assets helps prevent attacks on neglected or invisible software. These can include unknown software assets with out-of-date security settings, untracked user accounts due to staff turnover, lack of follow-through on policies and procedures, or shadow IT.
SaaS apps can be challenging to inventory without the proper tooling. Because they are hosted externally by third parties, knowing someone has set up a SaaS may be impossible if they didn’t inform the IT department. A SaaS Security Posture Management (SSPM) platform like Suridata can scan for SaaS apps and create an inventory of SaaS assets to support this control.
2. Access Controls that Leverage MFA and Apply the Least Privilege Principle
Unauthorized access to a SaaS app can cause severe data breaches and operational disruption. For instance, a hacker can use stolen credentials to log into a customer relationship management (CRM) system and exfiltrate the customer list or corrupt it to become unusable.
Tighter access controls and multi-factor authentication (MFA) implementation can help prevent unauthorized access to SaaS apps. Ensure you also enact a policy of least privilege to reduce the risk of an attacker “moving laterally” through different sections of an application once they have logged in.
MFA and least privilege should be part of a broader Identity and Access Management (IAM) program to achieve the control objective effectively. This may involve the integration of the MFA solution with the company’s IAM platform and related Identity Governance systems.
Malicious actors are constantly looking for insecurely configured SaaS apps that they can exploit. Think of a SaaS storage app set to allow anyone to access the files without being authenticated – misconfiguration vulnerabilities like this are liquid gold for attackers.
You need to monitor SaaS security configurations continuously, flag insecure setups, and alert admins to remediate them. But with a hundred SaaS apps in use and potentially thousands of end users, inspecting security configurations must be done with an automated tool.
4. Data Protection Controls
Encrypting data in transit and at rest and backing it up can prevent data breaches or, at the very least, reduce their impact. However, these controls require security managers to know where all their data is stored. This can be a challenge in SaaS, as the organization hosts the data externally.
For example, how would you know that your order management SaaS app was storing customers’ Personal Identifiable Information (PII), which would cause a compliance problem if it was breached? You need an automated data scanning tool that can identify the location of data and establish who has access to it.
5. Develop and Test an Incident Response Process
Cyber attacks often have extensive, costly, and potentially irreversible business impacts. Even if your data isn’t stolen, unplanned downtime can negatively affect customer relationships and damage your reputation. Developing and testing an incident response process enables rapid recovery of SaaS apps from a cyber incident, ensuring no further damage is done.
Responding to SaaS cyber incidents works best when you have immediate, detailed information about the nature of the threat and the status of your SaaS environment. A SSPM platform can provide the basis for forming an effective incident response plan.
6. Continuous Monitoring and Prioritization with SSPM
To have your SaaS apps under control, you need to achieve comprehensive, real-time awareness of the security status of all apps in your ecosystem. Furthermore, you must be able to react quickly to detected threats and vulnerabilities.
Ensure you leverage the continuous monitoring capability of an SSPM platform to achieve constant, thorough, and up-to-date security awareness of all SaaS apps. This control needs to be coupled with a prioritization of alerts and some automation of remediation processes.
Continuous monitoring can create a too-long list of vulnerabilities, and not all will be equally serious. Some might even be irrelevant to SaaS security. An effective SSPM platform will include a priority list of vulnerabilities to address and automatically remediate as many as possible—referring only those needing human attention to security managers.
7. Third-Party Security Risk Management
Third-party integrations can be a significant source of risk exposure for SaaS apps. Establish a process to inspect third-party integrations, such as those executed with plugins. Identify insecure plugins and integrations and alert critical stakeholders to trigger remediations.
You will need an automated solution to do the groundwork for you, as you’ll likely have an extensive list of third-party integrations and plugins to monitor. Suridata monitors and analyzes all third-party integrations and identifies security problems, such as unsupported plugins that have become insecure or that enable unknown users to access SaaS apps.
Getting Started with Your Must-Have Cyber Security Controls
If you’re neglecting the seven SaaS controls highlighted in this article, now would be a good time to implement them. The risks are too significant to ignore and will continue to grow as your business grows. Even if your team has the basics covered, you should equip them with a comprehensive tool that automates all the monitoring, detection, and remediation processes to protect your entire SaaS arsenal. Purpose-built solutions like Suridata combine SSPM with robust SaaS Security Detection and Response (SSDR) capabilities, helping you get to the bottom of every SaaS vulnerability without operational overload. Learn more here.
