Uncorrelated accounts - How to detect incorrectly correlated accounts - Theoretical scenario

Hello Everyone,

I have a scenario(s) that I’d like to discuss options/thoughts on:

Tightening existing controls and SLAs is one thing but I need to balance security and reasonable controls. Note: this might be an environment that has 2000+ applications, 30,000+ users (this stat is useful as not all small environment solutions can be applied to larger organisations)

Scenario:

  • Disgruntled Admin Employee: An employee with access to a web application that lacks SSO (Single Sign-On).

  • Correlation Rule and Configuration: In IIQ, the correlation rule is based on the ‘email address’.

  • NCD is not applied on this application.

    Risk:

    1. Creation of Rogue Account:

      • The admin creates a rogue account with an email address that does not correlate with any existing identity in IIQ.

      • Termination of Employment:

        • The Admin employee is fired today.

        • Uncorrelated Account Visibility:

          • The uncorrelated account appears in in the uncorrelated accounts report

          • Potential Exploitation:

            • During the period before the uncorrelated account is deleted, the ex-employee could log into the web app portal using the rogue account.

            • Since the account is uncorrelated and not part of an automated leavers process, it wasn’t linked to any HR identity.

            • The ex-employee could:

              • Delete numerous staff accounts.
              • Cause an outage and business impact.
              • Affect clients.
              • Potentially lose historic data.
              • Leak PII (Personally Identifiable Information) by downloading information onto a personal device.

Investigation:

  • Once the uncorrelated account is discovered, an investigation begins.

  • Often, the account is simply correlated to an existing old identity cube without checking the lifecycle status. In this scenario, they would delete the account as there is no HR record to link it to.

  • We have a UAM process removes old access linked to identity cubes it finds.

  • There is a window of a few days or potentially weeks where unauthorised access and malicious activities could continue.

    ________
    Scenario 2:

    If I am a disgrunted admin of an application with no SSO who creates an additional account but uses an email address that correlates to an existing IIQ identity cube that has an inactive HR record) which is then missed until the next application user access review which is on a frequency based on the risk rating.

    ________

    Scenario 3:

    If I am a disgrunted admin of an application with no SSO who creates an additional account but uses an email address that correlates to an existing IIQ identity cube that has an active HR record) which is then only noticed in our reporting until the next application user access review which is on a frequency based on the risk rating.

Such a critical application exposed to internet without basic SSO - don’t you see big red flag here. I am not talking about MFA again for admin with highest privileges to the application. Even after assuming Sailpoint had all the features you needed like NCD Sailpoint is not right tool to detect fraud in real time.

Hello @sanjaysutarc  , of course there is a big problem with not having SSO enabled however, there are definitely assets out there that do not have it enabled.

The scenarios are specifically for assets that do not have SSO enabled.

The main question is, how do we promptly identify and pick up incorrectly manually correlated accounts.

Even if the asset is not critical and used for money movement, fraud, it can still cause damage to organisations.

Many companies approach IAM from a risk priority perspective. Targeting high risk assets first and then working towards the lower risk assets. I am also referring to an environment with 6000+ applications. It is unlikely all of these will have SSO enabled (even if that is a desirable outcome)

You can likely create reports or access reviews that app owners could review of all their uncorrelated accounts or create work items for them. As far as newly correlated accounts on inactive users, also something you could do with and identify certification using a trigger event, run reports on or create widgets to monitor in real-time.

Some many red flags here why is the org against SSO, or jump host or some other methods (IP restriction), why NCD not turned on. SailPoint is not SIEM solution never is and never will be, but if you want to track build a report and have 1 person in operation area doing this on weekly basis as a control if that’s acceptable. you can’t fix this w/ SP as bad data not matter what IGA tool will not help you identify who that person is if you don’t have any other unique identifier numerical number keys.

Hello @lennoz  ,

I understand that an organisation without SSO and NCD enabled for all their applications is a concern however, it’s a reality for some organisations hence the theoretical scenario to figure out whether or not this can be managed within SailPoint IdentityIQ.

Based on what you’re saying, it seems like an IGA tool is not the appropriate platform. Either pay for a tool that does handle this or add it as a regular operational task as a basic control until NCD and SSO is enabled.

I guess there isn’t a straight forward process to avoid these types of issues where SSO and NCD is not enabled. Guess that’s the purpose of SSO and NCD haha