Sicherheit ist nicht separat. Es ist ein Signal.

Security-Events und Anomalien werden wie andere Observability-Signale behandelt: Log-Einträge, Metriken und Traces. Anomalien automatisch erkannt – in deiner Infrastruktur, betrieben von Skalenta.

Das SecOps-Problem: Silos zwischen Ops und Security

Typische Setups haben:

  • Ops Team: Prometheus, Grafana, Loki (Logs, Metriken, kein Security-Fokus)
  • Security Team: Falco, AppArmor, SELinux, Vault (separate Tools, separate Alerts)
  • Resultat: Zwei Teams, zwei Toolchains, zwei UIs, keine Cross-Visibility

Ein Security-Event passiert: Falco wirft Alert, das Ops-Team sieht es nicht (liegt in einem anderen Tool). Trotzdem: API-Latency steigt, Ops debuggt das Netzwerk statt der Intrusion.

KI-Ops integriert Security als erstklassiges Observability-Signal – als SaaS-Tool, der in deiner Cloud oder On-Prem läuft. Deine Logs, Metriken und Audit-Daten bleiben in deiner Umgebung.

Security-Signale in deinem Ops-Stack

1. RBAC & Access Auditing mit Anomalie-Erkennung

$ ki-ops audit-rbac --namespace production
Auditing Role-Based Access Control...

🔴 ANOMALIEN ERKANNT:

1. ServiceAccount: deployment-automation (ns: ci-cd)
   Trend Analysis:
   ├─ Today: 45 API calls
   ├─ Last 7 Days: avg 8 calls
   ├─ Spike Factor: 5.6x higher than normal
   └─ NEW PERMISSION GRANT: cluster-admin (granted 3 minutes ago)

   ⚠️ ANOMALIE-ANALYSE:
     Verdächtig: ServiceAccount escalated zu cluster-admin
     Timing: Right before unusual activity surge
     Confidence: 94%

   Empfehlung:
   a) Review: War das authorisiert?
   b) Check ob legitim oder kompromittiert
   c) $ kubectl logs -n ci-cd deploy/deployment-automation --tail=100

2. User: [email protected]
   Aktion: 23 Secret reads in last 30 minutes
   Trend:
   ├─ Historisch: Never accessed Secrets
   ├─ Zeitstempel: 02:47 UTC (unusual hour)
   └─ Source IP: 203.0.113.45 (new IP, untypisch)

   ⚠️ ANOMALIE-ANALYSE:
     High Confidence: Potential Credential Theft
     Gründe:
     ├─ Unerwartete Zeit (2:47 UTC)
     ├─ Neues Netzwerk (neue IP)
     ├─ Anomale Behavior (secrets lesen)

   Empfehlungen:
   ├─ Check ob alice on-call ist
   ├─ Verify Laptop VPN aktiv
   ├─ Review welche Secrets gelesen wurden
   └─ Ggf.: Rotate affected Secrets

2. Runtime Behavior Anomalies (Machine Learning)

$ ki-ops detect-anomalies --security --lookback 7d
Detecting behavioral anomalies...

BEHAVIORAL ANOMALIES (Machine Learning-basiert):

1. Pod: api-service-xy81f (ns: production)
   Anomaly: Outbound Connection Pattern verändert
   ├─ Normal Behavior (Baseline):
   │  ├─ Connect to: postgres (10.0.1.5:5432) - täglich
   │  ├─ Connect to: redis (10.0.2.10:6379) - täglich
   │  └─ Connect to: dns (10.96.0.10:53) - kontinuierlich
   │
   ├─ ANOMALIE ERKANNT (seit 45 min):
   │  ├─ Connect to: 185.220.100.45:443 (Tor Exit Node!)
   │  ├─ Frequency: 234 connections/min
   │  └─ Data Transfer: 450MB in 45 min
   │
   └─ Risk Level: CRITICAL
      ├─ Dieser Pod sollte nicht nach außen connecten
      ├─ TOR-Nutzung ist stark verdächtig (94% confidence)
      └─ Mögliche Ursachen: Malware, Kompromittierung, Crypto-Miner

   Sofort-Maßnahmen:
   a) Analyse: Welcher Prozess macht das?
      $ eBPF zeigt: Container läuft suspicious binary
   b) Review: Image-Provenance, Recent Deployments
   c) Incident: AlertDesk notified, Quarantine pod

2. Process Behavior Anomaly
   Container: postgres-backup (ns: databases)
   ├─ Normal: Läuft täglich 01:00-02:30 UTC, CPU 15%, Memory 800MB
   ├─ ANOMALIE: Läuft jetzt 13:47 UTC (!), CPU 95%, Memory 4.5GB
   │  ├─ Process Tree: bash → dd → /dev/zero (?)
   │  ├─ File Access: /var/lib/postgresql (unusual read pattern)
   │  └─ System Calls: 2345 getuid() calls (why so many privilege checks?)
   │
   └─ Analyse:
      ├─ Scheduled Job läuft zur unerwarteten Zeit (anomal)
      ├─ Resource-Verbrauch 30x höher als normal (anomal)
      ├─ Verdacht: Job-Controller Bug, Malicious Cron (80% confidence)
      
   Debug-Schritte:
   $ kubectl logs postgres-backup -n databases --timestamps
   $ kubectl describe pod postgres-backup -n databases

3. Vulnerability Scanning Integration

$ ki-ops scan-vulnerabilities --cluster
Scanning images and dependencies...

🔴 VULNERABILITIES FOUND:

1. Image: api-service:v2.3.1
   Base OS: ubuntu:20.04
   Kritische Vulnerabilities:
   ├─ CVE-2024-1234: OpenSSL Integer Overflow (CRITICAL)
   │  ├─ CVSS Score: 9.8 (Very High)
   │  ├─ Affected: libssl1.1 (2.3.0)
   │  ├─ Fixed In: libssl1.1 (2.3.2)
   │  └─ Pods Using: 47 pods (api-service-1, ..., api-service-47)
   │
   ├─ CVE-2024-5678: XSS in express.js (HIGH)
   │  ├─ CVSS Score: 7.2
   │  ├─ Affected: express (4.18.1)
   │  ├─ Fixed In: express (4.19.0)
   │  └─ Aktion: Update package.json, rebuild image
   │
   └─ CVE-2023-9999: Path Traversal in fs library (MEDIUM)

2. Deployed Image: worker-job:v1.2.0
   Status: 12 known CVEs, 3 CRITICAL
   Last Updated: 2021-03-15 (!!!)
   ├─ Image ist 3 Jahre alt
   ├─ Wahrscheinlich 100+ neue Vulns bekannt
   └─ EMPFEHLUNG: Retire image immediately or rebuild

3. Kubernetes RBAC Risk Assessment
   ClusterRole: "edit"
   ├─ Users: [email protected], automation-bot
   ├─ Permissions: Zu viele (create pods, delete services, etc.)
   └─ EMPFEHLUNG: Least privilege RBAC policy
      → Create role "deployment-editor" mit nur deploy/service Rechten

4. Network Policy Gap Analyse
   Namespace: production
   ├─ Status: No NetworkPolicies defined (!!)
   ├─ Risk: All pods can communicate with all pods
   ├─ Risk: All pods can communicate with external internet
   └─ EMPFEHLUNG: Implement default-deny-all NetworkPolicy

Anomalie-Erkennung: Machine Learning-Ansatz

KI-Ops verwendet Machine Learning (nicht nur Rules):

Phase 1: LEARNING (erste 7 Tage)
├─ Sammelt Baseline-Behavior für alle Pods
├─ Metriken: CPU, Memory, Network I/O, Prozesse, Connections
├─ Baseline: P50, P95, P99 Latenz, Throughput, Error Rates
└─ Builds Statistical Model pro Workload

Phase 2: DETECTION (kontinuierlich)
├─ Vergleicht aktuelle Signale gegen Baseline
├─ Erkennt Anomalien wenn Abweichung > 3 Standardabweichungen
├─ Filterung: False Positives durch Seasonality-Model
│  (z.B.: Jeden Montag höherer Traffic ist NORMAL, kein Alert)
└─ Transparency: Skalenta-Team kann Models gemeinsam mit dir tunen

Phase 3: CORRELATION
├─ Mehrere Anomalien gleichzeitig?
  → Wahrscheinlich ein Root Cause
  → Cluster zusammenhängende Events
└─ Single anomaly → Low severity
   Multiple correlated → High severity + Immediate Alert

Use Cases in der Praxis

Szenario 1: Crypto-Mining Malware Erkennung

1. Pod startet unerwartete Prozesse
   → eBPF erkennt: bash → gcc → make (???)
   → Anomaly: Dieser Pod sollte nicht compilieren

2. CPU-Auslastung steigt von 10% auf 98%
   → Metric Anomaly erkannt (P99 baseline: 25%)

3. Network Connection zu Mining Pool
   → eBPF zeigt: tcp:185.220.100.45:443
   → Behavior Anomaly: untypisches Netzwerk-Pattern

4. KI-Ops ALERT (Confidence: 98%):
   "Possible Crypto-Mining in api-service-xy81f"
   ├─ Correlation Score: 98% (sehr sicher)
   ├─ Sofort-Maßnahmen: Kill pod, rebuild image, audit code
   └─ Audit: Vollständiger Trail aller erkannten Signale

Szenario 2: Credentials Leak Erkennung

1. New Secret created by "alice"
   → Access audit zeigt: alice created "aws-secret"
   → Anomaly: alice ist Application Developer, nicht DevOps

2. Secret exfiltrated zu external service
   → eBPF zeigt: pod sendet SECRET_VALUE zu external IP
   → Behavior Anomaly: nie vorher gesehen

3. KI-Ops ALERT (Confidence: 96%):
   "Possible Credential Leak Detected"
   ├─ Secret 'aws-secret' accessed 45 times in 10 min
   ├─ Exfiltrated to: 203.0.113.99:443
   ├─ Severity: CRITICAL
   └─ Aktionen:
       a) Rotate AWS Credentials (jetzt!)
       b) Kill affected pods
       c) Review CloudTrail for unauthorized API calls

Security + Ops Integration

# KI-Ops Config: Security Events in Alerting
observability:
  security:
    enabled: true
    sources:
      - falco          # Runtime Security
      - rbac-audit     # Kubernetes Audit Logs
      - vulnerability  # Image Scanning
      - network        # eBPF Network Flows

  alerting:
    rules:
      - name: "Critical Security Anomaly"
        condition: "security_risk_score > 8"
        notify: ["#security-oncall", "[email protected]"]

      - name: "Image Vulnerability"
        condition: "vulnerability.cvss_score > 7.0 AND deployed_pod_count > 0"
        notify: ["#platform-eng"]

Was du mit Security Observability gewinnst

  • Holistic View: Security + Performance + Reliability in einer Plattform
  • Faster Detection: Anomalien werden erkannt, bevor Schaden entsteht
  • Context: Warum ist ein Pod verdächtig? Weil: neues Behavior + falsche RBAC + altes Image
  • Team Alignment: Ops und Security sprechen die gleiche Sprache (Signals, not silos)
  • Compliance by Design: Vollständiger Audit-Trail für alle Security-relevanten Events – ausgelegt auf DORA, NIS-2 und EU AI Act
  • Managed: Betrieb, Updates und das Tuning der Detection-Models übernimmt Skalenta – die Daten bleiben in deiner Umgebung
  • Read-only & Non-Invasive: KI-Ops erkennt und analysiert Sicherheitsprobleme, aber greift nicht ein – du entscheidest über Response

Im Service enthalten

  • Runtime-Security-Signale (Falco, eBPF) als erstklassige Observability-Quelle
  • RBAC- & Access-Auditing mit Trend- und Anomalie-Erkennung
  • Vulnerability-Scanning für Images und Dependencies
  • ML-basierte Behavioral Anomaly Detection inkl. Seasonality-Filter
  • Intelligente Korrelation: Mehrere anomale Signale → ein Alert (statt Alarm-Überflutung)
  • Betrieb, Updates und Model-Tuning durch Skalenta – in deiner Cloud oder On-Prem
  • Audit-Trail für alle erkannten Anomalien und Handlungsempfehlungen

Nächster Schritt: Demo buchen – wir zeigen dir Behavioral-Anomalien live in deiner Umgebung.

In deiner Umgebung sehen

Wir zeigen dir diese Funktion live an einem Setup wie deinem – managed, in deiner Cloud oder On-Prem.

Demo buchen