SailPoint ISC to Sentinel: watching the system that grants access

Why the governance layer is where detection belongs

Most identity monitoring watches the effects of access: a sign-in from somewhere odd, a privileged group gaining a member, a mailbox rule appearing. That works when the attacker has to break something to get in.

It does not work against someone who controls identity governance. They don’t need to bypass a control — they raise a request, approve it themselves, and the platform provisions the access properly. Every downstream system then sees a legitimate, approved grant, because that is genuinely what it is. The audit trail agrees with them.

So the only place that story falls apart is in the governance layer itself, where you can see the same person requesting and approving. Miss it there and you won’t catch it later.

That makes ISC audit events high-value SOC telemetry. It also makes anything carrying those events part of your Tier 0 estate, which is the thing most collector projects get wrong: the pipeline holds a credential that can read the entire audit trail, and — if it rotates its own credentials — one that can mint new ISC credentials. Compromise the pipeline and you have compromised the evidence.

What the pipeline does

Two Python Function Apps in one resource group, deployed by Bicep:

• Collector — polls the ISC search API on a timer (every 5 minutes by default), normalises each event into a fixed column shape, and writes it through a Data Collection Rule into Log Analytics as SailPointISC_CL.
• Rotator — replaces both ISC credentials on a schedule with no human in the loop. Weekly check, replacing anything older than 30 days.

Supporting cast: Key Vault for the two credentials, a storage blob for the ingestion checkpoint, and a Data Collection Endpoint plus Rule for the ingestion path. Events land in your existing Sentinel workspace if you point the template at one, which most people will want.

Every normalised event also keeps the untouched ISC payload in a RawEvent column. That matters more than it sounds: a detection engineer is never blocked by a mapping decision made in the collector, and a schema change at the ISC end degrades to “one normalised column is empty” rather than “the data is gone”.

The decisions that carry weight

These are load-bearing. Each one changes the security posture if you undo it, which is why the repo records the reasoning in docs/threat-model.md rather than leaving it in a commit message.

That last one has a subtlety worth calling out, because it’s the kind of thing that looks fine in review and quietly loses data. ISC routinely emits several events in the same millisecond. If your checkpoint stores a timestamp and the next query asks for everything after it, you silently drop every other event that shared that millisecond. The collector instead queries inclusively from the checkpoint and de-duplicates by event id, keeping a small set of ids seen at exactly that timestamp.

Runbook: deploy it

The full runbook — parameters, bootstrap, first rotation, verification, troubleshooting — is infra/README.md. This is the shape of it.

Detections worth building

Start by learning your own tenant’s vocabulary. Event names and actions vary between tenants and releases, so confirm what yours actually emits before hard-coding values into an analytics rule:

SailPointISC_CL
| where TimeGenerated > ago(7d)
| summarize Events = count(), Latest = max(TimeGenerated) by EventType, EventAction
| order by Events desc

Persistence — a new API credential appears. In a mature tenant this should be rare and always tied to a change record:

SailPointISC_CL
| where TimeGenerated > ago(24h)
| where EventName has_any ("PERSONAL_ACCESS_TOKEN", "OAUTH_CLIENT", "API_CLIENT")
| where EventAction has_any ("CREATE", "CREATED")
| project TimeGenerated, ActorName, TargetName, EventName, EventAction, IpAddress
| order by TimeGenerated desc

Privilege escalation where the actor is also the target. This is the self-approved grant that looks legitimate everywhere downstream:

SailPointISC_CL
| where TimeGenerated > ago(24h)
| where EventType has_any ("IDENTITY", "ROLE", "ACCESS_PROFILE", "CAPABILITY")
| where EventAction has_any ("GRANT", "ADD", "UPDATE")
| where isnotempty(ActorId) and ActorId == TargetId
| project TimeGenerated, ActorName, TargetName, EventName, EventAction, IpAddress

Preparation for mass deprovisioning. A source’s delete threshold is the guardrail stopping an aggregation from wiping accounts wholesale. Someone raising or removing it is worth a conversation:

SailPointISC_CL
| where TimeGenerated > ago(7d)
| where EventName has "THRESHOLD" or TechnicalName has "THRESHOLD"
| project TimeGenerated, ActorName, SourceName, EventName, Details
| order by TimeGenerated desc

Standing access that should have gone. Deprovisioning that failed is the leaver who still has a live account:

SailPointISC_CL
| where TimeGenerated > ago(7d)
| where EventStatus has_any ("FAILED", "FAILURE", "ERROR")
| where EventAction has_any ("DISABLE", "DELETE", "REVOKE", "DEPROVISION")
| summarize Failures = count(), Latest = max(TimeGenerated)
        by TargetName, SourceName, EventAction
| order by Failures desc

And watch the pipeline itself. A silent collector means the governance layer is unwatched — treat it as a security alert, not a housekeeping one:

SailPointISC_CL
| summarize Latest = max(TimeGenerated)
| extend MinutesSinceLastEvent = datetime_diff('minute', now(), Latest)
| where MinutesSinceLastEvent > 30

When a normalised column doesn’t carry what you need, RawEvent has the original payload — extend parsed = parse_json(RawEvent) and work from there.

Validation checks

Constraints that look like bugs

Three of these fail silently — the pipeline keeps reporting success while doing the wrong thing. Worth knowing before you “fix” any of them.

What it does not do

Being straight about the gaps is more useful than a feature list.

• Everything is reached over public endpoints. Key Vault, Storage and the data collection endpoint accept internet traffic, gated by Entra RBAC rather than network position. On consumption-class hosting the outbound IPs are shared and variable, so IP allow-listing wouldn’t meaningfully narrow it either. Private networking — VNet integration plus private endpoints for all three — is not implemented. If your tenant requires it, treat that as work to do before adopting this, because disabling public access without it would sever the functions from their own credential store.
• Privilege is concentrated, not eliminated. Splitting the credentials removes the collector’s ability to manage tokens; it doesn’t remove that ability from the system. Whoever obtains the rotator’s PAT can mint further ISC credentials. That’s held behind the more restrictive identity rather than designed away — a credential that cannot mint its own replacement cannot self-rotate.
• This moves personal data into Sentinel by design. ISC events identify named individuals. Retention and lawful basis both need covering by whatever record your jurisdiction requires — in the UK, the ROPA and DPIA. Retention is a template parameter precisely so it’s set to an agreed figure rather than inherited.
• You cannot query events you never collected. The collector currently takes everything the search API returns for the window. Narrowing that cuts ingestion cost and cuts what you can investigate later.

Rollback / back-out plan

• Collection producing noise or cost you didn’t expect – raise collectorSchedule or narrow the search query and redeploy. Data already ingested stays and still bills for its retention period.
• A rotation you want to undo – you can’t un-revoke a PAT, but you don’t need to: seed a fresh credential by CLI exactly as at bootstrap, and the rotator adopts it on its next run.
• Removing the pipeline – follow the decommissioning step in the runbook. Delete the function apps first so nothing is mid-write, then the ingestion path, then the vault. Revoke the ISC PATs on the ISC side as well; deleting the Azure resources does not invalidate them.
• Keeping the evidence – the custom table and its data outlive the pipeline. Decide deliberately whether the table goes with it, because deleting it destroys audit history you may be required to hold.