Audits and reports

Endpoint Privilege Management for Windows sends events to the local Application event log, depending on the audit and privilege monitoring settings within the Endpoint Privilege Management for Windows policy.

Additionally, BeyondTrust provides an enterprise level, scalable reporting solution in Endpoint Privilege Management Reporting. Endpoint Privilege Management Reporting includes a rich set of dashboards and reports designed to simplify the centralized management and auditing of Endpoint Privilege Management for Windows activity throughout the desktop and server estate. Each dashboard provides detailed and summarized information regarding Application, User, Host, and Workstyle usage.

Events

The following events are logged by Endpoint Privilege Management for Windows:

Each process event contains the following information:

• Command line for the process
• Process ID for the process (if applicable)
• Parent process ID of the process
• Workstyle that applied
• Application Group that contained the process
• End user reason (if applicable)
• Custom access token (if applicable)
• File hash
• Certificate (if applicable)

ℹ️

Note

Each process event also contains product properties, where applicable, but these can only be viewed in the Endpoint Privilege Management Reporting Console.

Audit with custom scripts

When an application is allowed, elevated, or blocked, Endpoint Privilege Management for Windows logs an event to the Application event log to record details of the action. If you want to record the action in a bespoke or third-party tracking system that supports PowerShell or JScript based submissions, you can use the Run a Script setting within an Application Rule.

To add a new auditing script:

1. Create a new or edit an existing Application Rule within a Workstyle.
2. In Run a Script, click on the Off value and in the dropdown menu, select Manage Scripts to open the Script Manager.
3. In the Script Manager, click New in the left tree view. A new script is added to the tree. Click the name New Script once to rename the script.
4. In the right script editor, enter your script code either manually, by copy and paste, or you can import a script from file by clicking Import.
5. In the Script Language dropdown menu, select either PowerShell or Javascript, depending on the code format you entered.

ℹ️

Note

PowerShell audit scripts can only be run in the system context.

1. Select a Timeout for how long the script will be allowed to execute, before it is terminated. By default, this is set to Infinite.
2. Select whether the script should be executed in the System context or the current User context from the Script Context dropdown menu.
3. Click OK to finish.

The new script is automatically selected in the Run a Script setting.

ℹ️

Note

If you have any existing scripts, these can be selected in the dropdown menu.

The auditing script supports the use of parameters within the script. Parameters are expanded using the COM interface PGScript.

Example

strUserName = PGScript.GetParameter("[PG_USER_NAME]")
strCommandLine = PGScript.GetParameter("[PG_PROG_CMD_LINE]")
strAgentVersion = PGScript.GetParameter("[PG_AGENT_VERSION]")

ℹ️

Note

Scripts created in the script editor can be reused in multiple Application Rules and On-Demand Application Rules. Any modification to an existing script affects all Workstyle rules that have been configured to execute that script.

📘

For a list of available parameters, see Policies and templates.