Who Has Control: The SaaS App Admin Paradox

Imagine this: a company-wide lockout to the company CRM, like Salesforce, because the organization’s external admin attempts to disable MFA for themselves. They don’t think to consult with the security team and don’t consider the security implications, only the ease which they need for their team to use their login.

This CRM, however, defines MFA as a top-tier security setting; for example, Salesforce has a “High Assurance Login Value” configuration and immediately locks out all users as a safety precaution. The entire organization hits a standstill and is frustrated and confused.

Deeply concerning, this is not a one-off event, admins for business-critical SaaS apps often sit outside the security department and have profound control. Untrained and not focused on security measures, these admins are working towards their departmental KPIs. For instance, Hubspot is usually owned by the marketing department, likewise, Salesforce is often owned by the business department, etc. Business departments own these apps because it’s what allows them to do their job efficiently. However, the paradox lies in the fact that it’s the security team’s responsibility to secure the organization’s SaaS app stack and they cannot effectively execute this task without full control of the SaaS app.

The 2022 SaaS Security Survey Report, run by CSA and Adaptive Shield, delves into the reality of this paradox, presenting data from CISOs and security professionals today. This article will explore important data points from the respondents and discuss what the solution for security teams could be.

Learn how your security teams can regain control of all SaaS apps.

SaaS Apps in the Hands of Business Departments

Across a typical organization, a wide array of SaaS apps are used (see figure 1), from cloud data platforms, file sharing and collaboration apps to CRM, project and work management, marketing automation, and a whole lot more. The need for each and every SaaS app fills a certain niche role required by the organization. Without the use of all these SaaS apps, a business could find itself lagging or taking more time to achieve its KPIs.

The 2022 SaaS Security Survey Report reports that 40% of these apps are managed and owned by non-security teams, such as sales, marketing, legal, etc. (see in figure 2). While the security and IT teams are reported to be the main destination for SaaS app management, it’s the 40% of business departments also taking part and having full access that complicates the threat landscape.

Security teams can’t take away this ownership as the business applications’ owners need to maintain a high level of access to their relevant SaaS apps for optimal use. Yet, without in-depth knowledge of security or the vested interest (a security KPI that reflects on their work product), it’s not reasonable for the security team to expect that the business owner will ensure a high level of security in their SaaS.

Figure 2. Departments Managing SaaS apps, 2022 SaaS Security Survey Report

Unpacking the SaaS App Ownership Paradox

When asked the main reason for misconfiguration-led security incidents (figure 3), respondents of the survey report cited these at their top four: (1) There are too many departments with access to security settings; (2) Lack of visibility to security settings when they are changed (3) Lack of SaaS security knowledge; (4) Misappropriated user permissions. All of these reasons, either overtly or implied, can be attributed to the SaaS App Ownership Paradox.

The leading cause of security incidents caused by misconfigurations is having too many departments with access to security settings. This goes hand in hand with the next cause – lack of visibility when security changes are changed. A business department may make changes to an app setting to optimize its ease of use without consulting with or notifying the security department.

In addition, misappropriated user permissions can easily stem from a business department owner at the helm who is not paying careful attention to the app’s security. Often users are granted privileged permissions that they don’t even need.

How Security Teams Can Regain Control

With this shared responsibility model, the only efficient way to bridge this communication gap is through a SaaS Security Posture Management platform (SSPM). Hailed as a MUST HAVE solution to continuously assess security risks and manage the SaaS applications’ security posture in the "4 Must-Have Technologies That Made the Gartner Hype Cycle for Cloud Security, 2021", such a solution can alert the security team on any app configuration change made by the app owner, and provide clear directions on how to fix it through a ticketing or collaboration management system.

With an SSPM solution, owned and managed by the organization’s security team, the security team can gain complete visibility of all the company’s SaaS apps and their security settings, including user roles and permissions. W

Organizations can take it one step further and have the app owners join the SSPM platform so they can actively control and oversee all configurations in their owned apps. By using a scoped admin capability (figure 4) the security team can grant the app owners access to the apps they own and can remediate security issues, with their supervision and direction.

There’s no way to eliminate business departments’ access to SaaS app security settings, and while users across the organization should be educated on basic SaaS security in order to reduce the risk that may occur from business departments, it doesn’t always happen or it’s just not enough. Organizations need to implement a solution that helps avoid these situations by enabling visibility and control for the security team, alerting on configuration drifts, audit logs that provide insight into actions within the SaaS apps and scoped admins.

Get a 10-minute demo of how Adaptive Shield’s SSPM solution helps security teams regain control.

Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post.