[ESET PROTECT] Add device inventory and CDR vulnerability findings data streams (v2.3.0)

[m11tch]

Suggested label: Enhancement (pick the matching GitHub label)

WHAT

Adds two new data streams to the ESET PROTECT integration at v2.3.0:

device — Collects managed device inventory from the ESET Device Management API (/v1/devices). Maps device identity, OS, hardware profiles, and network adapters to ECS (host.*). Uses an _id fingerprint on device.uuid to deduplicate inventory records across polls. Includes MAC address extraction, OS type/platform/family normalisation, and hardware profile camelCase → snake_case renaming via Painless scripts.

device_vulnerability — Collects per-vulnerability records from the ESET Vulnerability Management API (/v1/device-vulnerabilities). Supports all three ESET vulnerability types (application, OS, package) and maps them to ECS vulnerability.* and package.* fields. Includes a latest transform (latest_cdr_vuln) that writes to the security_solution-eset_protect.vulnerability_latest alias consumed by Kibana's CDR vulnerability findings panel. Each poll emits fresh documents (no _id fingerprint) so the transform destination stays current and the 2h retention policy correctly ages out remediated vulnerabilities.

detection (updated) — The detection stream previously only carried host.id (device UUID). Since the ESET detection API returns only a deviceUuid with no host metadata, a two-phase CEL collection cycle is introduced: Phase 1 pre-fetches the full device inventory and builds an in-memory UUID → device info map; Phase 2 fetches detections and embeds host.name, host.ip, and host.os.* into each event at collection time. This makes host context visible in the Kibana host flyout without requiring the entity store. The device pre-fetch is best-effort — a Phase 1 API failure falls through to Phase 2 with an empty map so detections continue to flow without enrichment.

WHY

ESET PROTECT customers using Kibana Security need:

1. A device inventory view for asset management (device stream)
2. Vulnerability findings visible in the Kibana CDR vulnerability panel (device_vulnerability stream + transform)
3. Host context (IP, OS) in the Kibana host flyout when investigating detection alerts (detection stream enrichment)

The ESET API design requires the two-phase detection approach because — unlike CrowdStrike, SentinelOne, and Microsoft Defender — the ESET detection endpoint returns only a deviceUuid reference with no host metadata inline. The device pre-fetch is the only way to enrich detections without a separate lookup at query time.

The vulnerability transform does not set vulnerability.score.base from ESET's riskScore field because ESET's score uses a 0–100 proprietary scale that is not comparable to CVSS (0–10). The field is declared in the transform destination mapping to satisfy the CDR panel's sort requirement, but left unpopulated. ESET's risk score is preserved in eset_protect.device_vulnerability.risk_score.

Note for reviewers: The latest_cdr_vuln transform destination index requires the kibana_system built-in role to have read access to logs-eset_protect.device_vulnerability-* and manage/write access to security_solution-eset_protect.vulnerability_latest*. A follow-up PR to the Elasticsearch repository will be needed to update the role after this integration merges.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

How to test this PR locally

1. Configure the ESET PROTECT integration in Kibana Fleet with valid credentials and region
2. Enable all three data streams: detection, device, device_vulnerability
3. Verify device inventory appears in logs-eset_protect.device-* and host metadata (IP, OS) is visible in the Kibana host flyout from detection events
4. For the CDR vulnerability panel, manually create the transform destination index template and transform as described in the note above — this step will be automatic post kibana_system role update
5. Navigate to Kibana Security → Findings → Vulnerabilities and confirm ESET findings appear with correct title, severity, CVE, and vendor

Screenshots

[cla-checker-service]

💚 CLA has been signed

[elastic-vault-github-plugin-prod]

Reviewers

Buildkite won't run for external contributors automatically; you need to add a comment:

• /test : will kick off a build in Buildkite.

NOTE: https://github.com/elastic/integrations/blob/main/.buildkite/pull-requests.json contains all those details.

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[m11tch]

I've signed the CLA in the meantime.

[efd6]

/test

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: 29f3f3e

Failed CI Steps

• Check integrations eset_protect

History

[efd6]

Pipeline test failure:

test case failed: one or more problems with fields found in documents: [0] field "host.mac"'s value, 11:22:33:44:55:66, does not match the expected pattern: ^[A-F0-9]{2}(-[A-F0-9]{2}){5,}$
[1] field "host.mac"'s value, AA:BB:CC:DD:EE:01, does not match the expected pattern: ^[A-F0-9]{2}(-[A-F0-9]{2}){5,}$
[2] field "host.mac"'s value, AA:BB:CC:DD:EE:FF, does not match the expected pattern: ^[A-F0-9]{2}(-[A-F0-9]{2}){5,}$

[github-actions]

TL;DR

Check integrations eset_protect is failing because the new device sample event uses a colon-delimited MAC address that violates ECS host.mac validation. Update the sample to hyphen-delimited uppercase format and re-run package tests.

Remediation

• In packages/eset_protect/data_stream/device/sample_event.json, change host.mac[0] from AA:BB:CC:DD:EE:FF to AA-BB-CC-DD-EE-FF (and keep any matching raw sample values consistent).
• Re-run: elastic-package -C packages/eset_protect test static -v (and then the full test_one_package.sh job).

Investigation details

Root Cause

The static test Verify sample_event.json for eset_protect/device fails ECS validation for host.mac.

• Source evidence: packages/eset_protect/data_stream/device/sample_event.json:94 currently contains "AA:BB:CC:DD:EE:FF".
• Expected pattern from validator: ^[A-F0-9]{2}(-[A-F0-9]{2}){5,}$ (hyphen-separated, uppercase).

Evidence

• Build: https://buildkite.com/elastic/integrations/builds/43271
• Job/step: Check integrations eset_protect
• Key log excerpt (local reproduction on PR commit 29f3f3e7f4d4d4b26d8efd8e3f3ddb3d6eb00af1):

FAILURE DETAILS:
eset_protect/device Verify sample_event.json:
[0] field "host.mac"'s value, AA:BB:CC:DD:EE:FF, does not match the expected pattern: ^[A-F0-9]{2}(-[A-F0-9]{2}){5,}$

Verification

• Buildkite log snapshot provided to this workflow is truncated to teardown lines, so the failing assertion is not visible there.
• Running elastic-package -C packages/eset_protect test static -v on the PR commit reproduces the failure deterministically.

Follow-up

• After updating the sample MAC format, re-run CI to confirm Check integrations eset_protect passes end-to-end.

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• [ESET PROTECT] Add device inventory and CDR vulnerability findings data streams (v2.3.0) #19139 pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #19139 pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

---

What is this? | From workflow: PR Buildkite Detective

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