Reference Users – An Underestimated Risk

We all know what reference users are, even if we don’t know that that’s what they are called. The story usually goes something like this: A new person – in our case Sarah – joins the company. The IT department now has to create a user for her in order to give her access to resources specific to her department.

Without an access management or identity and access management software, the IT admin is forced to create Sarah’s user and assign her the appropriate privileges manually.

Since the admin does not know which access rights Sarah’s position requires, he asks Sarah’s manager, who replies: “Oh, Sarah‘s job is the same as Gary’s.” So the admin simply duplicates all of Gary’s accounts to create Sarah’s user for Active Directory® and SAP®.

There is a reason, of course, why admins like to duplicate existing users to create new ones: it’s fast and it’s easy. Not that creating new users in the AD is overly complicated – but it’s more than a click: Admins have to use the server manager to make a couple of configurations, e.g. to assign the new user to the correct groups and organizational units.

The larger the company, the more it takes to manage all those accounts and rights. The “quick and dirty“ method of copying a user in the Active Directory® is literally done with a single click:

At first glance, this method seems pretty great, doesn’t it? Not only does it save time, it also gives Sarah all the privileges she needs for her job at one click.

Here’s the thing, though: Do you really think Gary and Sarah need the 100% exact same access rights?

SAP generally supports the use of reference users as a means to classify users. However, SAP also explicitly points out that users can/should only inherit other user classifications if:

The reason why reference users pose a security risk is a fallacy admins often hold to: While they think they are merely copying the reference user’s current departmental privileges for the new user, what they are really doing is transferring all of Gary’s privileges, which he collected throughout the years, to Sarah – including access rights for various departments and branches, as well as special project-related rights.

The longer reference users are used, the more chaotic access landscapes become. Ask any IT officer and they will confirm this thesis. One reason why reference users are a problem is that they endanger internal data protection. Because, if nobody is able to trace who has access to what resources and data anymore, the risk for employee data theft rises significantly.

The next issue is external attacks: The more privileges a user has, the more catastrophic the consequences of malware or ransomware attacks and phishing mails can be.

Administrators use reference users to save time when creating new users. But there is another way to do this without compromising security: Not only will an access management software make reference users unnecessary, it will also ensure that access structures are built in accordance with compliance policies.

The motivation behind using reference users is fairly simple: copy-pasting saves time. The access management software tenfold uses standardized rights profiles to replace the copy-pasting process. These profiles only have to be set up one time. Once that is done, they can be used as needed to assign access rights to users automatically across systems (e.g. Active Directory®, SAP® etc.), based on user attributes such as department or location. This makes duplicated users unnecessary.

What’s more, users can request access rights they deem necessary themselves via tenfold’s self-service function. As part of a workflow, data owners can then confirm or reject these requests or set a time-limit for them, which is especially useful for project-based work. You can also modify the default privileges contained within profiles, which is one of the features that sets tenfold apart from inflexible role-based systems provided by competitors.

So far, we have learned that tenfold assigns the appropriate access rights automatically. But what about all the unnecessary privileges that existed prior to tenfold?

No problem, tenfold takes care of this issue as well: Once installed, the software compares all current standard privileges with its profiles and updates those privileges accordingly. Sound good? Well, it gets better still. While the initial alignment of privileges is an important first step, it is not enough to carry us safely across the flowing river of access rights – which is why tenfold comes with another safety boat: the user access review.

As part of a user access review, data owners are “forced“ to regularly review all permissions they are responsible for and to either reconfirm or remove them. There is also a third way of removing superfluous access rights, which we have outlined for you here.

What happens to a person’s privileges if that person changes to another department or leaves the company altogether? tenfold has a solution: it simply revokes the privileges automatically on the set leaving date. For department changes, tenfold can be set to revoke permissions after a transition period.

For instance: let’s assume Gary wants to train his successor Sarah before moving on to his new department. In this case, tenfold will see to it automatically that Gary gets to keep his old privileges and gets those for his new department for the duration of one month, based on predefined profile settings.

At the end of the 1-month transition period, tenfold automatically withdraws Gary’s old rights. And do you know what? During the whole process, our admin didn’t have to lift a single finger.