Architecture

High-Level Overview

RhythmX extends the LogRhythm platform with a complementary detection and analytics layer. It receives logs from LogRhythm's Log Distribution Services, processes them through dedicated ingestion pipelines, applies Sigma-based behavioral detections, runs machine learning anomaly detection, and correlates alerts across 21 threat use cases — all feeding back into LogRhythm for unified alerting and case management.

flowchart TD
    subgraph sources [" "]
        direction LR
        W["Windows Endpoints<br><i>Event Logs</i>"]
        LS["Linux Endpoints<br><i>Sysmon</i>"]
        LA["Linux Endpoints<br><i>Auditd</i>"]
    end

    SMA["System Monitor Agents"]
    MED["Mediator"]
    LDS["Log Distribution Services"]

    WP["Windows Pipeline<br><b>Port 5514</b> · TCP/UDP"]
    LSP["Linux Sysmon Pipeline<br><b>Port 5515</b> · TCP"]
    LAP["Linux Auditd Pipeline<br><b>Port 5516</b> · TCP"]

    EN["Log Enrichment &<br>Normalization"]
    ROT["Log Rotation &<br>Batching"]
    DET["Sigma Detection Engine"]

    subgraph analytics [" "]
        direction LR
        ML["ML Anomaly Detection"]
        CORR["Correlation Engine<br><i>21 Threat Use Cases</i>"]
    end

    OUT["Structured Detection Output<br><i>LogRhythm-compatible</i>"]

    W --> SMA
    LS --> SMA
    LA --> SMA
    SMA --> MED
    MED --> LDS

    LDS -->|"Port 5514"| WP
    LDS -->|"Port 5515"| LSP
    LDS -->|"Port 5516"| LAP

    WP --> EN
    LSP --> EN
    LAP --> EN
    EN --> ROT
    ROT --> DET
    DET --> ML
    DET --> CORR
    ML --> OUT
    CORR --> OUT

    style sources fill:#4a148c,stroke:#7c43bd,color:#fff
    style analytics fill:#1a237e,stroke:#534bae,color:#fff
    style SMA fill:#1a237e,stroke:#534bae,color:#fff
    style MED fill:#1a237e,stroke:#534bae,color:#fff
    style LDS fill:#1a237e,stroke:#534bae,color:#fff
    style W fill:#6a1b9a,stroke:#ab47bc,color:#fff
    style LS fill:#6a1b9a,stroke:#ab47bc,color:#fff
    style LA fill:#6a1b9a,stroke:#ab47bc,color:#fff
    style WP fill:#4a148c,stroke:#9c27b0,color:#fff
    style LSP fill:#4a148c,stroke:#9c27b0,color:#fff
    style LAP fill:#4a148c,stroke:#9c27b0,color:#fff
    style EN fill:#0d47a1,stroke:#42a5f5,color:#fff
    style ROT fill:#e65100,stroke:#ff9d3f,color:#fff
    style DET fill:#b71c1c,stroke:#f05545,color:#fff
    style ML fill:#00695c,stroke:#4db6ac,color:#fff
    style CORR fill:#00695c,stroke:#4db6ac,color:#fff
    style OUT fill:#1b5e20,stroke:#4c8c4a,color:#fff

---

Log Ingestion

RhythmX receives logs from LogRhythm's Log Distribution Services (LDS). LDS is configured within the LogRhythm platform to forward copies of collected logs to the RhythmX server over the network.

Supported Log Sources & Ports

Log Source	Port	Protocol	Description
Windows Event Logs	5514	TCP / UDP	Windows Security, System, Sysmon, and Application event logs
Linux Sysmon	5515	TCP	Sysmon for Linux telemetry (process, network, file events)
Linux Auditd	5516	TCP	Linux Audit daemon logs (syscall, file access, auth events)

Each log source has its own dedicated ingestion pipeline, ensuring that parsing logic, enrichment, and detection rules are tailored to the specific log format.

How Logs Get to RhythmX

1. LogRhythm System Monitor Agents collect logs from Windows and Linux endpoints
2. Logs are sent to the LogRhythm Mediator for initial processing
3. The Mediator forwards logs to Log Distribution Services
4. LDS is configured with a distribution policy that sends a copy of the logs to the RhythmX server's IP and designated port
5. RhythmX's ingestion layer receives and begins processing

No additional agents are installed on endpoints — RhythmX leverages LogRhythm's existing collection infrastructure seamlessly.

---

Log Processing Pipeline

Once logs arrive, each pipeline performs the following steps:

1. Enrichment & Normalization

Incoming logs from LogRhythm carry metadata alongside the raw event data. RhythmX extracts the entity information and the original event payload, then enriches the raw log with source metadata to produce a normalized event ready for detection.

2. Malformed Event Handling

Events that cannot be parsed (missing fields, incomplete XML, encoding issues) are never dropped. They are routed to a separate malformed event stream with:

• A timestamp of when the parsing failure occurred
• The reason for the failure
• The full original event preserved for investigation

3. Log Rotation & Batching

Processed logs accumulate until they hit a configurable size threshold. At that point, the current log file is rotated and processed through the detection engine. This batching strategy balances near real-time detection with high throughput.

---

Sigma Detection Engine

RhythmX evaluates every log batch against a library of Sigma rules and produces structured alerts for any matches.

Built-in Rule Sets

RhythmX ships with curated Sigma rule sets covering common threat behaviors:

Rule Set	Coverage
Windows Generic	Broad Windows event log detections
Windows Generic (High/Medium)	Severity-filtered subsets
Windows Sysmon	Process creation, network, file, registry events
Windows Sysmon (High/Medium)	Severity-filtered subsets
Linux Sysmon	Linux process, network, and file monitoring
Linux Auditd	Syscall-level detections, privilege escalation, file access

Custom Sigma Rules

Teams can upload their own Sigma rules as .yml files to extend detection coverage. RhythmX supports separate custom rule directories for each log type:

• Custom Windows rules — applied to the Windows pipeline
• Custom Linux Sysmon rules — applied to the Linux Sysmon pipeline
• Custom Linux Auditd rules — applied to the Auditd pipeline

Custom rules follow the standard Sigma rule specification and are automatically picked up on the next detection cycle.

Rule Selection & Exclusion

During installation, operators choose which built-in rule sets to activate per pipeline. Additionally:

• Selection configs control which rules are active
• Exclusion configs allow suppressing specific rules (e.g., noisy or irrelevant rules for your environment)

This gives operators fine-grained control over detection coverage without modifying rule files.

---

Machine Learning — Anomaly Detection

After Sigma-based detections are generated, RhythmX applies a machine learning model to identify anomalous behaviors that may not match any existing rule.

flowchart LR
    A["Sigma Alerts"] --> B["Feature Engineering"]
    B --> C["ML Anomaly Detection"]
    C --> D["Normal"]
    C --> E["Anomalous"]

    style A fill:#4a148c,stroke:#9c27b0,color:#fff
    style B fill:#0d47a1,stroke:#42a5f5,color:#fff
    style C fill:#00695c,stroke:#4db6ac,color:#fff
    style D fill:#1b5e20,stroke:#4c8c4a,color:#fff
    style E fill:#b71c1c,stroke:#f05545,color:#fff

How It Works

The ML engine runs on a continuous cycle, analyzing alerts over a rolling time window. For each entity (user or computer), it builds a behavioral profile and flags deviations from that profile as anomalous.

What the ML Engine Analyzes

The model evaluates multiple dimensions of each alert to determine whether the behavior is normal or anomalous:

Signal Category	Examples
Alert context	Rule names, tactics, techniques, and severity
Command line behavior	Suspicious patterns, encoded commands, unusual tokens
Identity & system context	User, computer, event type, and provider
Behavioral patterns	Alert velocity, timing patterns, and network indicators

Per-Entity Profiling

The model builds independent behavioral profiles for each entity, ensuring that what is normal for a database server is not applied as the baseline for a developer workstation. This eliminates cross-entity noise and produces highly targeted anomaly scores.

Output

Alerts are annotated with an ML classification — normal or anomalous — allowing analysts to prioritize investigation on behaviors that deviate from established patterns, even when no Sigma rule explicitly covers the activity.

---

Correlation Engine — Threat Use Cases

Beyond individual alert detection, RhythmX runs a correlation engine that identifies complex, multi-stage attack patterns by analyzing relationships across multiple alerts.

flowchart TD
    A["Sigma Alerts +<br>ML Annotations"] --> B["Correlation Engine"]

    B --> C["Lateral Movement"]
    B --> D["Password Spraying"]
    B --> E["APT Chains"]
    B --> F["Ransomware Indicators"]
    B --> G["18 more use cases..."]

    C --> H["Cases"]
    D --> H
    E --> H
    F --> H
    G --> H

    style A fill:#4a148c,stroke:#9c27b0,color:#fff
    style B fill:#00695c,stroke:#4db6ac,color:#fff
    style C fill:#0d47a1,stroke:#42a5f5,color:#fff
    style D fill:#0d47a1,stroke:#42a5f5,color:#fff
    style E fill:#0d47a1,stroke:#42a5f5,color:#fff
    style F fill:#0d47a1,stroke:#42a5f5,color:#fff
    style G fill:#0d47a1,stroke:#42a5f5,color:#fff
    style H fill:#b71c1c,stroke:#f05545,color:#fff

21 Threat Detection Use Cases

The correlation engine evaluates alerts against 21 predefined attack patterns:

Use Case	What It Detects
Lateral Movement	A user appearing across multiple machines with diverse attack tactics
Password Spraying	Same source targeting multiple user accounts in a short time window
Brute Force	Repeated authentication failures against a single account
APT Chain	Multi-stage persistent attack progressing through kill chain phases
Reconnaissance	Discovery and enumeration commands indicating pre-attack activity
Credential Theft	Credential dumping tools and techniques (Mimikatz, LSASS access)
Defense Evasion	Attempts to disable or tamper with security tools
PowerShell Abuse	Malicious PowerShell execution patterns (encoded commands, downloads)
Privilege Escalation	Techniques to elevate privileges beyond authorized levels
Persistence	Autorun entries, scheduled tasks, and other persistence mechanisms
LOLBins Campaign	Living-off-the-land binary abuse across multiple endpoints
DLL Sideloading	DLL hijacking and sideloading techniques
System Binary Anomaly	Unusual execution of legitimate system binaries
Remote Access Abuse	Unauthorized use of remote management tools
Installer Abuse	MSI and setup file exploitation
Parent-Child Anomaly	Unusual process parent-child relationships
Initial Access to Lateral	Progression from initial compromise to lateral movement
Credential Campaign	Coordinated credential attacks across the environment
Ransomware Indicators	Behavioral precursors to ransomware deployment
Rapid Fire Alerts	High-velocity alert patterns indicating active attack
APT36 Transparent Tribe	TTPs specific to the APT36 threat group

How Correlation Works

1. The engine runs on a continuous schedule, querying recent alerts
2. Each use case defines thresholds and conditions (e.g., same user on 4+ machines with 5+ distinct tactics)
3. When conditions are met, a case is created linking all related alerts
4. Cases are assigned a severity based on the matched use case
5. Cases sync back to LogRhythm for unified case management

Use cases are fully configurable — teams can adjust thresholds, add new patterns, or disable use cases to match their environment.

---

Detection Output

When the detection engine, ML model, or correlation engine produces a finding, it generates a structured alert containing:

Field	Description
Title	Detection rule name
Description	What the rule detects
Severity	Informational, low, medium, high, or critical
MITRE ATT&CK	Mapped tactics and techniques
ML Classification	Normal or anomalous
Matched fields	The specific event fields that triggered the detection

These detections are written in a LogRhythm-compatible format, enabling:

• Re-ingestion into LogRhythm for correlation and case management
• Direct alerting and dashboard integration within the LogRhythm platform

---

Performance & Scalability

RhythmX is engineered for high-throughput environments:

Metric	Value
Sustained throughput	20,000–25,000 EPS
Burst capacity (5–10 min)	30,000–35,000 EPS
Detection latency	60–120 seconds
Recommended hardware	64GB RAM / 16 CPU cores

Dedicated pipelines per log source, built-in queue management, and optimized processing ensure consistent performance even during traffic spikes.