Can Graph-Based Microservice Performance Detection Be Used for Microservice Intrusion Detection?

Technical Summary: Can Graph-Based Microservice Performance Detection Be Used for Microservice Intrusion Detection?

Problem Statement
Microservice architectures generate rich telemetry streams (metrics, logs, and distributed traces) that are traditionally analyzed separately for performance anomaly detection and intrusion detection. Performance monitoring focuses on latency and resource consumption, while intrusion detection targets malicious behavior. However, in microservice systems, these domains overlap: attacks often manifest as performance symptoms (e.g., increased latency, unusual request rates, or altered service dependency paths). This paper investigates whether graph-based methods, originally designed for performance anomaly detection, can effectively serve as a foundation for microservice intrusion detection. The core question is whether modeling service dependencies as graphs allows for the classification of normal versus intrusive requests, and how different telemetry modalities contribute to this detection.

Methodology
The study employs a reproducible experimental design using a synthetic e-commerce microservice benchmark deployed via Docker Compose. The system consists of six services: frontend, auth, catalog, cart, order, and payment.

• Data Collection: The authors conducted 50 controlled trials across five attack types (HTTP flood, brute-force login, SQL injection probe, SSRF-like probe, and exfiltration simulation) under normal workloads. This generated 21,438 labeled request-level invocation graphs.
• Graph Representation: Each request trace is converted into a graph $G_i = (V_i, E_i, X_i, y_i)$.
  • Nodes ($V_i$): Represent the services involved in a request.
  • Edges ($E_i$): Represent the runtime call relations observed in the trace (symmetrized for message passing).
  • Features ($X_i$): A 25-dimensional vector per node, concatenating 16 TF-IDF dimensions from timestamped logs and 9 dimensions from per-service performance metrics.
  • Labels ($y_i$): Six classes (normal plus five attack types).
• Models:
  • Graph-Based: A supervised two-layer Graph Convolutional Network (GCN) using mean pooling for graph-level classification.
  • Non-Graph Baselines: Random Forest and Multi-Layer Perceptron (MLP) classifiers trained on flattened log and metric features.
• Evaluation Strategy: The study compares a "graph-level random split" (optimistic, within-distribution) against a "trial-level split" (stricter, ensuring no data leakage between training and testing trials). It also includes modality ablation (testing trace-only, logs-only, and metrics-only inputs) and runtime analysis.

Key Results

1. Baseline Performance (Random Split): Under a random split, the two-layer GCN achieved 96.2% test accuracy and a macro F1 of 0.955. This establishes an optimistic within-distribution reference point.
2. Generalization (Trial-Level Split): When evaluated under the stricter trial-level split (testing generalization across different experimental runs), the GCN's performance dropped significantly to a macro F1 of 0.777.
3. Non-Graph Superiority: Surprisingly, under the trial-level split, non-graph baselines (Random Forest and MLP) outperformed the GCN, achieving macro F1 scores of 0.980 and 0.974, respectively. This suggests that the engineered log and metric features are highly discriminative even without graph message passing.
4. Modality Ablation:
   • Trace Structure Alone: Insufficient for detection (Macro F1 0.405), indicating that call-path topology alone cannot identify all attack semantics.
   • Logs and Metrics: Both modalities significantly improved detection over trace-only features. Metrics were particularly effective for performance-visible attacks (e.g., HTTP flood), while logs helped detect semantic probes (e.g., SQL injection).
   • Combined: The combination of logs and metrics yielded the highest accuracy (0.879), though the short 5-epoch training limited the GCN's ability to balance class performance compared to metrics alone.
5. Error Analysis: The GCN struggled most with "brute-force login" attacks (recall dropped to 0.033 in the exploratory run), often misclassifying them as normal. These attacks preserved normal-looking request paths, requiring stronger temporal or security-event features than the shallow GCN utilized.

Significance and Claims
The paper concludes that graph-based microservice performance detection is a useful foundation but not a complete replacement for security-aware intrusion detection.

• Utility: Request-level graph representations successfully connect invocation paths with performance symptoms and security events, making them a promising substrate for intrusion detection, particularly for attacks that disturb service behavior or dependency structures.
• Limitations: The current shallow GCN does not yet outperform strong, non-graph baselines on the engineered feature set. The study emphasizes that graph methods must be evaluated against strong flattened baselines and require richer features (e.g., edge attributes, temporal aggregation) and class-aware training to claim superiority.
• Nuanced Answer: The approach is most effective when attacks create visible performance footprints or alter log patterns. Attacks that are semantically malicious but operationally quiet may not produce strong anomalies detectable by current graph methods without additional context.

The authors position this work as an exploratory step, providing a reproducible benchmark and demonstrating that while graph structures preserve valuable dependency information, the immediate value for intrusion detection in this specific setup currently lies in the quality of the engineered features (logs and metrics) rather than the graph architecture itself.