One thing I’ve been thinking about is recommendations to clients around the leaver process when an IDNow admin leaves the company. As you likely know the VAs get their own API Key. It’s not unreasonable to assume, especially with this hot job market, that IDNow admins will move from company to company. However, currently there isn’t an easy way to change the API key for the VAs when a admin leaves.
Right now the recommended approach I’ve outlined is to replace the existing VAs in a cluster with a new set of VAs. That way you don’t need to re-enter the credentials for all sources associated with said cluster. What are some suggestions or practices you are using within your own company or for clients?
Besides in the UI, upon initial setup it’s quite easy to pull back the API key within the VA.
This is a good reminder not to record any sessions when setting up the VA because that’d be the same as having a recording that shows in plain text the user name and password. It’s also a good reminder to be mindful of who you invite to the VA setup call because anyone looking at the screen would be able to capture the details if they were so inclined.
This reminds me a lot of the process we run when a DBA or Linux/UNIX admin leaves and the need to rotate all the passwords on any servers they had access to. Except here instead of rotating passwords we’re rotating VAs.
@pmartinezclango - Ideally SailPoint would know this API key is specific to the VA’s and as such would only accept it’s use directly from the VA to mitigate any misuse.
Without this it’s literally uncontrollable and the only mitigation is as you noted - to change it which requires new config.yaml files to swap the existing VA for a new logical VA.
@MVKR7T You hit both of the important “keys”. I agree that your personal PAT should be disabled upon leaving the organization (employee OR contractor) by disabling your IDN account/identity.
The trickier keys are anything related to the VA which are in clear text during the setup process and anyone that happens to capture / store these could in theory use these to generate an access token and manipulate data within the client.
Without specific documentation from SailPoint confirming how the VA specific keys are treated within IDN we can only assume worst case scenario (i.e. they provide ALL access) and a bad actor could use these to cause havoc in an environment.
Knowing the vast majority of admins consider themselves professionals who wouldn’t act in a bad way, the risk in minimal. But the alternative of a disgruntled prior admin with VA full access keys creates a risk for every organization that needs to be accounted for.
The example of deleting a source is something you can do after leaving a client if you had the VA keys. The scope for the token is sp:scopes:all sp:scopes:default. I haven’t gone through all the APIs, but ideas that come to mind is creating a new identity and requesting access, extracting identity data, and so forth.
I wouldn’t pose the question otherwise
Colin confirmed the process. Ideally the token would be restricted for use to the network location of the VAs in the cluster to prevent misuse.
Another thing beyond the conversation of this thread is you could use a service to crawl all the IDNow tenants (you can see every customer who is on IDNow that’s not on vanity URLs quite easily) and then use NMap to scan for VAs or using Shodan and see if any of the VAs are using the default password. From there logon, grab the VA key, and have full access. This of course would be a completely different bad actor, but something that could happen if IGA products ever came into the crosshairs like Access Management solutions do.
The VAs have been interesting me from a security standpoint.
No problem. Now that @colin_mckibben confirmed this is the recommended practice we’ll just be adding it as part of our offboarding process for IDNow admins going forward. I love how @jordan_violet 's built a community where everyone can learn from each other.
