Possible Identity and Management System Reports

Here are some of the IDMS Reports that I have seen in my past implementations that could be useful to anyone looking to extracting more value from their existing IDMS infrastructure.

Most of these assumes that you already had a way to correlate accounts to real people, and most of these accounts have login information readily available. The Unauthorised Reports assume also that you have some form of ticket request mechanism for users to request for new accounts/access, and it could be readily extracted for correlation.

Dormant Account Report

A dormant account report shows a list of accounts that are ‘dormant’: They have not been logged in/used over a specified period of time (also known as dormant period). Accounts that have logged in during this period typically should not show up in this report. Ideally, this list should be empty; there should be no accounts that are not used on a day-to-day basis.

If an account do appear in this list, the management needs to answer this question: Does the user really need this account access? If not, it should really be revoked. If he does need it, but access is infrequent, then the account should be marked as an exception in the report, and ideally no longer show up in future dormant accounts report.

Typically the dormant account report should only contain accounts that belongs to a real person. Accounts that do not belong on this list should be reported in orphan account report instead.

Orphan Account Reports

An orphan account report shows a list of accounts that are ‘orphan’: They are not associated with any real person. This report will typically contain administrative/service accounts like ‘root’ or ‘sysadmin’ that do not belong to any real persons. For this report to be of real use, these administrative/service accounts must be identified, and filtered out for any future use.

After the filtering, we will end up with a real list of accounts that logically should be tied to real people. Ideally, this list must be empty. If this list do show up, we could attribute it first to an inability to automatically link the account to a real person; the linking rule was not sophisticated enough to handle the edge case. If it is supposed to be genuinely orphan, then we might have a problem. Look into the last login date of this account to verify if it had been used, and run audit report of this account’s actions in the target application. Find out if there were any damage caused by this rogue orphan account.

And of course, don’t forget to disable/delete this account immediately to prevent any further damages.

Unauthorised Account Report

In most enterprises, you would have some form of request ticketing system when a person request for an application account/access. This could be an online web based system, or a paper base, and these typically involve some kind of manager approval before the identity & access management team process and creates the user accounts/access. Ideally, in both form, there is some kind of unique identification number for each request.

With such a system in place, we could correlate the request with the actual accounts we find in the systems. Thus we finally can come to the definition of unauthorised accounts: Accounts that exist in the target system but do not have a corresponding ticket requesting for creation, or accounts that still exist in the target system that has a corresponding ticket requesting for deletion.

Unauthorised accounts are a source of great concern, and especially if they are accounts with powerful administrative access. They must be carefully investigated, reviewed, disabled/revoked if necessary. There should not be any unauthorised accounts in the system. Exceptions could arise when the ticketing system is unavailable, but email/paper or other form of approvals had been found and manual account creation performed. In such cases, new tickets should be generated with these information as attachments to ‘authorise’ these accounts.

In a more ambitious case, the report could be extended to display unauthorised access, in cases where an account could have multiple access/privileges, and these requests are captured in the tickets properly.

Expired Account Report

Some user account access might be temporary. It could be for a duration of a project, or duration of the person’s stay in the company (contract staff with a specified time period). Once an application access is still valid after its validity period, it represents a risk of abuse. These accounts should be reviewed to ensure that they are still valid. If the managers has deemed them as valid, the expiry period should be extended. If they are no longer valid, they must be cleaned up immediately, either by disabling them or deleting them.

This could also be extended to include accounts where the person has left the company (resignation). Once a person has left, all his account access should be deleted/revoked. This report could include such accounts that are still enabled/exist in the target system.

Account Login Report

This is different from the dormant account report. Whereas the dormant account report aims to identify if there are any accounts that has not been logged in during a specified period of time, this report aims to find out when and how many times did an account logged in during a specified period of time.

Why do we need such information? One use case would be at least that if a user is meant to be on leave, and we see account logins, then it would be a big red warning flag. The account might be compromised and an unauthorised personnel is using the account to do damage.

Ideally this should be in real time, and handled by an Web Access Management tool that protects application access, so that we can get real time alerts and blocking the user before any damage can be inflicted. But if that is not available, this would be a nice second choice.

SoD Violation Report

In enterprises, you would typically have some form of Segregation of Duties. Person A might have an application user account that acts as a Maker in some of the tasks, and Person B might have an application use account that acts as a Checker for the tasks of Person A, approving them before they are processed. A person should not have an account that acts as both Maker and Checker, or should not have two accounts, one acting as Maker and one acting as Checker.

With such rules built into the system, a report of violating accounts could be generated. Each violation is a risk and must be carefully reviewed, and if necessary, the violating accounts disabled or revoked. If the violation is accepted by the management to be legit and necessary for the people to perform their daily work, the accounts must be marked as approved by the management, ideally only for a time period. This allows for the violation to be reviewed again in the future.

Such rules could be within a single application, or span across multiple application access. The rules can get really complex, and really depends on the risk appetite of the enterprise, and the amount of time they wish to invest in this, especially since such rules are dependent on how the business operates, and business do change from time to time.