SaaS Applications – solving the Inventory & Discovery challenge

Baseline SAM is about reconciling what you own against what you’re using. ITAM tool vendors have mastered this for software installed on devices ranging from IoT sensors to mainframe computers. However, as Software-as-a-Service use grows, they are presented with both a threat to their current products, and an opportunity to deliver considerable savings to their customers.

The primary challenge with managing SaaS applications is how do you inventory an application that isn’t installed and may not even be authenticated to your corporate directory? And how do you discover SaaS applications which have been brought into the organisation by employees and departments without IT involvement? These problems require innovation, and much of this innovation has been made by new entrants to the SAM tool marketplace.

This article explores the strengths and weaknesses of the various discovery methods implemented by both these new entrants and traditional ITAM tool vendors.  As you will see, in order to get a full picture of your SaaS Management landscape, multiple discovery and inventory methods will be required, and there is scope for further innovation.

In general, vendors make use of the following discovery methods to inventory SaaS subscriptions.

• Inventory Agent/Browser plugin
• API
• App Permissions
• Cloud Access Security Broker (CASB)
• Expenses/Accounts Payable
• Web Proxy/Endpoint
• Single Sign On (SSO)

Agent/Browser Plugin

Discovery via an Agent or Browser Plugin is the “traditional” method for discovery and inventory. Either an agent, potentially one already deployed for inventorying on-premises software deployments, or a browser plugin is deployed on each company device.

This is best-suited to company-owned and managed devices, where the ITAM team has good control over their environment.

In order to work effectively there should be no method to bypass the agent – for example, it should also capture SaaS traffic from desktop applications communicating via HTTP, and not just browser-native applications.

A further challenge to this approach is BYOD – be that a mobile device or personal laptop being used to access the SaaS service. Whilst an Acceptable Use Policy could be used to prevent such devices from accessing the service this may not be desirable and is also easily bypassed.

Caution is also required in order to only capture services used for corporate use. For example, employees may access personally-owned services using company-supplied equipment. Furthermore, there may be simultaneous personal and corporate use of the same SaaS application – G-Suite being a prime example.

API

API discovery methods make use of SaaS vendor-provided API connections to discover and inventory SaaS application usage. They have the potential to provide rich discovery and inventory data and avoid issues around privacy and discovery bypass inherent with other methods. A SaaS Management tool can be configured to only harvest inventory from SaaS apps configured by the ITAM team. However, data quality is controlled by the vendor and subject to change. Some vendors, such as Adobe, charge a premium for such data – in their case it is only available with a Creative Cloud for Enterprise subscription. API integrations are also complex for the SaaS Optimisation vendor to develop and may be charged for separately. Finally, not all SaaS providers will have APIs so this can only ever work for a subset of your SaaS estate.

App Permissions

Discovery by App Permissions is achieved by interrogating the list of third party apps granted some form of access to the primary SaaS application. An example would be discovering the shared calendar app Calend.ly through G-Suite integration, because a user has granted it permission to access their Google Calendar. This discovery method relies on API access being provided by the SaaS application provider but can enable an assessment to be made regarding third-party supplier risk, which is important for regulatory compliance.

Cloud Access Security Broker

Cloud Access Security Brokers are typically specified by IT Security & Compliance teams, and are managed by Network teams. They are analogous to and often form part of a firewall implementation. They broker all traffic between company employees, their devices, and the specified cloud applications. Typically they perform a range of functions but for the purposes of this discussion we’ll focus on how they discover and inventory SaaS applications. Depending on the deployment scenario they may be agent-based or agentless. Agent-based CASB requires an endpoint to be installed on each monitored device, with similar benefits and cautions to the Agent/Browser Plugin approach discussed above. Agentless discovery may also be deployed; this can provide fine-grained discovery and inventory – for example only capturing data for corporate-owned SaaS applications.

In general CASB products exist to enforce security and network access policies. Their usefulness for discovery, inventory, and metering may be a secondary benefit and as such may not provide the data a SAM team needs, or offer integrations with traditional SAM tools.

Expenses/AP

Integration with Expenses and Accounts Payable systems is used to discover spend on SaaS services. This is an agentless discovery methodology which typically is quick to implement and may find SaaS usage that bypasses other methods. Vendors using this approach are able to discover and inventory SaaS spend regardless of where the service is consumed. The expense may also be easily assignable to an individual. This method should be acceptable from a privacy perspective because it will only capture services being used for business use, based on the fact that the business is paying the bill.

However, this approach requires compatibility with the customer’s systems and so may not suit all deployment scenarios. Furthermore, if used in isolation it only captures spend (entitlement), not utilisation.

Proxy

Most organisations deploy web proxies to monitor internet traffic and protect their networks. Modern proxies usually operate through the installation of a client on each endpoint, ensuring that all web traffic routes via the proxy. These clients can be configured to discover and inventory SaaS application usage. However, as with the agent/browser-plugin based approach this becomes problematic when SaaS usage originates from personal devices.

Endpoint clients may also be incompatible with SaaS applications – for example Forcepoint’s (formerly Websense) client was unable to proxy traffic to Slack, either from the browser native or desktop application. If your SaaS traffic has to bypass your endpoint client or proxy it becomes harder to discover.

In the absence of an endpoint client a company’s web security provider may be able to provide reports of SaaS usage. The challenge is that typically this is not core functionality for a proxy product, and this is likely to mean that the accuracy and completeness of the discovery may be less good than that from a pure SaaS optimisation product. Given that many organisations allow personal use of the internet via company-owned devices caution is also required in order not to capture personal use of SaaS applications.

SSO

Single Sign On Discovery methods link the SaaS Optimisation tool with an SSO Provider such as Onelogin, GSuite, or Okta. Each user login from your domain is then captured and fed into the SaaS tool. There are clear benefits to this method in that it will work regardless of device ownership and can be easily configured to only capture login data for company-managed SaaS apps. This should address the privacy concerns inherent with other discovery methods.

However, SSO Discovery will have to be combined with other discovery methods in order to provide vendor level information – costs, number of contracts, owners, renewals, etc. It is reliant on the SaaS application supporting the SSO broker and may only discover applications you have configured for monitoring, rather than all SaaS apps. Furthermore it may only detect logins, not usage.

Discovery Challenges

Each discovery methodology has strengths and weaknesses and currently there is no single methodology to rule them all. Challenges to discovery completeness include:

• Privacy
• BYOD
• Browser-native vs Dedicated application
• Proxy bypass
• AP/Expenses system compatibility
• Agent/Browser Plugin deployment
• Core vs peripheral functionality
• API availability/complexity
• SaaS Provider resistance

The table below (click the table to expand it) outlines how the various discovery methodologies are impacted by these challenges.

Green indicates that the challenge is met by the discovery method. For example, Browser-native applications will be detected by a tool using an inventory agent or browser plugin. Amber means that there may be issues in certain circumstances. For example there may be privacy concerns using CASB as you may track personal use of an application, depending on configuration. Red means that a challenge is insurmountable for the discovery method. For example, an inventory agent or browser-plugin will not be able to detect use of SaaS applications on BYOD or unmanaged devices.

Click table to expand

Summary

It is clear that multiple discovery methods are required in order to provide an accurate SaaS inventory. SaaS Optimisation tools and services will need to take a blended approach based on the challenges to completeness highlighted above.

The next article in this series will look at the requirements you should consider when selecting a SaaS Management tool.

If you’re already using a SaaS Management tool I’d welcome a conversation around your experiences. As with all my interactions with customers and vendors this will be treated in strictest confidence. If you’re a vendor I’d also welcome your views on this analysis – you can reach me via the links in my profile.