SailPoint takes the security of our products very seriously. We’re a key part of the cyber ecosystem, and it’s essential that we gather insights on security concerns from all sources, including this community.
As an example, @angelo_mekenkamp recently found a condition in which one type of admin was able to assign themselves different admin roles, thereby escalating their privileges. And while all admins are intended to be trusted individuals, this was a design flaw with security implications, and our teams worked with Angelo to develop a fix (which is now live). I’ll leave it to Angelo and the SailPoint product owners to share the details.
In the course of our collaboration with Angelo, we realized two things.
First, our intake process for security issues from this community needs refinement to make sure we’re getting the right attention as quickly as possible. To that end, I’ve asked Angelo to join other members of the community on a working group to develop a streamlined, prioritized reporting process for SailPoint partners to share security concerns. I expect to have that new process defined and shared by Navigate.
Second, we realized that we’re leaving a lot of talent and value on the table by not fully engaging with this community on targeted security concerns. Our developer community knows SailPoint as well as anybody, and we should be actively cultivating your help in improving the security of our products. With that in mind, @taylor_wingfield is creating an incentive structure for encourage engagement on security topics. More details to follow on that.
Thanks again to everybody for all you do, security and otherwise. SailPoint cherishes its community, and we’re glad to have you on board.
Thank you for this post @Rex_Booth and for your kind words!
It is a pleasure to be part of this community, and I am looking forward to what the future brings!
To give some insights on the matter. I discovered this security vulnerability, where, as a lower level admin, one could make themselves a full org admin without requiring intervention by others. It was possible to do this as user levels including ORG_ADMIN were treated as entitlements in the native source called IdentityNow (or Identity Security Cloud depending on when your tenant was created) and as such could be added to a newly created role or access profile without approval flow and this could then be requested by the role admin and source admin for themselves.
One might argue that role admins and source admins are highly vetted (or should be, given their authorization) and could therefore be trusted to not perform these steps, but from a least privilege perspective this should not be possible. If a malicious actor finds its way into obtaining access to an identity with such a lower level admin user level, they can already do damage, but if they are then also able to elevate their privilege more without intervention, the potential impact will rise as well. To prevent this to be a step in the kill chain of a malicious actor, this security vulnerability needed to be addressed.
After following the process of reporting this finding internally, which included productive discussions with the CISO of SailPoint and other stakeholders, I am happy to see that this released functionality will now prevent malicious actors from hacking themselves to full admin access using this elevate privilege trick.
Please note though that if your tenant is using any kind of loopback connector, whether it is the out of the box Identity Security Cloud Governance connector, a custom build web services connector or custom build SaaS connector, this trick can still be used via those connectors. After all, that is the effect you create by choosing to use a loopback connector which will then create similar entitlements representing the user levels. To prevent this trick from being used, one could decide to stop using the role admin and source admin user levels, and instead use role sub-admin and source sub-admin user levels and ensure that these loopback sources are not associated to any governance groups whose members contain these sub-admins.
Regarding your question @BenNelson, This security vulnerability (which is now fixed) was based on the fact that the native source IdentityNow had user levels that were behaving as entitlements and could therefore be used by role admins and source admins for creating roles/access profiles. Since the report admin is not authorized to manage access items to begin with, this was and is not applicable to the report admin. So unless you have specifically created a process (like a role without approval flow) to allow so (which is not there out of the box), I don’t see how a report admin could elevate themselves to org admin. So my answer would be no, this is not possible.
I was just asked this the other day by our audit team. They want to be able to view everything on their own without having to log ticket to our internal support for a screenshot.
@colin_mckibben I think @angelo_mekenkamp should at least get 2000 Ambassador points for this security finding! (Vertically elevating admin privileges)
So he will remain an Expert Ambassador for an additionally 3 Months.
I do agree here with @Remold as i have seen the contribution that @angelo_mekenkamp makes on new anouncements by sharing his perspective , security vunerabilities and overall developer community. I would say, if there is any higher level than expert amabsaddor then Angelo definitely deserves it .
But great work here and glad that security vunerability was spotted and rectified on short notice.
