Skip to content

[jumpcloud] Add PAM (Privileged Access Manager) events to services enum #18542

@dherceg-eyeo

Description

@dherceg-eyeo

Summary

The JumpCloud integration currently supports these service categories:

all | directory | radius | sso | systems | ldap | mdm

(from packages/jumpcloud/data_stream/events/manifest.yml, jumpcloud 1.17.1.)

JumpCloud's Privileged Access Manager (PAM) produces audit events for privileged sudo grants (temporary local admin elevation via the accessrequests API). These events are exposed by JumpCloud's Directory Insights API but are not collected by this integration because the services enum does not include a PAM category and the collector does not request PAM events.

Observed behavior

With jumpcloud 1.17.1 and services: ['all']:

  • POST /api/v2/systems/{id}/associations with additionalAttributes.sudo.enabled=true (standing admin grant) is ingested as event.action: association_change with full payload (sudo attrs, passwordSource, connection from/to). Works.
  • POST /api/v2/accessrequests with additionalAttributes.sudo.enabled=true (temporary admin elevation, JumpCloud PAM) produces nothing in logs-jumpcloud.*. An ES|QL hunt across event.action LIKE "*access*" OR "*pam*" OR "*elev*" OR "*privileg*" returns zero rows.

Proposed change

  1. Add PAM as a supported value in the services variable in packages/jumpcloud/data_stream/events/manifest.yml, and ensure all includes it.
  2. Update the httpjson stream template so the collector requests PAM events from Directory Insights when PAM is selected (or implicitly via all).
  3. Extend the ingest pipeline to recognize PAM event types and map them to ECS (event.category: iam, event.action set appropriately).
  4. Add a _dev/test fixture covering a PAM event.

Why

Temporary privileged access events are a high-value SIEM signal: they are the authoritative record of who got admin on which endpoint, when, and for how long. Without this change:

  • ISO 27001 A.8.2 (privileged access rights) and SOC 2 CC6.1 evidence collection miss the most relevant control.
  • Detection use cases (grants outside business hours, back-to-back grants on the same device, grants exceeding duration thresholds, grants to users who already have standing admin) are not implementable because the events never reach Elasticsearch.

References

Environment

  • Elastic Cloud stateful, Elasticsearch + Kibana 8.19.14
  • jumpcloud 1.17.1

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions