SaaS Security Guide: SSPM and Configuration Drift

Recent large SaaS data thefts, from Snowflake to Salesloft Drift, did not break the SaaS platforms themselves: they exploited the customer's half of the shared responsibility model, through weak sign-in, drifting settings, over-shared data and integrations nobody owned. Each SaaS application has its own admin console, local accounts, sharing model, API tokens and audit log, and its defaults change on the vendor's release schedule, not yours. This guide covers the controls the customer owns: inventory and shadow SaaS, configuration baselines such as CISA's SCuBA and the CIS benchmarks, SaaS security posture management (SSPM) and drift, identity and admin roles, integrations, data sharing, logging and licence tiers, backup, offboarding, and what recent SaaS supply chain incidents teach. It is written for security architects, SaaS platform owners and identity teams.

Key takeaways

• The customer owns configuration, identity and data. The provider secures the platform; who can sign in, what they can share, which apps are connected and what is logged are your decisions, and defaults are rarely the secure option.
• Baselines turn opinions into tests. CISA's SCuBA baselines for Microsoft 365 and Google Workspace and the CIS Microsoft 365 Foundations Benchmark give numbered, testable policies; the free ScubaGear and ScubaGoggles tools check a tenant against them.
• Drift is the normal state. Admins change settings, vendors ship new features with permissive defaults and exceptions never expire, so posture has to be re-measured on a schedule, not certified once.
• Stolen sessions and tokens bypass the front door. Snowflake, Salesloft Drift and the ShinyHunters Salesforce campaign used valid credentials, OAuth tokens or a connected app the victim approved, not a software vulnerability.
• Logs depend on licence tier. Retention and high-value events such as MailItemsAccessed or Salesforce query logs often sit behind premium licences; decide what you need before an incident, not during one.

Shared responsibility in SaaS

The NCSC puts it plainly: "There is a shared responsibility between both the SaaS provider and the organisation consuming the service." In SaaS the provider runs the application, platform and infrastructure, which leaves the customer a smaller but decisive set of controls. The CSA SaaS Security Capability Framework (SSCF) was written for exactly this boundary: it defines "configurable, consumable, and customer-facing security controls provided by SaaS vendors to their customers", and works as both a procurement checklist and a hardening scope.

Inventory and shadow SaaS

Shadow SaaS arrives through free tiers, expense claims, trials signed up with a work email address and "Sign in with Microsoft or Google" buttons that create an OAuth grant on first use. Build the inventory from several sources, because each misses something:

• Identity provider: SSO applications and sign-in logs; blind to apps using local passwords.
• OAuth grants and service principals: consented third-party apps in Entra ID and Google Workspace, which surface tools users connected themselves. See the Shadow AI Discovery Guide for AI tools found this way.
• Network and browser telemetry: secure web gateway, CASB or SSE logs, and browser extension or enterprise browser data. See the Enterprise Browser and Browser Security Guide.
• Finance: card and expense records catch paid tools that never touch SSO.

For each application record the owner, admin, data classification, sign-in method, integrations, licence tier and whether audit logs are collected. Tier the estate: the identity provider, email and collaboration suite, CRM such as Salesforce, ITSM such as ServiceNow, data warehouses such as Snowflake, code hosting, HR and finance are tier 1 and get baselines, SSPM coverage and log collection first.

Configuration baselines and drift

A useful baseline gives each control an identifier, a required value and a test. Three sources do:

• CISA SCuBA: the Secure Cloud Business Applications project publishes secure configuration baselines for Microsoft 365 and Google Workspace. ScubaGear queries a Microsoft 365 tenant (Entra ID, Defender, Exchange Online, SharePoint, Teams, Power BI and Power Platform), compares settings against the baselines with Open Policy Agent Rego policies and reports in HTML, JSON and CSV. ScubaGoggles does the same for Google Workspace through the Admin SDK API. US federal civilian agencies must apply them under Binding Operational Directive 25-01 (December 2024); for everyone else they are a free starting point.
• CIS benchmarks: the CIS Microsoft 365 Foundations Benchmark (version 7.0.0 at the time of writing) is consensus-built and maps to CIS-CAT Pro scanning; CIS also publishes foundations benchmarks for other SaaS platforms such as Google Workspace.
• Vendor hardening guides: for Salesforce, ServiceNow, Snowflake and other platforms without a SCuBA baseline, use the vendor's security guide and the SSCF controls.

Example SCuBA policies for Entra ID

SSPM and drift detection

SaaS security posture management tools connect to each application's admin APIs, read configuration, users, roles and integrations, compare them to a policy set and alert on change. Whether you buy one or script the SCuBA tools, drift control needs four things: a scheduled scan (daily for tier 1), a stored previous result so each run is a diff rather than a fresh report, an exception register with an owner and expiry date for every accepted deviation, and an alert when a high-severity control flips from pass to fail. Review vendor release notes monthly for new features enabled by default, especially AI assistants and sharing options.

Identity and admin roles

• Enforce SSO, then remove the back door: enabling SAML or OIDC is not enough if local username and password sign-in still works. Disable local sign-in where the app allows it, and list every account that can still use it. See the Identity Provider and SSO Security Guide.
• MFA at the right layer: with SSO, enforce phishing-resistant MFA in the IdP through conditional access; for apps with local accounts, enforce the app's own MFA. Snowflake customers whose accounts lacked MFA were the ones hit in 2024. See the MFA Guide.
• Admin roles: count super admins per app, use the platform's least-privileged admin roles (Global Reader in Microsoft 365, delegated admin roles in Google Workspace, permission sets rather than profiles in Salesforce) and use just-in-time elevation where offered. In Salesforce, treat "API Enabled", "Customize Application" and "Manage Connected Apps" as privileged permissions. See the JIT Access Guide.
• Break-glass accounts: keep one or two local emergency accounts per tier 1 app, excluded from SSO dependency, with strong credentials held offline and an alert on every use. See the Break-Glass Account Guide.
• Sessions: SSO does not end a session the SaaS app already issued. Set session lifetimes and restrict sign-in by device or network for high-value apps. Stolen session tokens and HAR files were central to the Okta support system breach. See the Token and Session Security Guide.
• Access reviews: review admin roles quarterly using the app's own role data, not just IdP groups. See the Access Reviews Guide.

Where identity fits: integrations and tokens

Every connected app, integration user, API key and OAuth refresh token is a non-human identity with standing access to SaaS data, often more than any single human user. ATT&CK tracks the abuse as T1528 Steal Application Access Token and T1671 Cloud Application Integration, which describes adversaries achieving "persistence by leveraging OAuth application integrations in a software-as-a-service environment". Two settings deserve specific attention. Google Workspace domain-wide delegation gives an app "access to the data belonging to all of your users" without consent, so only super admins can grant it and scopes should be narrow and reviewed. Salesforce connected apps should have IP relaxation set to "Enforce IP restrictions" and scopes narrower than full, as Google Threat Intelligence advised after the Salesloft Drift tokens were abused. Consent policy, grant inventory, scope review and the vendor-breach revocation runbook are covered in the SaaS and OAuth App Governance Guide; vendor and contractor accounts in the Third-Party Access Guide.

Data sharing, external collaboration and backup

• Link sharing: disable or restrict "anyone with the link" sharing for tier 1 data, set default link type to internal, and apply expiry to external links.
• External domains and guests: allow-list partner domains for sharing and guest access instead of allowing all; expire guest accounts that have not signed in for 90 days. Teams, Slack and Google Chat settings are covered in the Collaboration Tool Security Guide.
• Public-facing components: customer portals and public sites connected to CRM records expose data to unauthenticated users if guest user permissions are loose; review them for every public site.
• Labels and DLP: apply sensitivity labels and DLP rules inside the SaaS platform, not only at the network edge. See the Data Loss Prevention (DLP) Guide.
• Bulk export: restrict report export and data loader tools to named roles.
• Backup and SaaS ransomware: native recycle bins and version history have short windows and do not protect against an admin account or a sync client deleting or overwriting data at scale. Keep an independent backup for tier 1 SaaS data and test restores. A SaaS backup service is itself a high-value integration: the Commvault Metallic breach exposed customers' Microsoft 365 app secrets. See the Backup Security and Immutable Backup Guide.

Logging, licence tiers and detection

Check what each tier 1 application logs, for how long, at which licence tier, and whether an API exposes it, before you need it. Also alert on audit logging being disabled, MFA exclusions, loosened sharing and new super admins.

Ingest logs into the SIEM with the app's own retention as a floor, not a ceiling. See the Log Management and Retention Guide. High-value detections:

Lessons from SaaS supply chain incidents

Offboarding users and applications

• Users: disabling the IdP account does not revoke app sessions, personal API tokens, OAuth grants the user made or local accounts. Use SCIM deprovisioning, revoke sessions in each tier 1 app and transfer file ownership. See the Joiner-Mover-Leaver Guide and SCIM Provisioning Guide.
• Owners: when an app's owner leaves, reassign ownership; ownerless apps drift first.
• Applications: when a SaaS product is retired, revoke its OAuth grants and service principals, delete integration users and API keys, remove SSO configuration, export what you must keep, and obtain written confirmation of data deletion.

Implementing a SaaS security programme

1. Inventory and tier (weeks 1 to 4): combine IdP, OAuth, network and finance data; name owners; select tier 1 apps.
2. Baseline in report-only mode: run ScubaGear and ScubaGoggles (or an SSPM) read-only against tier 1 tenants; record every failure as fix, accept with expiry, or not applicable.
3. Fix identity first: block legacy authentication, enforce SSO and phishing-resistant MFA for admins, reduce super admins, restrict user consent. Pilot conditional access changes on a test group with report-only mode before enforcing, and keep break-glass accounts excluded.
4. Integrations and sharing: review connected apps and grants, then restrict sharing defaults and guest access.
5. Logging: license the tiers you need, stream to the SIEM, build the detections above.
6. Automate drift: schedule scans, diff results, alert on regressions, and route fixes to app owners with a service level.
7. Roll back safely: snapshot settings before each change (ScubaGear JSON output works), change one control group at a time, and revert if sign-in or integrations break.

Choosing an approach

Larger organisations usually combine all four. See the ITDR Guide and ISPM Guide.

Detection and measurement

• Coverage: percentage of tier 1 apps with SSO enforced and local sign-in disabled.
• Posture: baseline pass rate per tier 1 tenant, and the number of high-severity failures open longer than 30 days.
• Drift: mean time from a control regression to its detection and to its fix.
• Privilege: super admin count per app against target (two to eight Global Administrators under MS.AAD.7.1v1).
• Integrations: percentage of connected apps and OAuth grants with a named owner, and number of dormant grants removed per quarter.
• Logging: percentage of tier 1 apps whose audit logs reach the SIEM, with retention meeting policy.

Framework mapping

Common failure patterns

• SSO without enforcement: local passwords still work, so infostealer credentials bypass the IdP, as in the Snowflake breach.
• Forgotten tenants and test environments: secondary tenants outside the baseline and without MFA, as in the Midnight Blizzard breach.
• Anyone can approve an integration: users or junior admins can authorise connected apps, which turns a vishing call into data theft.
• Secrets stored in SaaS records: keys and passwords pasted into support cases or tickets become loot for whoever reads the CRM, which UNC6395 searched for after the Drift token theft.
• Logs not licensed or not collected: the investigation cannot show what an integration read because query or mailbox access events were never enabled.

Practitioner checklist

• Build a SaaS inventory from IdP, OAuth, network and finance data, with an owner and tier for each app.
• Run ScubaGear or ScubaGoggles (or the CIS benchmark) against Microsoft 365 or Google Workspace and track every failure to fix or time-limited exception.
• Enforce SSO and disable local sign-in on tier 1 apps; keep tested break-glass accounts.
• Require phishing-resistant MFA for all admins and remove permanent active assignment of the highest roles.
• Restrict who can authorise connected apps and OAuth consent; apply IP restrictions to integrations.
• Restrict external sharing defaults and expire inactive guests.
• License and collect the audit events you need, and alert on new admins, new integrations and bulk export.
• Schedule posture scans with diffing and alerting on regressions.
• Keep independent backups of tier 1 SaaS data and test restores.
• Revoke tokens, integration users and grants when users leave and when apps are retired.

Standards and references

• CISA: Secure Cloud Business Applications (SCuBA) Project
• CISA: ScubaGear, Microsoft 365 secure configuration assessment tool
• CISA: ScubaGoggles, Google Workspace secure configuration assessment tool
• NCSC: Understanding Software as a Service (SaaS) security
• Cloud Security Alliance: SaaS Security Capability Framework (SSCF)
• CIS: Microsoft 365 Benchmarks
• Microsoft Learn: Learn about auditing solutions in Microsoft Purview
• MITRE ATT&CK: T1671 Cloud Application Integration

Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · Third-Party Access Guide · Identity Provider and SSO Security Guide · Collaboration Tool Security Guide · ISPM Guide