Bedrohungserkennung für Hybrid-Infrastrukturen: ein praktischer Bereitstellungsleitfaden

Jeder Vendor-Pitch beginnt gleich: Gehen Sie Cloud-nativ und alle Ihre Transparenzprobleme verschwinden. Schöne Geschichte. Nur hat Ihr Rechenzentrum von 2014 diese Nachricht nicht bekommen, Ihr Produktionsbereich läuft immer noch auf einem OT-Netzwerk, das niemand anfassen will, und die Hälfte Ihrer „Cloud-Migration“ ist eigentlich ein Kubernetes-Cluster mit einem VPN-Tunnel zurück zu einem Rack in einer Colocation-Einrichtung.

Hybrid ist keine Phase, die Sie auf dem Weg zu Cloud-nativ durchlaufen. Für die meisten Organisationen ist es der permanente Zustand. Und das bedeutet, dass die Bedrohungserkennung über Umgebungen hinweg funktionieren muss, die nie dafür ausgelegt waren, vom gleichen Tool überwacht zu werden.

Die Lücke in der Hybrid-Bedrohungserkennung liegt an den Grenzen zwischen Umgebungen

Sie können Erkennung für AWS kaufen. Sie können Erkennung für Azure kaufen. Sie können Erkennung für Ihre On-Prem-Firewalls kaufen. Was fast niemand kauft, ist Erkennung für die Grenze zwischen ihnen. Die Identitätsbrücke zwischen Ihrem AD und Ihrem Cloud-IdP, das Dienstkonto, das auf beiden Seiten Zugriff hat, das VPN-Gateway, das das Einzige ist, das zwischen einem kompromittierten Laptop und Ihren wertvollsten Vermögenswerten steht.

Angreifer respektieren Ihr Architekturdiagramm nicht. Sie gehen überall hin, wo der Weg am kürzesten ist, und der Weg führt fast immer durch eine Grenze, die niemand genau beobachtet, weil sie zwei Teams gehört und keines von ihnen besitzt sie.

Was Hybrid-Bedrohungserkennung tatsächlich erfordert

Die meisten Inhalte zur „Hybrid-Bedrohungserkennung“ gehen von einer grünen Wiese aus. Ihre ist es nicht. So kommen Sie tatsächlich von dort, wo Sie sind, dorthin.

1. Inventarisieren Sie Ihre Grenzen, bevor Sie etwas kaufen. Kartografieren Sie jeden Ort, an dem Identität, Netzwerk oder Daten eine Umgebungsgrenze überschreiten: AD-zu-Entra ID oder Okta-Synchronisierung, gemeinsame Dienstkonten, VPN-Gateways, S3-Buckets, die von On-Prem-NAS replizieren, Kubernetes-Cluster mit Hybrid-Node-Pools. Diese Liste ist normalerweise länger und hässlicher als erwartet.
2. Normalisieren Sie, bevor Sie korrelieren. AWS CloudTrail, Azure Activity Logs, GCP Audit Logs, On-Prem-Syslog von Firewalls und IDS sowie Kubernetes Audit Logs beschreiben alle die gleichen Arten von Ereignissen – Authentifizierung, Zugriff und Konfigurationsänderung – in völlig unterschiedlichen Formen. Wenn Ihre Plattform sie nicht auf ein konsistentes Schema abbilden kann, übersetzen Ihre Analysten während eines Vorfalls von Hand, was der schlechteste mögliche Zeitpunkt ist, um ein neues Protokollformat zu lernen.
3. Legen Sie Identitäts- und Netzwerk-Telemetrie auf die gleiche Zeitachse. Eine Cloud-IAM-Richtlinienänderung und eine On-Prem-VPN-Anmeldung drei Minuten später könnten unabhängig sein. Oder es könnte der ganze Vorfall sein. Sie können den Unterschied nicht erkennen, wenn sie in separaten Tools mit separaten Aufbewahrungsfenstern leben.
4. Ordnen Sie MITRE ATT&CK unabhängig davon zu, woher das Protokoll stammt. Konsistente Erkennungslogik über Umgebungen hinweg ist wichtiger als jede einzelne Erkennungsregel. Wenn Ihre On-Prem-Erkennungen und Cloud-Erkennungen unterschiedliche Taxonomien verwenden, verwalten Sie zwei mentale Modelle des gleichen Angreifers.
5. Erstellen Sie Playbooks, die tatsächlich die Grenze überschreiten. Ein Insight, der bei anomalem Cloud-seitigen Zugriff ausgelöst wird, sollte automatisch gegen Ihr On-Prem-Asset-Inventar und Ihre Identitätsdaten angereichert werden können, anstatt an der Grenze des Tools zu stoppen, der zufällig den Alert generiert hat.

Wie das in der Praxis aussieht

Dies ist der eigentliche Anwendungsfall für Cloud SIEM: Es erfasst AWS, Azure, GCP, Kubernetes, Linux, NGINX und On-Prem-Quellen in eine normalisierte Pipeline, anstatt einen Haufen von getrennten Tools, die alle behaupten, „einheitlich“ zu sein.

DojoAI argumentiert über diese unterschiedlichen Quellen hinweg, anstatt jede als ihre eigene Insel zu behandeln, verbindet ein Signal aus einer Cloud-Kontrolleben mit Aktivität auf einem On-Prem-Endpunkt, ohne dass Ihr Analyst die beiden manuell zusammennäht. Und weil Erkennungen unabhängig von der Quelle konsistent auf MITRE ATT&CK abgebildet werden, kann der SOC Analyst Agent einen Insight auf die gleiche Weise triage, ob er von einem VPC-Flow-Log oder einer Firewall auf einem Rack stammt, den Sie vergessen haben, dass er noch eingesteckt ist.

Letztes Wort

Niemandes Infrastruktur ist sauber. Die Organisationen, die verletzt werden, sind nicht diejenigen, die Hybrid betreiben; das ist fast jeder. Sie sind diejenigen, die Erkennung für jede Umgebung separat kauften und annahmen, dass die Grenzen sich selbst kümmern würden. Angreifer haben die Grenzen bereits gefunden. Die einzige Frage ist, ob Sie sie zuerst finden.

Führen Sie Erkennung über Cloud und On-Prem durch und spüren die Grenzen? Sehen Sie, wie Sumo Logic Cloud SIEM Hybrid-Umgebungen handhabt.