The concept of zero trust – as a way to improve the security of and access to an organization’s network, systems, and data – has gained traction in recent years. The basic premise is that no user or device should be trusted by default and all access to data and resources should be granted based on critical business need – and such need should be continuously verified.
While zero trust can be an effective approach to security, it can also present some challenges, particularly when it comes to implementing it for software as a service (SaaS) due to the fast pace of its adoption, distributed ownership of SaaS applications across organizations, and the shared responsibility model between a SaaS vendor and a customer.
The traditional approach to SaaS security challenges has been to use a cloud access security broker (CASB) and/or identity provider (IdP) to manage access to SaaS applications. IdPs are used by many organizations to centrally authenticate human users into an application or system, enforcing many strong authentication methods.
Some organizations also add a CASB to sit between users and the services they access, enforcing granular security policies and controls to ensure that only authorized users can access specific resources, and to protect against malicious activity. These combined solutions help to simplify the implementation of zero trust principles to SaaS applications such as Microsoft 365, Salesforce, ServiceNow and Workday, and make it easier to manage access and security at the points of both authentication and authorization.
CASBs and IdPs alone or in tandem, however, are still inadequate since SaaS applications have become increasingly more complex, including collaboration and automation elements that could “break” the zero trust model, such as:
- Third-party integrations like OAuth, APIs and low/no-code – non-human identities that are not governed by existing IdP solutions and grant direct programmatic access for third-party vendors to core SaaS applications, without applying strong human authentication methods
- External data sharing settings that enable the sharing of files with external collaborators in OneDrive, SharePoint, Google Drive, Box, Dropbox, etc., the forwarding of emails to external users and publicly sharing sensitive data repositories (i.e., source code repositories)
- External user identities that allow collaboration with contractors, vendors and other external parties which enable users to access business-critical resources from unmanaged devices without enforcing the corporate identity provider and security guardrails
Additionally, SaaS applications are much more complex than traditional applications and they allow business users autonomy to manage them without IT in a democratized model. These SaaS applications encourage users to perform what in the past would have been considered administrative actions, resulting in potential misconfigurations.
Each SaaS application has its own permission model and set of complex configurations, most of them can impact the security posture of the SaaS application. This almost makes it easy for users to mistakenly configure SaaS applications to break the zero trust model. For example, in many organizations Salesforce administrators create local users in their tenant to enable automation scripts and service accounts, which allow them to improve business processes. If such accounts aren’t properly configured, they may access Salesforce directly, without authenticating through the IdP, hence bypassing a critical security control.
Finally, security teams lack control over the underlying infrastructure of their SaaS application. When using on-prem systems, an organization has complete control over the hardware, software, and network configuration, which makes it easier to implement security controls and enforce policies. Due to the shared responsibility model for securing SaaS services, the infrastructure is managed by the service provider, which can make it more difficult if not impossible to apply zero trust principles to it. Plus, without visibility into who these security vendors are, security teams don’t even have an opportunity to vet their security posture. This limits security teams to managing configurations that were enabled by the SaaS vendor, which in many cases may not be sufficient to enforce the desired policies.
What is the key to building a scalable zero trust model for the modern SaaS?
Engagement and collaboration with the business users who adopt, manage and use SaaS applications on a daily basis. By working closely with them, security teams can gain visibility into all applications across their organization’s diverse and complex SaaS environment and ensure zero trust security guardrails are in place without disrupting either the pace of adopting and configuring SaaS applications or the pace of the business itself.
Without such engagement, security teams lack critical context into the day-to-day business use of these SaaS applications that is critical to securing SaaS services in a way that doesn’t disrupt the business. With it, they can gain valuable insights from business users, educate the entire organization on SaaS security best practices, and extend security resources to the entire organization by drawing those outside of the security team into SaaS security workflows and processes.