669226129
Gorodenkoff | shutterstock.com
Trotz Millioneninvestitionen in Security Operations Center (SOCs) und modernsten Detection-Technologien sind Breaches weiterhin an der Tagesordnung – Tendenz weiterhin steigend.
In meiner Erfahrung reagiert nur etwa jedes zwanzigste SOC effektiv auf die ausgeklügelten identitätsbasierten Angriffe, mit denen wir heute konfrontiert sind. Das ist allerdings kein technologisches, sondern ein Paradigmenproblem. Und es ist an der Zeit, zu erkennen, dass unser derzeitiger Ansatz für den SOC-Betrieb gescheitert ist.
7 Gründe für die SOC-Krise
Bevor wir uns mit der Lösung des SOC-Problems befassen, werfen wir zunächst einen Blick auf die zentralen Herausforderungen, die die SOC-Krise erst geschaffen haben.
1. KI-gestütztes Social Engineering
Um die jahrelangen Bemühungen um den Aufbau ausgefeilter Abwehrmechanismen im Bereich Identity & Access Management auszuhebeln, bringen Cyberkriminelle die Nutzer mittlerweile vornehmlich dazu, selbst ihre Zugangsdaten zu “liefern”. Zuträglich ist ihnen dabei auch und insbesondere künstliche Intelligenz (KI). Sie ermöglicht es, Social-Engineering-Kampagnen besonders überzeugend zu gestalten, um die einzige Komponente auszunutzen, die sich nicht patchen lässt: der Mensch.
Bei einem unserer Kunden haben wir kürzlich fast 100 Konten vorgefunden, die immer noch mit Abwandlungen des Nicht-Passworts ABC123 “abgesichert” waren. Wenn Daten im Dark Web verfügbar sind und KI dabei helfen kann, persönliche Informationen für gezielte Angriffe zu sammeln, werden solche Schwachstellen zu riesigen Sicherheitslücken. Um diesen Angriffsvektoren entgegenzuwirken, braucht es völlig neue Ansätze.
2. Die Identity-Security-llusion
MFA-Token, Single-Sign-On-Systeme und Identity-Management-Plattformen vermitteln ein Gefühl der Sicherheit. Bis ein Angreifer die Identität eines legitimen Benutzers annimmt – dann sind all diese teuren Kontrollmechanismen wirkungslos. Neben Social Engineering kommen auch Browser-basierte Angriffe und Cookie-Diebstahl als mögliche Angriffsvektoren in Betracht, um Authentifizierungs-Kontrollen zu umgehen.
Das Problem liegt darin, dass heutige Systeme zwar Konten überprüfen, aber nicht, ob die Person die sich einloggt, tatsächlich die richtige ist. Gelangen Angreifer an die Zugangsdaten von Benutzern, können sie sich zudem meist über längere Zeiträume im Netzwerk einnisten und im Rahmen der normalen Parameter agieren. Nehmen wir an, ein Benutzer meldet sich normalerweise um 9 Uhr morgens an, liest die Nachrichten, überprüft seine E-Mails und folgt von Montag bis Mittwoch einem vorhersehbaren Muster. Am Donnerstag greift er plötzlich auf die SaaS-Anwendung eines Drittanbieters zu, die er noch nie zuvor verwendet hat. Diese Abweichung sollte eigentlich sofort auffallen, aber in den meisten SOCs fehlen die dazu nötigen Behavioral-Analytics-Lösungen.
3. Tools ohne Integration
Wenn Sie heute ein beliebiges SOC in einem Unternehmen betreten, finden Sie im Regelfall eine überwältigende Auswahl an Tools vor. Etwa:
SIEM-Systeme oder
KI-gestützte Threat-Detection-Lösungen.
Die grundlegende Sicherheitshygiene lässt jedoch trotz dieses technologischen Arsenals oft zu wünschen übrig. In meiner Laufbahn habe ich Unternehmen erlebt, die auf Millionen-Budgets für Security sitzen – und dennoch weder über grundlegende Asset-Register, noch einheitliche Passwortrichtlinien oder eine umfassende Patch-Management-Strategie verfügen. Um es klar zu sagen: Sämtliche Scanning Tools und Monitoring-Plattformen nützen nichts, wenn das Verständnis darüber fehlt, was eigentlich geschützt werden soll.
Das Problem wurzelt entsprechend auch nicht in den Tools selbst, sondern vielmehr in einem Deployment-Flickenteppich-Ansatz, mangelnder Integration zwischen Systemen sowie fehlender Feinabstimmung und Optimierung.
4. Konfigurationsfehler
Noch besorgniserregender ist, dass traditionelle Vulnerability-Management-Programme Konfigurationsfehler regelmäßig völlig außer Acht lassen. Denn diese sind insbesondere in großen Unternehmen mit organischem Systemwachstum, unterschiedlichen System-Ownern, Legacy-Umgebungen und Schatten-SaaS-Integrationen unvermeidlich.
Identity-Systeme, die domänenübergreifend inkonsistent konfiguriert sind oder Cloud Services mit zu freizügigen Zugriffsrichtlinien ermöglichen Angreifern oft, sich lateral durch das Netzwerk zu bewegen. Dennoch verfügen die meisten Unternehmen nicht über einen systematischen Ansatz, um diese architektonischen Schwachstellen zu identifizieren und zu beheben.
5. Das SOC-Modell
Das ideale SOC wäre intern ausgerichtet und mit Mitarbeitern besetzt, die den Kontext, die Systeme und die Geschäftsprozesse Ihres Unternehmens verstehen. Diese Menschen wissen, welche Assets kritisch sind, kennen die normalen Verhaltensmuster der Benutzer und können fundierte Entscheidungen über die Risikotoleranz treffen. Interne SOCs sind jedoch mit enormen Kapazitätsengpässen konfrontiert. Vor allem haben Unternehmen Schwierigkeiten damit, qualifizierte Analysten für den 24/7-Betrieb zu finden. Finanzielle Zwänge machen es zudem schwierig, die Gemeinkosten zu rechtfertigen – insbesondere wenn Anbieter eine gleichwertige Abdeckung zu niedrigeren Kosten versprechen.
Externe SOC-Anbieter bieten Rund-um-die-Uhr-Monitoring und spezialisiertes Fachwissen, aber ihnen fehlt der organisatorische Kontext, der es erst möglich, Vorfälle effektiv zu erkennen: Sie verstehen Ihre Geschäftsprozesse nicht, können nicht ohne Weiteres zwischen legitimen und verdächtigen Aktivitäten unterscheiden und verfügen oft nicht über die Befugnisse, entschlossen zu handeln. Dabei spielt auch eine Rolle, wie sich die Beziehung zwischen Anbieter- und Anwenderunternehmen gestaltet. Ich habe schon erlebt, dass externe SOCs Bedrohungen zwar erkennen, dann aber aufgrund von Haftungsbedenken oder unklaren Autorisierungsmaßnahmen nicht handeln.
Hybride SOCs versuchen, internen Kontext mit externer Abdeckung zu verbinden. Das schafft jedoch häufig neue Probleme in Bezug auf Verantwortlichkeiten und Koordination. Wenn die Verantwortung zwischen internen und externen Teams verteilt ist, können wichtige Entscheidungen verzögert werden, die eine umfassende Kompromittierung verhindern.
6. Die Detection & Response-Falle
Kürzlich gelang es uns im Rahmen einer gemeinsamen Simulationsübung mit einem Kunden, innerhalb von drei Stunden nach der ersten Kompromittierung Zugriff auf den Domänenadministrator zu erlangen. Das SOC des Unternehmens – ein renommierter externer Anbieter – identifizierte während dieses gesamten Zeitraums lediglich zwei geringfügige Indikatoren für eine Kompromittierung. Als wir ihnen mitteilten, dass ihr Kunde vollständig kompromittiert wurde, war die Überraschung groß.
Dieses Szenario verdeutlicht die Kluft zwischen unseren vermeintlichen Detection-Fähigkeiten und der Praxis. Die Angriffszeiten werden immer kürzer, die Angriffspfade effizienter und die Verweildauer länger. Parallel benötigen viele SOCs Stunden oder sogar Tage, um Warnmeldungen zu untersuchen, die eigentlich sofortiges Handeln erfordern würden.
Diese Herausforderung ist sowohl psychologischer als auch organisatorischer Natur: SOCs haben regelmäßig “Angst” davor, falschen Alarm zu schlagen, schließlich untergräbt das das Vertrauen und kann in Alert Fatigue münden. Diese Vorsicht führt allerdings regelmäßig dazu, dass subtile Frühindikatoren übersehen werden, die eine vollständige Kompromittierung verhindern könnten. Zu empfehlen sind deshalb Lösungen zur Verhaltensanalyse, die über einzelne Endpunkte hinausgehen und Muster über die gesamte Unternehmensumgebung hinweg erfassen.
7. Kapazitäts-Bottlenecks
Ich habe beobachtet, wie Sicherheitsverantwortliche durch Lieferantenmanagement, Vertragsverlängerungen und Reporting-Pflichten an den Vorstand so überlastet sind, dass sie keine Zeit mehr haben, sich um grundlegende Sicherheitsprobleme zu kümmern. Ist das der Fall, stellt der zeitliche Aufwand für Vendor Management und Co. eine massive, versteckte Kostenposition dar, die Unternehmen selten in ihren Security-Budgets berücksichtigen.
Diesbezüglich ist es an der Zeit, unseren Ansatz für den SOC-Betrieb und Security Monitoring im Allgemeinen grundlegend zu verändern. Security ist nicht durch höhere Budgets, zusätzliche Tools oder mehr Personal “erkaufbar”.
5 Tipps zur SOC-Krisenbewältigung
Wir müssen anerkennen, dass unsere aktuellen SOC-Modelle unzureichend sind, und diese von Grund auf neu aufbauen. Die Frage ist nicht, ob Ihr Unternehmen mit einem ausgeklügelten identitätsbasierten Angriff konfrontiert wird, sondern ob Ihr SOC darauf vorbereitet ist. Erfolgreiche Unternehmen betrachten ihr SOC als eine lebendige Fähigkeit, die ständiger Schulung und Weiterentwicklung bedarf, und nicht als einen statischen Dienst, den man auslagern und anschließend vergessen kann.
Diese fünf Tipps können Sicherheitsentscheider und CISOs mit Blick auf die SOC-Krisenbewältigung voranbringen:
Zuerst die Grundlagen: Bevor Sie in fortschrittliche Threat Detection investieren, sollten Sie sicherstellen, dass grundlegende Sicherheitsmaßnahmen vorhanden sind. Asset Management, einheitliche Passwortrichtlinien, ein umfassendes Patch Management und angemessene Zugriffskontrollen bilden diese Grundlage, auf der sich dann zielführend aufbauen lässt.
Testing in den Betrieb integrieren: Jeder Penetrationstest sollte eine Schulungsmaßnahme für Ihr SOC sein. Bei jedem Red-Team-Einsatz sollte getestet werden, ob Ihre Erkennungs- und Reaktionsverfahren tatsächlich funktionieren. Machen Sie Sicherheitstests zu einer gemeinsamen Aufgabe, die die operativen Fähigkeiten verbessert.
Continuous Validation implementieren: Lassen Sie jährliche Sicherheits-Assessments hinter sich und validieren Sie Ihre Sicherheitskontrollen kontinuierlich. Testen Sie die Erkennungsfähigkeiten Ihres SOC regelmäßig mit kleinen, realistischen Szenarien. Schaffen Sie eine Kultur, in der es mehr zählt, von simulierten Angriffen zu lernen, als auf vermeintlich perfekte Performance-Metriken zu starren.
Kontextbezogene Detection-Fähigkeiten aufbauen: Investieren Sie in Behavioral Analytics. Die Benutzeraktivitäten zu überwachen, sollte mehr sein, als nur einfache Schwellenwertwarnungen. Nur so lassen sich subtile Abweichungen erkennen, die auf eine Kompromittierung hindeuten.
Reaktionsbefugnisse definieren: Legen Sie genau fest, welche Handlungsbefugnisse Ihr SOC hat – egal ob internes oder externes Modell. Dokumentieren Sie diese Befugnisse klar und stellen Sie sicher, dass alle Beteiligten verstehen, wann und wie sie ausgeübt werden können.
(fm)
Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox.
No Responses