Skip to content

Dashboard User Guide: Overview

The Logster dashboard is the primary interface for SOC analysts. It reads directly from Elasticsearch and surfaces aggregate views, per-endpoint drill-downs, inference detail, process trees, and MITRE ATT&CK TTP distributions — all scoped by a time range and optional hostname filter.

This guide teaches you how to use it effectively, from first login to recording analyst verdicts on real detections.

What this guide covers

Page You'll learn how to...
Getting Started (this page) Understand what the dashboard is, how to log in, and how to orient yourself.
Dashboard GUI Navigate every view — Summary, Hosts, Timeline, Recent Attacks, Inference Detail, Process Tree, Endpoint Insights, Distribution, Analytics.
Investigation Examples Follow the end-to-end triage workflow — from "something lit up" to "verdict recorded" — with worked examples.

What the dashboard is (and isn't)

The dashboard is a read-only analytics view over two Elasticsearch indices populated by the Logster pipeline:

  • logster-events — normalized endpoint events (every Sysmon, auditd, or eBPF record the pipeline has seen).
  • logster-inferences — one row per GNN run, with attack_prob, prediction, and the list of events that contributed to the prediction.

The analyst views are all aggregations over those two indices. When you change the time range or filter by hostname, every tile re-queries Elasticsearch and redraws.

[!NOTE] The dashboard is not where alert state transitions happen. Moving an alert from open to resolved, adding analyst notes, and submitting true/false-positive feedback all go through the Logster REST API. See API User Guide. A production deployment typically wires the dashboard's "mark as reviewed" buttons to those endpoints.

First login

  1. Make sure the Logster stack is running. See Admin Guide: Installation.
  2. Open http://localhost:5001 in a browser.
  3. The default development stack has authentication disabled (DISABLE_AUTH=true), so you land directly on the main view with no login step. In a production deployment, your reverse proxy will challenge you for credentials first — see Admin Guide: Authentication.

Orienting yourself

The top bar of the dashboard has two controls you will use on every session:

  • Time range picker. Every query the dashboard issues is scoped to this range. Defaults to now-30m → now. Widen it if you are investigating a historical event, narrow it if you are watching a live incident.
  • Hostname filter. Scopes every tile to a single endpoint. Useful when you have already decided which host to drill into and want every panel to reflect that one host.

Dashboard top bar — time range picker, endpoint filter, refresh cadence, and live-update indicator

Top bar: the Time Range picker and Endpoint filter scope every tile on the page. Refresh controls auto-reload results at the selected cadence; LIVE / Updated timestamp confirms the data is current.

Below the top bar, the dashboard is organized into progressively more specific views:

  1. Summary — fleet-wide KPIs at a glance.
  2. Hosts — per-endpoint cards sorted by threat level.
  3. Attack Timeline — when attacks happened, bucketed over time.
  4. Recent Attacks — the raw list of attack-predicted inferences.
  5. Inference Detail — what a single GNN run actually classified.
  6. Process Tree — how the processes in a detection relate.
  7. Endpoint Insights — behavioral baseline for one host.
  8. Distribution and Analytics — noise / trend / heatmap / TTP distribution.

See Dashboard GUI for the view-by-view walkthrough.

The triage workflow in one paragraph

A typical SOC analyst session goes like this: glance at Summary to see if anything is lit up in the last 30 minutes; if it is, jump to Hosts and pick the worst card by max_attack_probability; open Recent Attacks filtered to that host and click into the most recent attack inference; read the Inference Detail view to see which events the GNN flagged; open the Process Tree for the same inference to walk parent/child relationships; cross-check Endpoint Insights to see whether the user, binary, and network destination are normal for that host; confirm the MITRE TTPs on the Analytics page; record your verdict via POST /feedback. For the detailed worked version of this loop, see Investigation Examples.

MITRE ATT&CK TTPs in the UI

Alerts and inference documents carry a ttp_techniques field populated by the optional TTP analyzer service. Values are MITRE ATT&CK identifiers in the form Tnnnn or Tnnnn.nnn (for sub-techniques).

[!TIP] The canonical MITRE ATT&CK reference is https://attack.mitre.org. Look up each technique ID there for the full description, suggested detections, and known mitigations. When an alert shows multiple TTPs, treat them as simultaneous observations — the graph in that window matched all of them, which is usually stronger evidence than a single technique.

TBD — a short glossary of the MITRE technique IDs most commonly produced by your deployment should be populated here from actual ttp_techniques history, not guessed in advance.

See Reading MITRE ATT&CK TTPs for how this surfaces in each view.

Where to go next