.jpg)
This is the seventh and final entry in my blog series based on the 2023 State of SaaS Security Report. The first introduced the report. The second focused on SaaS breaches. The third focused on data security. The fourth opined on SaaS identities. The fifth explores SaaS misconfigurations. The sixth surfaced SaaS integration insights. Finally, this one brings everything together with our SaaS security recommendations.
Check out the 2023 State of SaaS Security Report
Throughout this series, we’ve written about the importance of SaaS security. Nearly every business has critical SaaS apps today. SaaS-related breaches are real and increasing in frequency. We dove deep into the SaaS challenges related to data security, identities, misconfigurations, and integrations. While we’ve included some recommendations in each of these six prior posts, this post will focus entirely on recommendations, bringing all of our advice together into one comprehensive post.
1. SaaS-to-SaaS Integrations
We’ll start with integrations - one of the most eye-opening areas in SaaS security. Most organizations suspect there will be some integrations they’re unaware of, but are consistently surprised when they see the actual volume of user-consented integrations - often 10x more than expected.
Once this initial batch of unfamiliar integrations has been reviewed and acted upon, we recommend reviewing new integrations as employees onboard them. In line with our philosophy to enable the business, we propose quickly reviewing new integrations and understanding the business case after the integration has been enabled. The concern is that the old method of requiring business justification before allowing employees to create integrations had a chilling effect on using integrations altogether, preventing potential productivity gains.
When reviewing new integrations, consider vendor reputation. Ensure the permissions, roles, or scopes requested by the integration match what the integrations need, or is the vendor requesting more than they need? Also, consider configuration and monitoring options. Is it possible to use this integration securely, and within regulatory requirements? Can critical events be logged and monitored? Finally, request business justification from the consenting employee, to understand why this integration is important to them and/or the business.
Our final integration recommendation is to regularly remove any integrations that aren’t being used, are unnecessary, or cannot be used safely, or in line with compliance or regulatory requirements. Also, ensure these integrations only have the privileges they require. Remove any extraneous privileges, or create custom roles for these integrations to limit their access to the SaaS application they’re connected to.
2. SaaS Identities and Permissions
With integrations under control, we have a few recommendations related to identities. Review accounts with high levels of privilege or administrative access. Reduce these privileges when necessary, and ensure roles are correct. For example, when someone moves jobs within an organization, often their access privileges and/or role should change as well.
This is an excellent opportunity to ask questions like, “do we really need 147 global admins?” When working with our customers, we see no magic number for administrator roles. In some cases, we see a ratio of 1 admin per 25 employees, and in others, the ratio is 1 for every 100.
A recurring theme in our recommendations revolves around closed-loop processes or lifecycles. For example, deactivating SaaS accounts should be part of offboarding an employee who has left the company. Investigate idle accounts, particularly if the employee isn’t on vacation and doesn’t otherwise have a reason to not generate activity on company systems.
Finally, a centralized identity provider (IdP) can help manage security settings by offloading them. Instead of relying on a SaaS application’s native identity security controls (like multifactor authentication), using SAML or other forms of single-sign on, allow these authentication requirements to be pushed off to an IdP such as Okta, OneLogin, or Microsoft Entra ID.
3. External SaaS Data Shares
Sharing a document prior to a meeting is one of the most common external data-sharing scenarios. Having access to this document is critical for the attendees of that meeting. It’s unlikely, however, that anyone thinks to unshare the document once the meeting concludes.
On one hand, hundreds of thousands of external data shares are evidence that an organization is thriving and getting productivity gains out of its SaaS file storage solution. On the other hand, if 90% of those external data shares haven’t been accessed in over 90 days (which is the average, according to our research), that’s evidence of a data-sharing lifecycle problem. If the shares aren’t being used, they’re not providing any value to the organization. We recommend unsharing these unused data shares to reduce this potential attack surface.
Another method of sharing external data is by creating email forwarding rules. This is a common tactic used by attackers to exfiltrate sensitive company data. Look out for any email forwarding rules pointing to personal email accounts, or email accounts on domains or providers commonly used by attackers or in countries that your company doesn’t do business in.
4. SaaS Misconfigurations and Compliance
Every SaaS application is unique. Log formats differ. APIs differ. The information available varies. The customer’s ability to manage, monitor, and configure the service varies. Some charge extra for security features. Others include them in the base price.
To secure SaaS, it’s necessary to learn each platform and understand all the features, possible settings, and configurations (that’s a lot to ask a security team, which is one of the reasons we built the Valence SaaS Security Platform and its SSPM functionality). Aligning them to best practices, standards, and compliance requirements such as ISO, NIST or CIS, or company policy adds to this challenge. Not all SaaS configurations have security implications, and not all security options have compliance significance.
Even when configurations have been investigated and corrected to the most secure options, drift can happen. We recommend regularly monitoring for configuration drift and understanding the reasons behind changes.
5. SaaS Threat Detection
Threat detection is one of the trickiest security goals to accomplish in the world of SaaS, for a variety of reasons. While APIs make it easy to retrieve information from the SaaS vendor, or implement changes, sometimes the necessary logs or events for threat detection aren’t enabled or monitored. Since storage incurs a cost for SaaS vendors, logs may be disabled by default, or stored for a limited amount of time.
In addition to each SaaS vendor being unique, so is each customer. This complicates threat detection, as something that might be totally normal for one customer, could be a critical event for another. It’s difficult to avoid having to customize threat detection for each SaaS platform, scenario, and customer.
We recommend ensuring SaaS logs are enabled, monitored, and stored for an appropriate period of time. It’s also necessary to understand how the business is using these applications. Something that might look suspicious to a SOC analyst, could be the result of a totally normal, legitimate job function. Finally, we recommend studying SaaS-related breaches, data leaks, and incidents. As attackers turn more attention to SaaS, it is necessary to understand their attack tools and methods in order to spot them.
Wrap Up
Thus concludes our seven-part series expanding on our 2023 State of SaaS Security Report! We hope you’ve enjoyed this deeper dive into the topics explored by this report, as these blogs have served as a sort of ‘director’s commentary’. Check out the full report for more details, real-world examples of SaaS security challenges, and a more concise, 14-point checklist of recommendations from the Valence Threat Labs team.
