Enterprise Compliance For Business Managers

I spent a number of years acting as a Line Manager for a team of Identity & Access Management specialists at a time when there was increasing focus on compliance controls within the organisation. Certifying that my employees only had the systems' access rights that they required for their job was a quarterly event to look forward to.

Being told that Joe Bloggs can access System X with a role of Developer might seem like sufficient information for me to testify that the this is appropriate, but I would have to have made an assumption that developer access on System X has been correctly configured by whomever configured the system. What would the impact be if the administrator of System X had inadvertently given superuser access to those users in the developer group?

Traditionally, we have merely accepted that assigning users to groups is enough to satisfy our legislative requirements. But this is not the case! We also need to attest that the lower level permissions have been configured appropriately.

So what if we could find a way to deliver the lower level permissions to the Line Manager during his quarterly certification? What if I could see that superuser access had been inadvertently granted to my set of developers on System X?

This raises another problem, though. Lower level permissions on various systems take the form of data values which may be meaningless in their own right and therefore not in a format that would allow a Line Manager to understand them. As an example, informing a Line Manager that their employee has access to a system which means they have been assigned the value of S to the attribute ACCESS_RIGHTS. What does S mean? Standard? Super? Something-Else?

So what if we could provide the details in a manner which is more meaningful for the Line Manager?

I've spent some time in the recent past working on a mechanism to augment these lower-level permissions to provisioning data in such a format, thus enhancing the attestation experience of access certifiers but also as a means of validating that systems have been configured properly (and, as a consequence, the ability to perform lower-level Segregation of Duties checking).

The result of this work has been documented by Alan Harrison and is now available on the Pirean website. The work shows how low-level attributes held in RACF can be presented in a meaningful way through the IBM Tivoli Identity Manager interface. The principles, however, can be applied to any credential storage mechanism.

How I wish I had had that ability when I was a Line Manager!