by Business Analysis (BAPL).

When I was at school, like most kids we dreaded the annual report card. I have to say I had some good years and some bad ones. It pretty much depended on my teacher and the impression I wanted to make on all the other kids in class. But this usually led to some very ordinary report cards and my parents (well at least my father) wasn’t very happy to see negative comments on the report card and hence it usually ended badly.

This article is about reporting and audit in Identity Management. This often-forgotten area is quite critical to fine tune the IAM system, provide the forensic information that is needed if a breach of the security system occurs, and identify what identities have access to specific resources.

The primary function of the IAM reporting service is to record and report on identity activity. These reports may be short term or long term but provide a range of detail that is usually subject to storage and availability circumstances. One of the things that ANU couldn’t do in the breach in late 2018 and early 2019 was to identify what the hackers had stolen.

Not all IAM systems come with a complete reporting service, but many of the quality systems, those that are in the leaders quadrant of Gartners magic quadrant do. The range of reports is typically quite broad and accessing and setting up reporting is quite different across systems. This blog is about what reports you need and for what reason.

The approach to reporting is twofold. Firstly, you need to understand what the reporting can provide (i.e. what the system can do and how it does it). Then you need to understand what is required from reporting. (Of course this assumes you already have an IAM system in place, if that isn’t the case then the reverse is relevant, identify requirements and include these in the tender request).

As an example, at a recent engagement I had at a tertiary education institution, we required reports for each faculty to be provided monthly identifying all the identities that were associated with the faculty. This was to enable each faculty to be accountable for the temporary staff access and ensure that they were aware of the access that remained when a staff member left or was terminated and not correctly de-provisioned.

When assessing whether the reporting capabilities are sufficient, I look for a couple of items. These are:

1. Whether it is possible to create scheduled reports and have them sent automatically to a list of recipients. This typically would follow the requirements gathering where stakeholders have indicated they need specific reports to ensure the right people have access.
2. Whether custom reports can be created, as the systems will come with a number of preconfigured reports. (This might be something like 20 different reports)
3. What the process is to receive reports. Some systems use a subscription method, or a shopping cart style, which is my preference as this means there is an approval process. (i.e. you can request access to the report but a manager needs to approve whether you can receive it).
4. What detail is provided in the forensic reports for IAM activity.
5. How simple is it to capture a report on identity access for auditing purposes.

The last of these, the auditing can be quite complex. I know organisations that still do much of the auditing of identity access by exporting information from Active Directory into a spreadsheet and then working out what groups they are in, what access to applications is provided due to position or other attributes, and finalising the spreadsheet over a month or two to present to management or auditors. This is a critical requirement for gambling and lottery organisations as they need to comply with world and local gambling authority standards for access to systems.

Requirements Gathering.

With these points in mind, simple questions can be established to develop the requirements for reporting from stakeholders.

Questions like:

• What sort of information do you need, and how often?

This might have to follow meetings with the service desk who are usually responsible for providing the reports before the IAM system is implemented. In this case, understanding the pain point from service desk can help in phrasing the question to the stakeholder better. For example, if the report is already provided by service desk, the stakeholder may not want to change anything so just asking whether the current report is sufficient, or if more information is required might be better.

• Would you prefer to download these or have them sent on a scheduled basis?

This follows the first question of course as stakeholders probably don’t want to have to search for the report, however if they are informed that they can access a range of reports themselves, they might look to identify customised reports or other scheduled reports.

Implementation

The reporting service is typically implemented as a final step. It may provide a lot of the metrics that can be used in identifying and measuring the success of the IAM system deployment. I have about 25 different metrics that I use to measure the success of the project but there isn’t the room here to include those for now.

Forensics

Forensic reporting provides the evidence and traceability of identity activity in an environment. Kaspersky identifies the following common methods of data breach:

• Stolen Credentials: The vast majority of data breaches are caused by stolen or weak credentials. If malicious actors have your username and password combination, they have an open door into your network. Because most people reuse passwords, cyber criminals can gain entrance to email, websites, bank accounts, and other sources of PII or financial information.
• Compromised assets: Various malware attacks are used to negate regular authentication steps that would normally protect a computer.
• Payment Card Fraud: Card skimmers attach to gas pumps or ATMs and steal data whenever a card is swiped.
• Third-party access: Although you may do everything possible to keep your network and data secure, malicious actors could use third-party vendors to make their way into your system.
• Mobile Devices: When employees are allowed to bring their own devices (BYOD) into the workplace, it’s easy for unsecured devices to download malware-laden apps that give hackers access to data stored on the device. That often includes work email and files as well as the owner’s PII.

(https://usa.kaspersky.com/resource-center/definitions/data-breach)

These are of course not the only methods but continue to be the main methods used by hackers to access an IT environment.

I figure there are four stages of preventing and managing a data breach. These are:

1. Prevent unauthorised access to your corporate data. This is typically a domain of the firewall and security systems. This is the reason why IAM is often considered as a security component rather than as a desktop service, as it integrates with the firewall service to allow access to known identities only.
2. If this fails, then containing the data breach to a limited set of data is the best approach. Once again this is part of the IAM system, in effect managing the access each identity has to data through ACL’s or how the identity I provisioned to each target system.
3. If this fails, then the next step is to control the data breach. This means limiting the extent of the data breach itself, unauthorised access is available to hackers because they have compromised the credentials of a user. Ensuring that each user has proper access and authorisation to systems will limit what access to data that the hacker has available. Of course, hackers want admin access to systems which will provide unfettered access to all the data. Admin accounts should be managed carefully using a Privileged access management system.
4. Finally, if this fails and the hacker has compromised admin access to data, the remaining control mechanism is to record, report and notify the extent of the data breach. In this instance, the IAM system forensic reports can provide what access each identity has, and following this it is possible to identify what data has been “modified” at what time. It is also possible to record what data an identity accesses in real time, but this is a very resource hungry service and difficult to justify for cost / benefits

Identity Management systems provide feature rich reporting capability. While it is great to provide standard reports, when a data breach is experienced, these reports come into their own as it provides the detail that is required to ensure data security or the extent of the data breach is determined and understood.

Alas I couldn’t contain the extent of the backlash that was likely to result from my poor report card. I could however change the approach and ensure that the next year was a better one. It’s a pity we can’t do the same in the world of corporate data security.