We’re introducing SoD audit events that capture when SoD policy definitions are created, updated, or deleted.
Background
Compliance teams utilize Separation of Duty policy to adhere to internal and external regulations that dictate an identity may not have ability to perform two functions. A common example of an SoD policy is ensuring someone cannot both write checks and cash checks. Customers create a SoD policy for toxic access using access items (entitlements).
Current Situation
An auditor may review SoD policies during a quarterly audit to evaluate whether the policy definition aligns with the applicable regulation. For example, the auditor may review cases where ISC detects a violation of the write-check/cash-check SoD policy.
Problem
Audit durations can increase when Compliance teams are unable to easily provide evidence that the write-check/cash-check policy has not materially changed since the last audit.
Solution
Policy Audit events written to SailPoint audit event service for create, update, and delete SOD policy.
This appears that it shows the fields that were changed, but not their previous values before they were changed. Is that accurate?
I recognize that audit events are up to individual teams to determine what data to feed in, but other teams have included data like the previous value and the new value for all attributes that changed
Hi Mark, correct. I’d like to prioritize, some fields are text blobs that maybe less valuable as we drive the future of SOD. I am thinking …
The current fields:
“name”,“description”,“ownerRef”,“externalPolicyReference”,“compensatingControls”,“correctionAdvice”,“state”,“tags”,“violationOwnerAssignmentConfig”,“scheduled”,“conflictingAccessCriteria”
Here would be priority - like your feedback - for before/after logging in the event prioritization:
“state” (enforced or not), “name” (reference past reports), violationOwnerAssignmentConfig (don’t want a dummy/compromised), ownerRef (don’t want a dummy/compromised)
Looking into “conflictingAccessCriteria” (material change) - due to size may get truncated so that field might need a better long term solution (versioning?).
I think you’re on the right path. You’re considering what changes are “material” to the policy. That’s exactly what an auditor would want to see.
It’s not quite enough to know just what fields changed. They’re going to want to know what about them changed.
Was any of the conflicting access changed? Was new access added?
Was the policy owner changed?
In my opinion the most important part of the policy changes needing to be notated are the values for conflicting access.
IDK what length you’d start getting into truncation issues, but consider looking into role membership criteria as an example. Those would typically have a lot of data. Or the connectorAttributes property on a source
Idea GOV-I-3607
By RSVP’ing to this event you will be reminded of this release prior.