[New Integration] BeyondTrust EPM

[cpascale43]

Description

BeyondTrust Endpoint Privilege Management (EPM) enforces least privilege and just-in-time elevation for endpoints across Windows, macOS, and Linux. It logs authorization decisions, process execution in elevated or restricted contexts, blocks and user cancellations, and (where enabled) related I/O or keystroke telemetry. Security and IT operations teams use this data for least-privilege compliance, threat detection, and incident investigation.

The Elastic integration should ingest EPM audit and activity events from Windows, macOS, and Linux for use cases like detecting abuse of elevation (unexpected admin rights, blocked runs), measuring least-privilege adoption and audit evidence for privileged access.

Sample tenant available upon request.

Data scope

• Windows and macOS event IDs include:

Event ID	Description
100	Process has started with admin rights added to token.
101	Process has been started from the shell context menu with admin rights added to token.
103	Process has started with admin rights dropped from token.
104	Process has been started from the shell context menu with admin rights dropped from token.
106	Process has started with no change to the access token (passive mode).
107	Process has been started from the shell context menu with no change to the access token (passive mode).
109	Process has started with user’s default rights enforced.
110	Process has started from the shell context menu with user’s default rights enforced.
112	Process requires elevated rights to run.
113	Process has started with Custom Token applied.
114	Process has started from the shell context menu with user’s Custom Token applied.
116	Process execution was blocked.
118	Process started in the context of the authorizing user.
119	Process started from the shell menu in the context of the authorizing user.
120	Process execution was canceled by the user.
199	Process execution was blocked, the maximum number of challenge / response failures was exceeded.

• Linux: event categories documented include:
  • Accept and Reject status
  • The user’s pbrun environment when an attempt is made to run pbrun
  • Keystroke action events
  • Task status (if the task finished successfully or unsuccessfully)

References

• SIEM settings EPM-WM Cloud
• EPM Elastic events EPM-WM Cloud
• SIEM connections EPM-L
• Events EPM-L

[github-actions]

tl;dr: I recommend creating a new packages/beyondtrust_epm package using the existing EPM CEL integrations as the template (admin_by_request_epm for minimal scaffold, cyberark_epm for multi-stream pattern), rather than extending beyondtrust_pra.

Recommendation

Build BeyondTrust EPM as a new integration package (packages/beyondtrust_epm) with an EPM-style CEL API structure and test fixtures from day one. Start with one stream for fastest delivery, then expand to multiple streams if the API/event model requires it.

Findings

• Existing BeyondTrust package is PRA-specific, not EPM-specific:
  • packages/beyondtrust_pra/manifest.yml:1-4 (name/title/version)
  • packages/beyondtrust_pra/data_stream/access_session/manifest.yml:1-8 (single access_session stream)
• Existing EPM integrations already provide proven scaffolds:
  • packages/admin_by_request_epm/manifest.yml:34-42 (policy template + CEL input)
  • packages/admin_by_request_epm/data_stream/events/manifest.yml:1-9 (data stream structure)
  • packages/cyberark_epm/manifest.yml:2-5 and :32-39 (EPM package + CEL policy template)
  • packages/cyberark_epm/data_stream/raw_event/manifest.yml:1-8 (streamed API ingestion pattern)
• CI/test workflow already codifies expected validation steps:
  • .buildkite/scripts/common.sh:838 (elastic-package check -v)
  • .buildkite/scripts/common.sh:871 (elastic-package install)
  • .buildkite/scripts/common.sh:884 (elastic-package test ...)

Related prior work (not duplicate implementation evidence for BeyondTrust EPM):

• Issue #14382 (processor migration across existing integrations, includes beyondtrust_pra/cyberark_epm references)
• PR #13573 (docs cleanup including beyondtrust_pra)

Verification

I validated repository evidence and local tooling availability in this runner:

$ mage -l
bash: mage: command not found

$ elastic-package version
bash: elastic-package: command not found

So I could not execute package tests in this environment, but CI scripts and docs provide the authoritative command sequence.

Detailed Action Plan

1. Create packages/beyondtrust_epm/ by copying minimal EPM skeleton from:

   • packages/admin_by_request_epm/manifest.yml
   • packages/admin_by_request_epm/changelog.yml
   • packages/admin_by_request_epm/docs/README.md

2. Add initial stream data_stream/events/ with required files patterned from:

   • packages/admin_by_request_epm/data_stream/events/manifest.yml
   • packages/admin_by_request_epm/data_stream/events/agent/stream/cel.yml.hbs
   • packages/admin_by_request_epm/data_stream/events/elasticsearch/ingest_pipeline/default.yml
   • packages/admin_by_request_epm/data_stream/events/sample_event.json

3. If BeyondTrust EPM API exposes distinct event families, split into multiple streams (like CyberArk):

   • reference packages/cyberark_epm/data_stream/*/manifest.yml

4. Define package-level config in manifest.yml:

   • endpoint URL + auth secrets + interval + timeout + proxy + SSL
   • mirror proven var patterns from admin_by_request_epm and cyberark_epm

5. Add fields and ECS mapping incrementally:

   • begin with core ECS + namespace fields in fields/*.yml
   • map unknown vendor fields under beyondtrust_epm.*

6. Add tests immediately:

   • _dev/test/pipeline/test-*.log
   • _dev/test/pipeline/test-*.log-expected.json
   • _dev/test/pipeline/test-common-config.yml
   • _dev/test/system/test-default-config.yml
   • use packages/admin_by_request_epm/data_stream/auditlog/_dev/test/system/test-default-config.yml:1-23 as baseline pattern.

7. Validate with CI-parity commands once elastic-package is available:

   • elastic-package check -v
   • elastic-package install
   • elastic-package test -v
   • plus focused elastic-package test pipeline --generate during fixture authoring.

8. Open initial PR as “MVP stream only”, then follow-up PR(s) for additional stream(s), dashboards, and docs enhancements.

Related Items

Type	Link	Relevance
Issue	#14382	Cross-integration ingest processor migration; mentions beyondtrust_pra and EPM integrations
PR	#13573	Documentation updates touching beyondtrust_pra
File	packages/beyondtrust_pra/manifest.yml:1-4	Confirms existing package targets PRA
File	packages/admin_by_request_epm/manifest.yml:34-42	Minimal EPM CEL package template
File	packages/cyberark_epm/data_stream/raw_event/manifest.yml:1-8	Multi-stream EPM ingestion reference
File	.buildkite/scripts/common.sh:838,871,884	Canonical check/install/test flow in CI

Note

🔒 Integrity filtering filtered 52 items

Integrity filtering activated and filtered the following items during workflow execution.
This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.

• issue:[New Integration] BeyondTrust EPM #18166 (issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #18166 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #17360 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #15075 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #15147 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #17361 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #16937 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• issue:SSI Integration: Use 'terminate' processor instead of 'fail' for integrations with stack version 8.16 or higher #14382 (issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #14725 (search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #14697 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #12023 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #11795 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #4895 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #752 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #18164 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• #14187 (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
• ... and 36 more items

---

What is this? | From workflow: Issue Triage

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.