AN1090: Analytic 1090
Access to organizational directories via Google Workspace Directory API, Slack SCIM, or Okta SCIM by apps or identities outside normal roles.
Analyst context for executives and security teams
This analytic matters because SaaS directory access can expose who works in the organization, group membership, and identity structure through services such as Google Workspace Directory API, Slack SCIM, and Okta SCIM. For executives and security leaders, the decision value is whether directory data access is limited to expected business roles and approved applications, and whether unusual access can be investigated quickly before it becomes an identity, privacy, or compliance issue.
Executive priority
Prioritize this as an identity and SaaS governance control question: which apps and identities are allowed to read organizational directories, who approved that access, and can the security team prove it with audit evidence? The main business risk is not defined impact from this object, but the exposure of identity and organizational data through SaaS integrations outside normal roles. This supports access review, compliance readiness, and incident triage around SaaS identity misuse.
Technical view
SOC, IAM, and cloud security teams should validate visibility into directory access events for the SaaS platforms explicitly named: Google Workspace Directory API, Slack SCIM, and Okta SCIM. Since ATT&CK does not provide detection logic for this analytic, teams should baseline normal directory-access roles, service accounts, integrations, and administrative identities, then review access by apps or identities that fall outside those expected roles. Investigations should focus on whether the actor, application, scope, and timing align with approved business use.
Likely telemetry
- Google Workspace Directory API audit or admin activity logs showing directory read/access events
- Slack SCIM access and app/integration activity logs
- Okta SCIM, system, and application integration logs
- SaaS application consent, OAuth/app authorization, or service account records where available
- IAM role assignment, group membership, and admin privilege change records
Detection direction
- Define the normal roles and approved applications that should access organizational directories, then alert or review access outside that baseline.
- Correlate directory access with app authorization, service account ownership, role assignments, and recent privilege changes.
- Tune carefully for legitimate HR, IT automation, provisioning, and identity governance workflows to reduce false positives.
- Validate whether logs distinguish human identities, service accounts, and third-party apps; this is a common blind spot in SaaS investigations.
- Because no official detection logic is supplied, treat this as a coverage validation and hunting direction rather than a ready-to-deploy analytic.
Mitigation priorities
- Inventory applications and identities with Google Workspace Directory API, Slack SCIM, or Okta SCIM directory access.
- Restrict directory access to approved business roles, managed integrations, and least-privilege scopes where supported by the SaaS platform.
- Require ownership, approval, and periodic access review for service accounts and apps with directory permissions.
- Maintain audit logging and retention sufficient for SaaS identity investigations and compliance evidence.
- Document expected directory-access patterns so SOC and incident response teams can distinguish approved automation from unusual access.
Analyst notes and limits
This object is a detection analytic for SaaS directory access outside normal roles. The supplied ATT&CK fields name Google Workspace Directory API, Slack SCIM, and Okta SCIM, but provide no tactics, relationships, or official detection text. The highest-value use is to turn it into a SaaS identity governance and logging validation: know who and what can read directory data, prove why that access is appropriate, and investigate deviations.
No relationship context, tactic mapping, adversary use, detection query, mitigation text, or impact statement was supplied. Local SaaS configuration, logging availability, retention, app inventory, and role definitions are required to determine actual exposure and detection coverage.
Analytic 1090
Access to organizational directories via Google Workspace Directory API, Slack SCIM, or Okta SCIM by apps or identities outside normal roles.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 7cb917a3ffc1… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1090Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.