The Top 10 SaaS Data Access Risks

Originally published by DoControl here.

Written by Corey O'Connor, DoControl.

Modern businesses increasingly rely on SaaS applications like Google Drive, Box, Dropbox, and Slack to facilitate daily exchanges of sensitive data and files. Although these tools allow for real-time collaboration that drives business enablement, their lack of granular access and security controls presents serious material risks for the businesses that use them. This blog outlines ten of the most significant risks associated with unmanageable data access within SaaS applications that your organization should be aware of.

Here's our top 10 list, with explanations below. Let us know what you think!

1. Internal and external sharing permissions remain active indefinitely – even after IDP deprovisioning.

Files stored in SaaS applications retain their sharing permissions indefinitely. For example, third-party vendors and internal employees will retain access to sensitive documents – and the ability to download or share – via old sharing links, which remain active unless permissions are manually changed. It’s not commonplace for employees to retroactively remove permissions for external collaborators when access is no longer needed, and even IDP solutions cannot remove data access permissions across all SaaS apps, meaning access to information stored in SaaS applications often remains long after it is needed. This is not only bad business practice – it significantly increases the amount of sensitive data vulnerable to exfiltration by malicious actors.

‍2. Personally Identifiable Information (PII) uploaded to overexposed locations remains overexposed indefinitely.

Any personal information shared to public locations within a company – such as public Slack channels, shared Drive folders, or Salesforce opportunities – will remain exposed forever, allowing anyone with high-level internal access to see, download or otherwise use the information. Traditional data loss prevention (DLP) solutions’ PII scanning tools do not effectively extend to data stored within SaaS applications, so PII shared in these locations must be manually discovered and deleted – an undertaking for which most security teams do not have time or resources.

‍3. Third-party collaborators can share your data with fourth-party collaborators who have never passed any security risk assessments.

Third-party collaborators with access to your data hosted within SaaS applications can share it with fourth parties such as their own vendors, exposing your data to unauthorized personnel who have not passed any security risk assessments. It’s extremely complex to implement consistent policies that prevent fourth-party sharing across all SaaS applications, so this added layer of access often goes unnoticed and unremediated.

‍4. Employees share encryption keys in open internal channels, increasing the likelihood of unauthorized access to production environments.

Technical personnel may share encryption codes such as AWS keys via SaaS communication streams – such as public Slack channels or Microsoft Teams chats – to aid collaboration during the development process. It’s impossible to prevent this kind of sharing using only the controls native to each SaaS application, and Dev teams often use these channels for convenience even if it is strongly discouraged. Individual SaaS applications offer no straightforward means for targeting these privileged credentials for removal, which creates opportunities for unauthorized personnel to find them and access the production environment.

‍5. Data-sharing restrictions are inconsistent across different SaaS applications.

While many SaaS applications do have built-in security controls and features to help users proactively manage access, the depth and granularity of each app’s controls vary greatly, which makes managing and scaling a strong security policy across a large, cloud-first organization incredibly difficult.

‍6. Employees and third-party collaborators share data with personal email accounts, creating overexposure and increased risk of account takeover attacks.

Basic sharing permissions within SaaS collaboration apps allow for added sharing with fourth-parties, such as personal email accounts. This gives anyone with access to sensitive data the freedom to exfiltrate it to personal accounts for their own unmonitored use. To make matters worse, most personal emails will not have security measures like multi-factor authentication (MFA) enabled, which further increases exposure.

‍7. Departing employees can exfiltrate company data to personal email accounts, a phenomenon that is incredibly difficult to detect and prevent at enterprise scale.

When HR managers initiate employment status changes for departing employees, security teams should be alerted so they can closely monitor these high-risk individuals for insider threats – but HR and security platforms are often disconnected in a way that makes this process overly complex. Without a centralized view of user activity across all SaaS applications, or the ability to automate any part of the permissions-cleanup process, data exfiltration by leaving employees is difficult to prevent, especially for large organizations.

‍8. Security teams can’t independently distinguish high-risk activity from employees’ regular duties around SaaS-hosted data.

Security teams are inundated with alerts for suspicious user activity across the SaaS environment, but lack the business context to quickly determine which activity presents actual risk. Security teams must manually query internal and external users on a regular basis to understand their business needs and adjust access accordingly. This process creates unnecessary interactions between security teams and business users and increases mean time-to-repair (MTTR) for actual threats to the business.

‍9. Employees enable data access to risky third-party OAuth apps.

OAuth connections provide SaaS applications with access tokens that authorize specific account information to be shared without exposing the user's password. While OAuth connections provide a convenient intermediary between applications and end users, they can also be used in phishing campaigns: Hackers create OAuth URLs that appear legitimate, but are actually modified to produce errors in the authentication flow and redirect to landing pages that attempt to steal login credentials.

When users are prompted to approve an OAuth connection, they often accept before closely examining the URL or reviewing the details in the prompt. It’s difficult to implement security policies that prevent users from authorizing OAuth connections across all the disparate SaaS applications used by the business. This creates an attractive landscape for attackers to conduct supply chain-based attacks by breaching trusted third-party apps.

‍10. Employees set internal access permissions to “anyone with a link” and paste links in overexposed locations.

When employees create new documents in SaaS applications such as Google Drive or DropBox, they often set permissions so that “anyone with a link” can view, edit or share. This is a convenient option for group collaboration, but when links are shared via open internal channels (i.e public Slack channels accessible to all employees), these entry points to sensitive data remain open and overexposed indefinitely. Without a way to auto-expire sharing links, there is no way to ensure they won’t be found and used by unauthorized personnel.