SaaS Security: The Control Gaps Between Tenant and Enterprise

A SaaS contract hands the application’s infrastructure, patching and uptime to the vendor. It does not hand over the tenant. Who can sign in, which apps hold tokens into it, which settings are on and what data leaves all stay with the customer.

The vendor’s independent assurance report covers the vendor’s side of that line. It says much less about yours. SOC 2 reports typically include a list of complementary user entity controls: the things the customer must do for the vendor’s controls to hold. Read that section. It is the vendor telling you what your side contains.

The question for a security team is not whether the vendor is secure. It is which controls sit on your side, who owns them and whether anyone is checking.

A worked example: stolen tokens, not a software flaw

Google Threat Intelligence Group documented a data theft campaign, tracked as UNC6395, that ran for about ten days. The actor used stolen OAuth tokens belonging to Salesloft Drift, a third-party app connected to customers’ Salesforce instances. GTIG stated that the activity did not stem from a vulnerability in the Salesforce platform.

With those tokens the actor counted and pulled records from objects such as Accounts, Users, Cases and Opportunities. It then searched the exported data for secrets: AWS access keys, passwords and Snowflake tokens. GTIG assessed the main goal as credential harvesting. The actor deleted its query jobs, but the logs were unaffected. GTIG later reported that tokens for a Drift email integration were used to reach a very small number of Google Workspace accounts, and advised customers to treat every credential stored in or connected to Drift as potentially compromised.

Three tenant-side gaps are visible in that account:

• Integration. A vendor’s vendor held a standing token into the customer’s tenant.

• Data. Support cases and free-text fields held secrets. The CRM became a credential store without anyone deciding that.

• Visibility. Defenders were pointed to Salesforce Event Monitoring logs to reconstruct what the actor had queried. Where those logs were not available or retained, the question stayed open.

Where the gaps sit

The split below is typical. Contracts and tiers differ, so treat it as a starting checklist and verify per application.

Why the gaps persist

Ownership is split. The business buys SaaS and runs it. Sales operations administers the CRM, HR runs the people system and marketing owns its stack. Security inherits the risk without owning the settings, and no single person sees the whole estate.

Tooling covers pieces. The identity provider shows who signs in. A cloud access security broker watches traffic and data movement. SaaS security posture management tools compare tenant settings with a baseline. Each sees a slice, and integration tokens often fall in the cracks between them. Test each tool against your five most important applications, not against the product category.

Logging is uneven. Event detail and retention differ by vendor and by plan. A team that has never asked what its plan logs finds out during an incident.

A workable approach

Trying to assess every application fails. Tier them and go deep on the few that matter.

1. Inventory from several angles. Finance records, the identity provider’s application catalog, OAuth consent records and network discovery each find apps the others miss.

2. Tier by data and reach. Tier 1 holds crown-jewel data or can reach other systems. CRM, HR, collaboration, code hosting and anything that stores credentials usually qualify.

3. Write a baseline for Tier 1. SSO and MFA enforced, few admins, approved integrations only with scoped access, sharing defaults set, logs exported.

4. Treat integration tokens as credentials. Give each an owner, a scope, an expiry and a revocation procedure. Rehearse the question: if a vendor announces its tokens were stolen, how fast can you revoke them and see what they touched?

5. Search stored data for secrets. GTIG advised searching Salesforce for AWS keys, Snowflake references and passwords, then rotating what turned up. Do this before someone else does.

6. Send logs to the SIEM and detect on them. New connected app, unusual API volume, bulk export and admin changes are a sound first set.

GTIG’s own hardening advice for the affected platform shows the level of detail to aim for: restrict connected app scopes and avoid the broadest ones, enforce IP restrictions on the app, shorten session timeouts, and grant API access through permission sets rather than whole profiles.

For leadership, the decision is accountability. Name a control owner for each Tier 1 application and require the baseline to be checked on a schedule. Without a named person, the baseline is a document.

Use this to evaluate cloud control and configuration risk: take your five most sensitive SaaS applications and run each through the table above. Where you cannot answer a question, you have found a gap.

Sources

• Google Threat Intelligence Group (Mandiant), Widespread data theft targets Salesforce instances via Salesloft Drift. https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift

• AICPA, SOC 2 Trust Services Criteria and the description of complementary user entity controls. aicpa-cima.com