Reflections from Identity and Access Attestations Exercise

For my last project, I had to roll out an annual attestation of the all the user’s access in the enterprise. Here are some of the reflections from the exercise.

Use the Person’s Known Name

We typically create user profiles from a HR source. But sometimes, our names on the HR system is not the name our colleagues typically known us as. It could be because the first/last names we had in HR are our registered identity card name, yet we had an english name we always introduce ourselves to others. This is especially true for Chinese, who had very hard to pronounce names.

When we present those names as a list of direct reports to the manager, they might not even have any idea who these people are! There would be confusion, and maybe even help desk support calls. This issue would not have happened if HR had a known as name, or if they is not accurate enough, have IDMS correlate each person with an optional known as name. Present the known as name to the managers on top of the first/last name.

Friendly Application and Access Names

Friendly really in the sense that the business managers understand them, not just the user. An IT application name of “Project Hercules” is really not useful to the business manager reviewing the people’s access. It should be something like “Financial Systems”, “Leave Approval System”, or the most ‘layman’ term you can think of.

Same goes for access rights. A technical term like “Workflow Approver” might not make sense, but a friendly business description of “Approves the user requests” would goes mile in allowing the managers to know what the access really is for. And reduce the support calls they might make to the identity and access management team

Allows Re-assignment

During attestation, a business manager would be given a list of direct-reports, as best as the system can determine. The source of the direct-reports is important, and might be at times inaccurate. Or the person might have been transferred to another manager. In such situations, it is important that the system used to perform attestation allows such re-assignment of personnel to another manager, thus completing his own attestation report. The re-assigned personnel should be attested by the new manager.

Simplify User Access Display

It is common for a person to have multiple application accounts, and each account might have multiple access tagged to each account. For a business manager, it is simply overwhelming, and it is very likely that the manager do not really know which is really necessary, and would have to approach the person to discuss if he really needs the access. A malicious person will not admit that he has excessive access. The managers really need help to ensure that the attestation is completed quickly, and accurately.

One approach to resolve this is to group multiple user access as application, or organisation roles. Organisation roles, especially, will significantly cut down on the number of items that a manager has to attest to. In addition, organisation roles are much more relevant to business context, and the manager can relate to it easily compared to the application roles. This, however, requires significant amount of effort to implement, and the organisation has to be vigilant in maintaining and updating the roles, especially during massive re-orgs.

The next approach is to simply hide all the baseline accesses. For example, if everyone should have an Active Directory lAN ID, then the access would be hidden. If everyone is supposed to be part of an application group “Normal User”, then it will be hidden. Take a step further and apply this to baseline role access, and the managers will only need to attest to ‘exceptions’. This would significantly reduce the number of access managers have to attest to, as every other access has been determined to be the normal access each person should have.

Highlight Risky Access

Not all accounts and access are equal. Some systems are more sensitive than others (like your payroll), and some access are more sensitive than others (like the ability to delete you from the payroll). Another candidate of risky access is SoD violation access. Hence, we really need only the right and minimal number of persons with those accounts and access. Call out these access during attestation, ideally by highlighting it with colour. But more importantly, explain why they are highlighted.

Allow Temporary Attestation

Some access might be temporary. It will be useful for a manager to mark such access as so, with an expiry date.

Of course, such a functionality begs the question of what happens when the expiry date is reached. One could always automatically disable / revoke the account access, though the better approach is to trigger an attestation of that access again to the manager, allowing the manger to request to extension if necessary.