In many organizations, each department typically has its own set of tools or SaaS applications they use to get their jobs done. Sometimes, IT is involved in the purchase of these tools. But other times — especially when it comes to SaaS — they aren’t.
Ultimately, SaaS ownership is complicated. And solving the issues of SaaS ownership requires understanding business goals, reasons, and pain points about why teams leverage the SaaS apps in the way they do.
To better understand the challenges with SaaS ownership and how organizations can go about solving them, I sat down with Axonius CISO Lenny Zeltser. Snippets from our conversation are included below.
Amir Ofek: Why do organizations need a SaaS management program?
Lenny Zeltser: Before SaaS, employees had to rely on IT and other teams to procure software, which gave the organization a direct way of controlling such purchases and deployments.
Nowadays, employees can sign up for SaaS applications without involving anyone in the company. The lack of internal bottlenecks empowers people to quickly get the tools they need to get work done. However, now finance, IT, legal, and other teams lack the visibility to ensure that the apps are provisioned and managed in a responsible and secure way. No longer the gatekeepers, they need to revisit their approaches to guiding and overseeing the company’s use of SaaS.
Ofek: Why is SaaS ownership so difficult for IT and security to get a handle on?
Zeltser: There are several reasons why SaaS ownership is challenging for IT and security teams.
Employees can start using SaaS applications without any involvement of IT and security teams. As a result, these teams are often unaware that the applications are being used and don’t know about the risks associated with them. For example, they might not know that sensitive data is now processed by a SaaS provider and cannot associate the appropriate security measures with the app. On their own, end users often lack the expertise to configure the apps in a way consistent with the organization’s policies.
Another challenge is the lack of a clear understanding of the roles and responsibilities for “owning” a SaaS application. Who is responsible for adding new users to it and assigning to them the appropriate permissions? Who will revoke access when the need arises? Who will handle renewal and other licensing discussions? End users who initially purchase a SaaS product might expect IT or other teams to handle all or some of these responsibilities, but these teams might not share this understanding.
In addition, modern SaaS applications rarely function as data siloes. They often integrate with other software. Such interdependencies and data flows are often not considered by the individuals who bring SaaS into the organizations. Late-stage discovery of such externalities can put unexpected burdens on IT and security teams and might prevent the SaaS application from achieving its full potential in a reasonable timeline.
IT and security teams should document the roles and responsibilities related to deploying and maintaining a SaaS application. Explain what aspects of the app’s configuration and oversight will be owned by the IT team. Clarify what responsibilities might reside with the end users. For example, depending on how the app integrates with the company’s identity management system, IT might be able to automatically provision users with the right privileges into the SaaS app; in other cases, designated people outside IT might need to do this.
Also, clarify the company’s expectations of SaaS applications. What security requirements does the organization impose on its SaaS providers? How might these requirements differ based on the sensitivity of the data processed by them? Consider service-level expectations, single sign-on (SSO) requirements, etc. What other internal teams, such as legal and finance, might need to be involved and when? Document these expectations so that when people looking at SaaS know what they need to do or communicate to SaaS providers.
In addition, recognize unsanctioned SaaS products will find their way into the organization. Consider what approaches and tools you might use to discover their existence, so IT and security teams can bring the necessary oversight to their usage to protect the organization and support end users.
Ofek: It may be difficult to get other departments to discuss SaaS ownership. What do you recommend IT and security to do, so they can bring up this issue and not get pushback?
Zeltser: One way to start the discussion of SaaS ownership is to identify common interests. Most likely all stakeholders want to have a SaaS application that is correctly deployed and properly licensed. It should be available to the right people with the expected functionality. The stakeholders will also probably agree that the app should be responsibly secured and that it shouldn’t expose the organization to unexpected or undesirable risks.
Next, outline what one-time and ongoing tasks need to happen for the organization to meet the identified objectives. With these responsibilities at hand, discuss who is best positioned to handle them, how, and when. For additional details, consider identifying responsibilities according to the RACI model, which calls for agreeing on who should be responsible, accountable, consulted, and informed about the tasks.