CrowdStrike Integration - Multiple Accounts for Identity

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi All,

Looking for some guidance from the community please.

Context:

We’ve setup the connector from our ISC tenant to our CrowdStrike tenant and there’s multiple accounts for one identity (as Crowdstrike pulls data in from multiple sources, eg: AD, Entra, etc).

Problem:

The issue is that when mapping attributes from CrowdStrike, SailPoint will simply choose the oldest account to map against the identity. Which would be fine if all accounts follow same creation timeframe but this isn’t the case.

Which means the OOTB Connector might map a risk score for some identities from AD but other risk scores from Entra. Which we’d like to avoid as we would prefer risk score sources to be consistent.

Potential Solution:

SailPoint suggest using a transform to filter which account we want mapping to the identity in this situation: Account attribute | SailPoint Developer Community

However, the OOTB integration documentation doesn’t provide a transform we could use… Bit pesky.

Help!

Does anybody have a working transform they would be willing to share or construct to help us filter account attributes from a specific account (all these accounts would be from the same Source within CrowdStrike, EG: Entra) to be mapped against an Identity?

Many thanks in advance,

Sean

2

@SeanK-W Use accountPropertyFilter in your accountAttribute transform. CrowdStrike accounts from different sources (AD, Entra, etc.) will have a distinguishing attribute — check what that field is in your CrowdStrike source schema (likely something like user_ou, idp_type, or a custom field that reflects the originating directory).

Once you identify it, the transform looks like this:

{
  "name": "CrowdStrike-RiskScore-Entra",
  "type": "accountAttribute",
  "attributes": {
    "sourceName": "CrowdStrike",
    "attributeName": "riskScore",
    "accountPropertyFilter": "(user_ou == \"Entra\")"
  }
}

Replace user_ou and \"Entra\" with whatever attribute/value actually differentiates the Entra-sourced account in your CrowdStrike data. accountPropertyFilter does in-memory filtering after account retrieval, so all account attributes are available to filter on — unlike accountFilter which is limited to nativeIdentity, displayName, and entitlements.

If you’re unsure which field to use, pull a raw account from the CrowdStrike source via the Accounts API and look for any attribute that’s unique to the Entra-origin accounts.

3

Overall, you probably just shouldn’t do this. ISC is not getting this info from CrowdStrike in real-time. It’s, at most, aggregating hourly, so you’ll have a delay in whatever logic you’re hoping to trigger off these scores. In addition, there’s the problem you’ve noticed, which is that CrowdStrike is assessing individual accounts, and you’re trying to map the scores for multiple accounts to a single identity.

Your SOC should be monitoring for and responding to risk events in real-time, not relying on ISC to catch it within the hour.

4

Thank you, this is exactly the sort of thing I was after!

This solved my use case; however, did then stumble into a few other issues which are unrelated to this transform… But I can look into those :slight_smile:

Re @sup3rmark , agreed that the use case you have presented is best handled real time via SOC.