Auditing software usage with EPM without precluding rule matches lower in hierarchy?

Hi ​@JayRob - that’s a great question, although possibly one without a single simple answer for every customer, as you’ve outlined! A key factor will be where the data needs to be available and how it will be used (e.g., is it being used for manual human analysis, or perhaps a trigger for some automated action like an alert or notification). 

I’m going to make some assumptions in my response, so feel free to correct them - but also know that some of the suggestions below may change based upon your feedback.

For many customers, and as a general baseline, most EPM policies do not audit events which are explicitly permitted, whether they are passive executed or elevated - instead focusing on exceptional events or explicitly blocked using catch all rules at appropriate locations within the rule structures.

If your deployment doesn’t make use of our QuickStart template, you may like to take a look at one (you can import them via your policy management interface), to review how they are structured and how the rules are configured, as a reference.

However, your use-case is fairly common and arises in various different scenarios (e.g., gauging application usage, looking for misuse/abuse of trusted applications etc.).

The easiest native route to deliver these audit events, is exactly what you’ve described - to create new application groups and associated rules, which implement the same behavior of your existing rules these applications/commands currently match. The new rules then have  the additional auditing options enabled - that may be local event logging, forwarding events to any management infrastructure, or using additional functionality such as scripts.

These new rules will sit immediately above their corresponding (existing) rules within your workstyle structures, ensuring the correct application behavior applies. In a normal deployment QuickStart based deployment, this would equate to just two new groups/rules - one above the elevation rule/group for the workstyle, and one above our passive allowlist (as neither of these have auditing enabled by default).

The reason I would suggest this is the easiest is that it creates a structure which you can easily move definitions into and out of, as your requirements to audit specific applications/commands might change over time. This also allows you to use features, such as disabling definition (or whole rules) or filtering rules within a workstyle to specific user groups, depending upon your auditing needs. 

I would suggest this is the most intuitive and simple approach - providing the most flexibility to support changes in requirements over time. It is also completely native, so is the easiest to review and troubleshoot.  However, there are certainly alternatives, which may suit different scenarios - but introduce additional considerations as you’ve outlined.

Audit Scripts (available for EPM-W) provide a possible alternative as they can allow scripted actions to be triggered in response to specific application rules being matched. This might include outputting bespoke audit events into a local event log (or even a file-based log), allowing more targeted logging and log collection - but introduces the requirement to identify the relevant applications/commands via the script, for it to be more desirable than simply auditing everything. This has the added complexity of managing and maintaining the list of targeted applications/commands compared to the application group approach previously outlined. 

Enabling more widespread auditing requires additional processing to find the subset of events which are relevant, as you’ve noted. In a security context, ingesting this additional data (and accepting the additional work and cost) may be acceptable to mitigate an identified risk, whereas for more ad-hoc project purposes like application usage, it may not. 

Depending upon the management platform you are using, you might also be able to consider retrieving data which has already been centralized, from available data interfaces, rather than directly from the endpoint. This may allow some intermediate data processing to occur to ensure only a subset is passed onto downstream systems where costs might occur. For on-premises deployments this takes the form of Export Views available in the PMR reporting database, whereas for PM Cloud deployments this is available via the Data API endpoints. 

Alternatively, if human analysis is going to be performed, manual exports of data from the reporting interfaces may be a valid approach - allowing analysis and filtering using external tools. 

I suspect much of that is just re-enforcing what you had already concluded, but hopefully there is some additional detail which is useful for you (and for others who may have a similar question, but who perhaps haven’t undertaken the same analysis already). 

Thanks Paul. This does re-enforce the options I was considering