Detect successful SaaS authentication through an application-specific or legacy credential mechanism from a source/client not previously associated with that account, correlated with new session establishment or subsequent access inconsistent with ApprovedASPUsage.
| Data Component | Name | Channel |
|---|---|---|
| User Account Authentication (DC0002) | saas:audit | Successful application-specific/legacy credential authentication where exposed |
| User Account Modification (DC0010) | saas:audit | ASP creation/modification event where supported |
| Logon Session Creation (DC0067) | saas:session | New authenticated session associated with changed source/client context |
| Field | Description |
|---|---|
| ApprovedASPUsage | Approved user/application/use-case relationships for ASP authentication—for example, which user or service is expected to use an ASP with which application. Derive from documented integration workflows and service ownership. Broadening permitted relationships reduces FP but increases FN for abused legitimate credentials; narrowing them increases detection sensitivity and FP. |
Detect successful Office Suite access using an authentication method that does not perform the account's expected MFA flow, correlated within ASPActivityWindow with first-seen client/application access, an anomalous source/device, or an ASP-related account credential change where available.
| Data Component | Name | Channel |
|---|---|---|
| Application Log Content (DC0038) | m365:unified | Authentication/account audit event identifying app-password or applicable legacy-authentication activity |
| User Account Authentication (DC0002) | azure:signinlogs | Successful account authentication with authentication/client properties inconsistent with normal MFA-backed access |
| User Account Modification (DC0010) | idp:audit | ASP added/created where exposed by provider |
Detect creation of an application-specific password for a user account, correlated within ASPActivityWindow with authentication from a source, device, client, or location outside the account's established baseline, or followed by authentication using a legacy/non-MFA authentication path inconsistent with ApprovedASPUsage.
| Data Component | Name | Channel |
|---|---|---|
| User Account Modification (DC0010) | idp:audit | Application-specific password created/added for account |
| User Account Authentication (DC0002) | idp:authentication | Successful authentication associated with legacy/application-specific credential flow |
| Logon Session Creation (DC0067) | idp:session | New session established from source/device inconsistent with account baseline |
| Field | Description |
|---|---|
| ASPActivityWindow | Time window used to correlate application-specific password creation, modification, retrieval, or use with subsequent authentication activity. Derive from the normal delay between ASP administration and legitimate first use. Increasing the window captures delayed malicious use but increases FP from unrelated account activity; decreasing it reduces FP but may miss delayed adversary use (FN). |
| ApprovedASPUsers | Users or roles authorized to create, manage, or use application-specific passwords. Derive from IAM policy, role assignments, and approved exception records. Broadening the list reduces FP but increases FN from compromised authorized accounts; narrowing it increases FP for legitimate ASP users but reduces FN. |
| ApprovedASPApplications | Applications, services, or integrations approved to authenticate using application-specific passwords. Derive from application inventory and IAM/integration configuration. Broadening the set reduces FP but may conceal unauthorized application use (FN); narrowing it increases FP when legitimate applications are omitted. |
| ApprovedASPUsage | Approved user/application/use-case relationships for ASP authentication—for example, which user or service is expected to use an ASP with which application. Derive from documented integration workflows and service ownership. Broadening permitted relationships reduces FP but increases FN for abused legitimate credentials; narrowing them increases detection sensitivity and FP. |
| KnownDevices | Devices or managed endpoints from which ASP-related account activity or authentication is expected. Derive from device inventory, endpoint management, and historical successful authentication. Broadening known-device criteria reduces FP but can suppress compromised devices; narrowing increases FP from new/rebuilt legitimate devices. |
| KnownLocations | Expected geographic, network, tenant, or organizational locations for the associated identity/application activity. Derive from historical authentication telemetry and organizational network architecture. Broadening accepted locations reduces travel/remote-work FP but increases FN; narrowing increases sensitivity but also FP. |
| ExpectedAuthMethods | Authentication methods normally associated with the account/application workflow. Derive from identity-provider policy and historical authentication telemetry. Broadening expected methods reduces FP but can hide fallback or weaker authentication abuse; narrowing increases FP when legitimate authentication methods change. |
| ApprovedLegacyClients | Legacy clients explicitly permitted to authenticate using ASP-compatible mechanisms. Derive from application inventory and documented compatibility exceptions. Adding clients reduces FP but increases the opportunity for malicious use to blend with approved legacy authentication; removing clients increases FP until legitimate dependencies are remediated. |
| KnownSourceRanges | Network ranges from which approved ASP-backed applications or services normally authenticate. Derive from service/network architecture and historical authentication sources. Broadening ranges reduces FP but increases FN for adversary activity originating within accepted infrastructure; narrowing improves discrimination but increases FP from legitimate infrastructure changes. |