Exabeam Admin cheat sheet

The New-Scale Platform is Exabeam's cloud-native security operations stack: data lake ingestion, correlation, UEBA/ABA analytics, and case management delivered as SaaS or in a customer cloud tenancy.

Deployment models: fully SaaS (Exabeam-hosted), self-hosted/on-premises for regulated data residency, and hybrid where ingestion or collection stays on-premises while analytics run in the cloud.

LogRhythm SIEM (now part of the Exabeam portfolio) is the self-hosted SIEM path: Data Processors, Data Indexers, and the Platform Manager form the classic three-tier topology.

In LogRhythm, the Data Indexer stores indexed log metadata for search; the Data Processor parses, normalizes, and enriches; the Platform Manager hosts the AI Engine, admin console, and API services.

Scale rule: add Data Processors for parsing throughput and Data Indexers for search/storage capacity; a single component type does not scale the other dimension.

Cloud-native means elastic compute and object storage for raw logs; self-hosted means fixed appliance or VM capacity that must be sized against daily ingestion volume (GB/day) plus peak multipliers.

High availability requires redundant Data Indexers/Processors and a load-balanced entry point; the Platform Manager is a critical singleton and must be protected by backup or clustering.

Network flows to confirm during deployment: syslog (514/601 UDP/TCP), TLS syslog (6514), HTTPS (443) for API/UI, and agent-to-manager channels for endpoint collection.

Ingestion paths: syslog push, log forwarders/agents, API pull (cloud audit and SaaS sources), file collection, and Exabeam/LogRhythm native integrations.

Normalization maps vendor fields to a common schema (user, host, source IP, destination IP, outcome, event time); unparsed or unnormalized events weaken correlation and UEBA baselines.

Pipeline stages: collect, parse/normalize, enrich (asset, identity, threat intel), index/store, then feed correlation and analytics; each stage can drop or delay events.

Time synchronization matters: event time versus ingest time skew breaks session assembly; NTP alignment across sources and collectors is a prerequisite for accurate timelines.

Retention is tiered: hot/searchable storage for recent data, warm/cold object storage for long-term compliance retention; retention periods are set per data type and per policy.

Parsing failures are diagnosed by inspecting raw versus parsed events, checking custom parser mappings, and validating message format changes after vendor upgrades.

Volume control levers: filter noisy low-value events at the collector, tune parser drop rules, and monitor license/ingest quota against GB/day or events-per-second budgets.

Log source health is measured by last-event-time monitoring and silence alerts; a source with no events for its expected interval is treated as a collection failure, not quiet.

UEBA baselines per-entity behavior (user, host, IP, service account) over a learning window and scores deviations; ABA applies the same behavioral modeling to machine/agent activity such as service accounts and automation.

Session assembly groups related events into a user or entity session using correlation rules and time windows; anomalous sessions are the unit analysts investigate.

Risk scoring combines rule-based risk (deterministic detections) and behavioral/anomaly risk; scores aggregate per entity and decay or age over time.

Watchlists are curated entity groups (privileged users, executives, critical servers) used to raise or lower risk weighting and to scope detections.

Peer groups define the comparison population for anomaly detection; a misconfigured peer group produces false positives because the baseline is wrong.

Learning mode: new entities need a baseline period before anomaly scores are meaningful; expect elevated noise during initial learning and suppress or down-weight alerts then.

Tuning loop: review top risk contributors, adjust model thresholds, add exclusions for known-good automation, and re-validate with historical replay where available.

ABA-specific signals include unusual process execution, anomalous service-account logon times, and machine-to-machine traffic patterns that human-focused models would miss.

TDIR lifecycle: detect (rules, correlation, analytics), triage (prioritize by risk and asset criticality), investigate (timeline and evidence), respond (contain, remediate), and close with documented outcome.

The Timeline is the investigation surface: it renders all events for an entity in chronological order, annotated with risk reasons and linked to related entities.

Pivoting rule: from a suspicious user, pivot to hosts, IPs, and processes; from a suspicious host, pivot to users and network peers; each pivot expands the session graph.

AI agent workflows automate repetitive investigation steps such as evidence gathering, enrichment lookups, and summarization, while keeping analyst approval on destructive actions.

Detection content includes correlation rules, anomaly models, and threat-intel matches; each detection should carry a risk reason that explains why it fired.

False-positive handling: suppress with narrow, documented exclusions tied to a specific entity or pattern, never broad source-wide mutes that hide real activity.

Case management links alerts into an incident, tracks status and ownership, and preserves the evidence trail required for audit and post-incident review.

Mean time to detect and mean time to respond are the primary TDIR metrics; measure them from first event time, not from alert creation time.

A playbook is a triggered workflow of actions: trigger (alert, case, manual, schedule), enrichment steps, decision branches, and response actions with outputs.

Common enrichment actions: WHOIS/IP reputation, hash lookup, identity context from directory, asset criticality lookup, and prior-alert history for the entity.

Response actions include disabling an account, isolating a host, blocking an IP/domain, and creating or updating a case; destructive actions should require human approval gates.

Idempotency and error handling: playbooks must tolerate repeated triggers and API failures, with retries and fallback branches rather than silent failure.

Integration surface is the REST API and prebuilt connectors; credentials for connectors should use scoped service accounts, not personal admin accounts.

Testing methodology: run playbooks against sample alerts in a staging or sandbox context, verify each branch, then promote; log every action for audit.

Automation scope decision rule: automate high-volume, low-ambiguity, reversible steps; keep ambiguous or irreversible steps analyst-driven with automated evidence attached.

Playbook performance is measured by execution success rate, time saved per alert, and percentage of alerts auto-closed with defensible disposition.

Outcomes Navigator maps deployed detection content and data sources to security outcomes and control frameworks, showing coverage gaps rather than raw rule counts.

Compliance mapping links controls (for example access control, monitoring, audit logging) to the evidence the platform produces: logs retained, alerts generated, cases closed.

Coverage assessment: for each framework control, confirm the required log sources are ingested, the detection exists, and the response process is documented.

Measurement metrics: log source coverage percentage, detection coverage per MITRE ATT&CK technique, alert-to-case conversion, and closed-case disposition rates.

Audit evidence must be reproducible: retention settings, access logs, and change history for rules and playbooks support examiner questions.

Gap remediation prioritization: missing critical log sources first, then missing high-severity detections, then process documentation gaps.

Dashboards should report trend over time (detections, cases, MTTD/MTTR) so program improvement is demonstrable, not a one-time snapshot.

Role-based access control: assign the least-privilege role needed (analyst, responder, administrator, read-only auditor); permissions govern data visibility and action rights.

Authentication options include local accounts, SSO/SAML federation, and MFA; federated identity centralizes deprovisioning and reduces orphaned accounts.

Service accounts for API integrations should be scoped, documented, rotated on schedule, and excluded from interactive login where possible.

Administrative hygiene: named accounts for humans, no shared admin credentials, periodic access reviews, and audit of privilege changes.

Health monitoring covers ingestion volume, component status, parser failure rates, and license/quota consumption; alert on threshold breaches before they impact detection.

Backup and change control: export configurations (rules, watchlists, playbooks) and version them; record changes with owner, date, and reason.

Support engagement: gather diagnostics (component logs, timestamps, affected entities, reproduction steps) before opening a case to shorten resolution.

Upgrade planning: review release notes for parser and API changes, validate in non-production, and confirm integration compatibility before production rollout.