I’m trying to figure out the best method to allow our Security Operations Centre (SOC) to set a lifecyclestate of “compromised” for a list of users in bulk (rather than setting the state on one identity at a time through the web interface) when they detect an intrusion.
Scenario: A cyber security intrusion is detected by our SOC, with multiple AD accounts suspected of being compromised - ie a bad actor has the username\passwords of multiple accounts. These accounts have to be disabled asap. We have a lifecycle state of “compromised” which disables the AD account. An SOC member of staff needs to set the lifecycle state to “compromised” for the list of AD usernames - in bulk.
The data isn’t in the authoritative sources.
We’ve had 3 thoughts on how to do this:
a generic flat file source (compromised accounts) - the SOC uploads the list of ad accounts into this source. The identity profiles have an IdentityAttribute (lets call it “Reported Compromised” linked to that source, and a transform that returns “true” if the Identity’s Ad username is found in the source. The automatic lifecycle state transform sets the lifecycle state to compromised if the “Reported Compromised” identity attribute is “true”.
a powershell script that takes a csv of usernames, calls the search api to get the ID’s of the users, then calls the api to set the lifecycle state to compromised.
a workflow that somehow takes a file, calls the search api to get the ID’s of the users, then calls the api to set the lifecycle state to compromised.
Has anyone implemented a method for dealing with this type of scenario? How did you approach it?
It seems like an identity solution should have something baked in for disabling accounts that are compromised in cyber security attacks, but if IdentityNow has something for that - I haven’t found it yet.
If the solution needs to be made available immediately then i would suggest you can use the first approach and when ever a new account is found compromised, then you can use a transform to set the identity LCS as compromised. But this will require manual effort to keep uploading these users in ISC.
If you have the connection (source) to SOC system or some other system which has the information about whether user is compromised or not and the ISC has the connection to it, then you may also update the mapping in identity profile to check this account attribute from SOC source. For this, the SOC source does not have to be authoritative and just a normal source should do the trick.
So you can read this account attribute which determines whether the account is compromised or not (by even using transform accountAttribute) and when ever identity referesh or aggregation happens, it should automatically set the user to right cloud lifecycle state.
Your SOC/SEIM might even have a triggered generic web service capability already. (Alot of these systems have “condition matched” → “Trigger response” features). If it doesn’t yet have that capability, it might in a future version, you would be able to just drop the PS portion and keep going with most of your existing work.
I am not sure making the SOC/SEIM a directly connected source is fast enough. making it a source would mean ISC would periodically aggregate/check (hourly?) …that might be too slow for this use case. unless you also have a way, the SOC triggers the aggregation.
IMO this scenario needs a triggered/pushed method. A file upload causes an aggregation, an API call updates the user, etc.
Option 2 as you can have an evidence trail and in the PSScript you can catch errors and have ad-hoc disable operations invoked for the said compromised accounts.