Skip to content

Key Features

Logster is an AI-driven threat detection platform. This page summarizes the features that matter most to security architects, SOC leaders, and platform operators evaluating Logster for a deployment.

For the full pipeline walkthrough, see Enterprise Architecture. For installation and configuration, start with the Admin Guide.

AI-driven detection

  • Pre-trained Graph Neural Network models (one for Windows, one for Linux) classify 3-minute sliding windows of endpoint activity as benign or attack.
  • Heterogeneous temporal graphs — Logster builds graphs with typed nodes (process, file, script, network, syscall) and typed edges (spawned, wrote, executed, connected-to, performed), timestamped at every edge. The model reasons over the shape of activity, not individual events.
  • 3-layer Graph Attention Network (GAT) with 128 hidden dimensions, 4 attention heads, and a 2-class output. Platform-specific models are shipped as PyTorch .pt files under models/models/.
  • Zero-day detection — because Logster reasons over behavioral graphs rather than indicators of compromise, it can flag novel attack patterns that share the structure of known attacks without requiring a signature update.
  • No manual threat hunting required — detections are automatic and continuous; analysts work from the alert queue rather than chasing hypotheses.

MITRE ATT&CK coverage

Logster is designed to detect activity across the full attack lifecycle. From Logster Support's product materials, the covered tactics are:

  • Reconnaissance
  • Resource Development
  • Initial Access
  • Execution
  • Persistence
  • Privilege Escalation
  • Defense Evasion
  • Credential Access
  • Lateral Movement
  • Command & Control
  • Impact
  • Exfiltration

TBD — technique-level coverage. Specific MITRE technique IDs (e.g. T1059.001) supported by the shipped models should be populated from Logster Support's model release notes, not guessed.

Every alert carries zero or more MITRE technique IDs in its ttp_techniques field, populated by the optional TTP analyzer service. Analysts use these for triage and pivoting — see the Dashboard User Guide.

Real-time alert pipeline

  • Deduplication — Same-endpoint alerts within a configurable window (default 5 minutes) are merged into a single alert, so noisy hosts do not spam the analyst queue.
  • Lateral-movement correlation — When multiple endpoints in the same tenant alert within a configurable window (default 60 seconds), they are cross-linked via the related_endpoints field on the alert.
  • Severity derivation — Every alert gets a severity based on attack_prob: CRITICAL >= 0.95, HIGH >= 0.85, MEDIUM >= 0.7.
  • MITRE ATT&CK enrichment — An optional TTP analyzer service enriches alerts with technique IDs and human-readable explanations.
  • Alert lifecycle — open → acknowledged → investigating → resolved / false_positive, driven by analyst transitions through the REST API. Enum definition in libs/logster-common/logster_common/schemas/alerts.py.
  • Notification sinks — Alerts are published to the logster-alerts Kafka topic and can be consumed by downstream systems (Slack, webhook, SOAR, ticketing).

Analyst dashboard

The Logster dashboard is the primary SOC analyst interface. It reads directly from Elasticsearch and provides:

  • Host cards with per-endpoint threat gauges and alert counts.
  • Attack timeline showing benign vs attack counts and average / maximum attack probability per bucket over time.
  • Inference detail view — full GNN prediction with the list of events that contributed to the window.
  • Process tree visualization — walk parent/child process relationships inside a detection window.
  • Endpoint insights — user activity, privilege levels, file activity, network destinations, process relationships, command lines — for both Windows and Linux hosts from a single UI.
  • Distribution and analytics — prediction histograms, severity breakdowns, MITRE TTP distribution, attack heatmaps by hour and day, trend analysis versus the previous period.

See the Dashboard User Guide for the full walkthrough.

REST API for integration

Logster exposes a small, stable REST API on port 8080:

  • GET /alerts — list alerts with filtering and pagination.
  • GET /alerts/{id} — fetch a single alert.
  • PATCH /alerts/{id} — update status and notes.
  • POST /feedback — record analyst true/false-positive verdicts.
  • GET /endpoints — per-endpoint alert summary.
  • GET /health — service liveness.

The API is a FastAPI service, which means Swagger UI is available at /docs and OpenAPI JSON is available at /openapi.json for free. See the API User Guide.

Data ingestion

Logster natively supports the mainstream enterprise log shippers on both Windows and Linux.

Platform Supported ingestion agents
Windows Elastic Winlogbeat, Splunk Universal Forwarder, Windows Subscription Logging
Linux rsyslog (native), Splunk Universal Forwarder, syslog-ng

Logster's target ingestion scale is up to 10 Tbps/day in enterprise configurations.

Custom integrations outside this list can be built by the Logster Support engineering team on request. See the Splunk Integration Guide for the most common integration recipe.

Deployment flexibility

Logster is available in two deployment models:

  • On-Prem — installed inside your own data center or cloud. Better data privacy; logs never leave your environment. You own hardware, staffing, maintenance, and training.
  • SaaS — hosted by Logster Support. Real-time model updates, no maintenance hassle. You retain responsibility for endpoint collector deployment and data source configuration.

Both models deliver the same detection capability. See the Licensing Guide for pricing tiers and deployment trade-offs.

Observability and operations

  • Prometheus metrics exposed by every Python service — raw event counts, normalized event counts, inference runs, active endpoints, inference latency, alerts created, dedup hits, lateral-movement detections.
  • Grafana dashboards pre-provisioned against the Prometheus data source.
  • Distributed tracing via OpenTelemetry → Tempo, with spans across the normalizer → inference → alerts pipeline.
  • Structured stdout logging from every service, trivially shipped to any log aggregator.
  • Health endpoints on the API and dashboard, usable by orchestrators.

See Admin Guide: Daily Operations.

Where to go next