Zum Inhalt
GlobalNet
Strategies

Cybersecurity · LOG / 631

CISA: Warum zwei SOCs denselben Angriff unterschiedlich bewältigen

CISAs Vergleich zweier Red-Team-Assessments zeigt: Tools allein entscheiden keinen Angriff. Alert-Tuning, klare Befugnisse und Cloud-Identity-Prozesse bestimmen, wie schnell ein SOC wirksam reagiert.

CISA hat zwei parallel durchgeführte Red-Team-Assessments mit ähnlichen Angriffsmethoden verglichen. In beiden Organisationen erreichte das Red Team eine vollständige Domänenkompromittierung und Zugriff auf sensible Geschäfts- sowie Cloud-Systeme. Dennoch verlief die Verteidigung unterschiedlich: Eine Organisation erkannte und isolierte erste Aktivitäten schnell, die andere konnte den Angriff weder wirksam erkennen noch eindämmen.

Für Unternehmen ist der Vergleich wertvoll, weil er eine verbreitete Fehlannahme korrigiert: Ein Security Operations Center wird nicht allein durch seine Werkzeuge leistungsfähig. Entscheidend ist, ob Signale sinnvoll abgestimmt sind, Verantwortliche handeln dürfen und Cloud-Identitäten nach einer Kompromittierung tatsächlich entzogen werden können. Selbst schnelle Erkennung verhindert nicht automatisch den gesamten Angriff, verbessert aber die Ausgangslage für Eindämmung und Aufarbeitung.

Was der CISA-Vergleich bestätigt

CISA nennt drei zentrale Ursachen für schwache Incident Response: schlecht abgestimmte Erkennungswerkzeuge, organisatorische Silos und unterschätzte Cloud-Risiken. Ohne belastbare Baseline und Alert-Filterung überlasten Fehlalarme und Routineereignisse die Verteidiger. Unklare Zuständigkeiten und bürokratische Hürden verzögern Entscheidungen. In der Cloud fehlen zudem häufig Kontrollen und eingeübte Verfahren für einen kompromittierten Zugang.

Bestätigt ist außerdem, dass beide geprüften Umgebungen trotz unterschiedlicher Reaktion vollständig kompromittiert wurden. Daraus folgt nicht, dass frühe Erkennung wirkungslos wäre. Es zeigt vielmehr, dass ein einzelner Alarm keine abgeschlossene Verteidigung ist. Er muss eine Kette aus Untersuchung, Isolation, Berechtigungsentzug, Token-Widerruf und überprüfbarer Wiederherstellung auslösen.

Reifegradcheck: Kann Ihr SOC aus einem Signal eine Entscheidung machen?

Die folgende Checkliste ist eine betriebliche Ableitung aus CISAs Befunden. Sie richtet den Blick auf die Übergänge zwischen Technik und Organisation. Denn dort entstehen häufig die gefährlichsten Verzögerungen: Ein Alarm ist vorhanden, aber niemand besitzt genug Kontext oder Befugnis, um einen betroffenen Dienst zu isolieren.

  • Baseline: Normale Anmeldungen, privilegierte Aktionen und typische Datenflüsse sind je Umgebung dokumentiert und technisch messbar.
  • Alert-Qualität: Wiederkehrende Fehlalarme werden mit Eigentümer, Entscheidung und Termin bearbeitet statt dauerhaft stummgeschaltet.
  • Eskalation: Für kritische Signale ist festgelegt, wer innerhalb welcher Frist entscheiden und Systeme isolieren darf.
  • Cloud-Sichtbarkeit: Identitäten, Rollen, Workload-Konten und Token-Ereignisse fließen in die Untersuchung ein.
  • Token-Widerruf: Für Zugriffs- und Refresh-Tokens existieren getestete Verfahren, nicht nur eine Passwortänderung.
  • IT und OT: Übergänge zwischen Büro-IT, Cloud und operativer Technik haben gemeinsame Ansprechpartner und getrennte Eindämmungsoptionen.
  • Wiederanlauf: Die Rückkehr in den Betrieb verlangt definierte Nachweise, dass Persistenz, überbreite Rechte und kompromittierte Identitäten entfernt wurden.

Je mehr Punkte nur auf Papier bestehen, desto größer ist das Ausführungsrisiko. Ein Prozesshandbuch hilft wenig, wenn das SOC nachts keine Isolierung auslösen darf oder das Cloud-Team erst am nächsten Werktag erreichbar ist. Für die Geschäftsleitung ist deshalb nicht die Zahl der Dashboards entscheidend, sondern die Zeit von einem belastbaren Signal bis zu einer autorisierten Schutzmaßnahme.

Ein 30-Tage-Plan ohne Plattformwechsel

CISAs Befunde lassen sich zunächst mit den vorhandenen Systemen prüfen. Das begrenzt Kosten und verhindert, dass ein neues Tool organisatorische Lücken verdeckt. Ziel ist ein messbarer Ablauf vom Alarm bis zur Eindämmung.

  1. Woche 1 – Top-Risiken wählen: Drei Angriffsszenarien mit hohem Geschäftsschaden bestimmen, etwa kompromittiertes Administratorkonto, verdächtige Cloud-Workload oder laterale Bewegung.
  2. Woche 2 – Signalkette prüfen: Für jedes Szenario Datenquelle, Alert, zuständige Rolle, Entscheidungsfrist, Isolationsmaßnahme und erforderliche Nachweise dokumentieren.
  3. Woche 3 – Tabletop und Techniktest: Einen realistischen Alarm einspielen, Kommunikationswege messen und den Widerruf betroffener Sitzungen sowie Tokens kontrolliert erproben.
  4. Woche 4 – Lücken schließen: Fehlalarme priorisiert reduzieren, Stellvertretungen festlegen, notwendige Rechte freigeben und offene Risiken mit Termin an die Geschäftsleitung eskalieren.

Gemessen werden sollten mindestens Erkennungszeit, Zeit bis zur Entscheidung, Zeit bis zur Isolation, Zahl notwendiger Übergaben und Vollständigkeit des Identitätsentzugs. Diese Kennzahlen sind keine von CISA veröffentlichten Zielwerte, sondern ein sinnvoller interner Vergleich. Unternehmen benötigen zunächst eine eigene Baseline und sollten Verbesserungen gegen denselben Szenariotyp messen.

Cloud-Identitäten werden zum Incident-Response-Thema

Ein Angriff endet nicht an der Grenze des lokalen Verzeichnisses. Wenn eine kompromittierte Identität weiterhin gültige Cloud- oder Refresh-Tokens besitzt, kann eine lokale Passwortänderung zu kurz greifen. CISA empfiehlt deshalb, Verfahren zum Erkennen, Beheben und Widerrufen von Zugriffs- und Refresh-Tokens umfassend festzulegen und regelmäßig zu überprüfen. Für Workload-Identitäten sollen Conditional-Access-Regeln sowie übermäßige oder ungenutzte Berechtigungen kontrolliert werden.

Die betriebliche Konsequenz ist klar: Identity-, Cloud- und SOC-Teams brauchen einen gemeinsamen Notfallablauf. Darin muss stehen, welche menschlichen und technischen Identitäten betroffen sein können, wie aktive Sitzungen beendet werden, wer Zertifikate oder Secrets sperrt und wie nach der Bereinigung ein kontrollierter Wiederanlauf erfolgt. Diese Aufgaben dürfen nicht erst während des Vorfalls zwischen Teams verteilt werden.

Der CISA-Vergleich ist damit kein Argument für mehr Alarmvolumen. Er ist ein Plädoyer für weniger Rauschen, eindeutige Verantwortung und geübte Eingriffe über IT, Cloud und gegebenenfalls OT hinweg. Unternehmen sollten ihr SOC nicht danach bewerten, ob es Angriffe theoretisch sehen kann, sondern ob es aus einem relevanten Signal rechtzeitig eine wirksame, autorisierte und überprüfbare Handlung macht.

Quelle

  1. CISA: A Tale of Two SOCs