Registrieren Anmelden
RegistrierenAnmelden
Breadcrumb-Navigation
Mit <kes>+ lesen

Auf dem Weg zu automatischen Reaktionen : Der SOCste Sinn : Gefahrenindikator „Objektivität“ am Beispiel BaFin-relevanter IT

Security-Operation-Center (SOC) gehören mittlerweile zum strategischen Standard großer Unternehmen. Mitunter sind sie allerdings selbst ein potenzielles Risiko für die Cybersicherheit, besonders wenn automatische Reaktionen implementiert sind. Unser Autor identifiziert SOC-Risiken und schlägt „Objektivität“ als wichtige Qualitätsgröße vor.

Stephen Fedtke
Lesezeit 27 Min.
Der SOCste Sinn
Der SOCste Sinn

Im Fall sehr großer oder gar systemischer Infrastrukturen ist ein SOC heute schlichtweg Pflicht, um IT-Sicherheitsvorfälle schnell und qualifiziert an das Computer- Emergency-Response-Team (CERT) zu melden. Ziel eines SOC ist die Vereinigung von Know-how und Technik in einer geeigneten Organisation, um negative Sachverhalte über alle Plattformen hinweg schnell sichtbar zu machen. Wesentlich sind IT-Sensorik, Analysefähigkeiten und der Leitstand mit seinen Spezialisten und dem SOC-Handbuch. Das SOC beobachtet und meldet aber nicht nur, es reagiert auch und greift bei Sicherheitsvorfällen entsprechend ein. Durch diese aktive Rolle ergeben sich SOC-eigene Risikoebenen. Im schlimmsten Fall können Angreifer beispielsweise das SOC selbst umgehen oder auch gezielt beschäftigen.

Aufbau und Betrieb eines SOC stellen für die Unternehmen einen erheblichen finanziellen Aufwand dar: geeignete Räumlichkeiten, Beschaffung und Implementierung notwendiger Monitoring-, Analyse und Visualisierungslösungen und schließlich das Personal für einen 24/7-Betrieb – und das alles eventuell mehrfach für verschiedene Zeitzonen. Abgerundet werden die Aufwände durch Zertifizierungen und regelmäßige Audits. Entsprechend anspruchsvoll ist die Erwartungshaltung – auch an die jeweiligen Verantwortlichen.

Für eine hohe Sicherheit ist ein SOC mit schneller Reaktionsgeschwindigkeit und zugleich personal schonender 24/7-Handlungsfähigkeit das Ziel. Verständlicherweise liegen deshalb große Hoffnungen auf hochgradig automatisierten Detektionen und am Ende auch auf automatischen Reaktionen. Die SOC-eigenen Risiken wachsen jedoch mit jeder weiteren Automatisierungsstufe seiner Architektur.

Risiko-Ansatzpunkte

Neben der Technik entsteht der „intellektuelle Aufwand“ beim Aufbau eines SOC in Form des umfangreichen SOC-Handbuchs, das einen Katalog aller relevanten Vorkommnisse ausreichend und vor allem auch verständlich beschreiben muss. Es enthält zudem sämtliche wichtigen Handlungsanweisungen und dokumentiert die organisatorische Integration der SOC-Abläufe, zum Beispiel in Form von Eskalationsstufen und -wegen für eine dem Risiko angemessene Reaktion.

Im Kern geht es im SOC-Regelwert um sehr konkrete und weniger um abstrakte Fragen, die gleichzeitig auch Ansatzpunkte für Risiken sind:

  • Einstufung: Wie dringlich ist ein Vorfall?
  • Eskalation: Welche Eskalationsmöglichkeiten stehen zur Verfügung? Ab „wann“ (Schweregrad, Risikolevel, Uhrzeit etc.) werden die Spezialisten angerufen, um einen Vorfall zu melden und abzuklären?
  • Hilfestellung: Wer kann bei Problemen welcher Komplexitätsstufe überhaupt helfen? Wen zu wecken macht Sinn? Ist er intern oder extern? Was passiert, wenn niemand passendes erreicht werden kann?
  • Reaktion: Wann und von wem darf eine entsprechende Reaktion im Sinne des Erhalts der produktiven Systeme überhaupt abverlangt und ausgeführt werden? Welche Abwägungen sind vor einer Entscheidung für eine Reaktion vorzunehmen? Wer trägt die Verantwortung?
  • Automatische Reaktion: Können Reaktionen zur Entlastung aller und für maximale Reaktivität eventuell auch automatisch erfolgen? Wie riskant sind diese Automatismen?

Inhärent hat die IT stets zum Ziel, auch die auf sich bezogenen Workflows hochgradig zu automatisieren. Im Fall des SOC geht es zugleich um adäquate Reaktionszeiten, die Entlastung der Mitarbeiter und um maximale Komplexitätsreduktion bezüglich der Erfassung und Behandlung eigentlich sehr komplexer Abläufe. Man kann ein SOC daher nicht als bloßes Upgrade einer klassischen Arbeitsvorbereitung betrachten – Letztere beschäftigt sich mit exakt geregelten und geplanten Ereignissen, ein SOC kämpft mit hochgradig Unerwartetem. Die Komplexitätsreduktion ist somit Dreh- und Angelpunkt eines erfolgreichen SOC-Teams.

Deswegen wäre es auch wunderbar, wenn das Security-Information-and-Event-Management (SIEM) beziehungsweise die nachgelagerten Systeme oder lokalen Agenten einen Vorfall einfach selbstständig und ohne manuelle Eingriffe lösen könnten, also präzise nur den ursächlichen Prozess abbrechen, eine potenziell missbrauchte Verbindung stoppen, einen verdächtigen User sperren, einen befallenen Server herunterfahren. Das 24/7-SOC-Team kann so aus bezahlbarem Personal bestehen und am Morgen, gut ausgeschlafen dank ausgebliebener Anrufe, lesen die Spezialisten stressfrei die zur automatischen Reaktion begleitend erstellten E-Mails oder Ticket-Kommentare und studieren nachträglich die Sachlage.

Ein bisschen können die technischen und algorithmischen Herausforderungen automatischer SOC-Abläufe mit denen des autonomen Fahrens verglichen werden: Das Ziel steht fest, der technologische Aufbruch fand auch schon statt, aber der Weg dahin wird Opfer im Sinne des Fortschritts fordern. Analog zur ethischen Grundfrage der künstlichen Intelligenz, wen überfährt das selbstfahrende Auto im Ernstfall oder opfert es sich ehrenhaft selbst, muss auch eine automatische SOC-Reaktion zwischen Verfügbarkeit und Sicherheit eine Entscheidung treffen [1].

Die vollständige Automatisierung des SOC-bezogenen Incident-Managements ist allerdings heute noch unrealistisch, jedenfalls solange man nicht das Risiko „ausgebliebene“ durch „vollkommen überzogene“ Reaktion ersetzen will. Es fällt schwer, einer SOC-/SIEM-Architektur zu erlauben, Applikationen bei kleinsten Anzeichen selbstständig zu stoppen oder Systeme vom Netz zu nehmen, indem auf ein „Hüsteln“ bereits übereifrig reagiert wird oder nur um nachts niemanden wecken zu müssen – die Reaktionen hätten eventuell ein höheres Schadenspotenzial als der Angriff selbst.

Immanente Risiken

Vor lauter positiver Zielsetzung und Begeisterung kann eine wichtige Frage eventuell unbewusst übersehen werden: Welche Risiken gehen möglicherweise von einem SOC selbst aus beziehungsweise welchen Risiken sind die Pfeiler eines SOC selbst unterworfen, einschließlich der Entscheidungen über seine Architektur? Das wären zum Beispiel:
  • Wirkungslosigkeit, Kostenexplosion oder Image-Sorgen durch „Versagen“
  • Infragestellung der Compliance, wenn das SOC notwendige Anforderungen nicht erfüllt („lieber keins als ein non-compliant SOC“)
  • physisch wie psychische Überbeanspruchung des SOC-Teams und anderer Spezialisten durch zu viele und/oder falsche Alarme zu eventuell ungünstigen Zeitpunkten
  • Wissensabfluss durch das SOC nach draußen, zum Beispiel beim SOC-Outsourcing
  • potenzieller Schaden durch falsche Entscheidungen und Reaktionen im Ernstfall, bis hin zu „Fokushima“-ähnlichen Szenarien dank automatisch eskalierter Kettenreaktionen [2]

Nach der Basis-Implementierung unterliegt das SOC mit seinen technischen wie auch organisatorischen Implementierungen einem typischen „Lifecycle“ und wird einer stetigen Bewertung und Verbesserung unterworfen. In größeren Installationen ergibt sich das implizit durch praktiziertes Change-Management, Revision, Auditoren, Compliance-Auflagen, Jahresabschluss oder BaFin-Audits. Eines steht jedoch schon fest, auf dem Weg des SOC in automatisierte Zustände kann und wird noch eine Menge schiefgehen. Bezogen auf das reine Monitoring und Detektieren stehen folgende Risiken im Vordergrund:

  • ausbleibende Alarme
  • falsche Alarme und Feststellungen
  • übersehene Alarme
  • zu viele oder irreführende Alarme
  • Handlungsunfähigkeit oder Überlastung des SOC-Teams und der Linie dahinter
  • fälschlicherweise oder zum falschen Zeitpunkt ausgelöste Reaktionen
  • überzogene Reaktionen
  • vollautomatisch ausgelöste fehlerhafte Maßnahmen

Mitwirkende

Ein gravierendes Problem resultiert auch aus dem Mangel an Fachkräften im Bereich der IT-Sicherheit – ganz zu schweigen von Mitarbeitern mit einem gewissen „Guru-Faktor“, die einen breiten Überblick bei gleichzeitigem Tiefgang mitbringen. Kandidaten dieser Klasse sind am Arbeitsmarkt kaum verfügbar und entsprechend teuer. Hat man sie dann, stellt sich zudem die Frage, ob das SOC das wertschöpfend optimale Einsatzumfeld für sie ist. Daraus ziehen die meisten Unternehmen zwei Schlussfolgerungen: mögliches Outsourcing und der Wunsch nach nachhaltigen Automatismen, um Ressourcen und Mitarbeiter zu schonen.

SOC-Spezialisten entscheiden über Techniken und Logiken und implementieren sie – ohne selbst später in ihrem täglichen Leben in den 24/7-Betrieb involviert zu sein. Entsprechend verfügen sie zugleich über eine hohe Macht und können oft nur durch wenige andere Mitarbeiter hinterfragt werden. Dadurch gewinnen sie durchaus eine Kritikalität wie die der „Privileged User“ und man muss hinterfragen, welches Risiko von ihren Entscheidungen, Empfehlungen und Aktivitäten ausgeht.

Im Fall von externen Mitarbeitern gibt es ein definitiv höheres Risiko. Aber auch bei internen Mitarbeitern mit verbliebener hoher inhaltlicher beziehungsweise interessenbezogener Bindung zu Dritten, wie Software-Herstellern, gilt es, stets auch die notwendige Objektivität im Auge zu behalten, wenn diese am SOC mitwirken. Konkret stellen sich Fragen, ob Dinge schöngeredet werden, damit sie passend wirken oder Lösungen zum Einsatz kommen sollen, um eigene Interessen damit zu fördern.

Es ist somit eine laufende Objektivitätsbewertung notwendig – schließlich besitzen die Experten nachhaltiges Wissen über das SOC und seine Wirkungsweise, was, nebenbei erwähnt, bei externen Mitarbeitern sehr strenge Vertraulichkeitsvereinbarungen mit Vertragsstrafe erforderlich macht. Für eine Risikoanalyse solcher „intellektuell“ extrem privilegierter Nutzer können durchaus die pragmatischen Überlegungen des EPIS-Konzepts angewendet werden [3].

Automatische Reaktion vs automatische Security-Controls

Es gibt sie schon in hoher Zahl und Vielfalt, die automatischen Reaktionen in der IT-Sicherheit – und das risikoarm. Was macht sie im SOC so risikoreich? Hierzu ist eine klärende Abgrenzung hilfreich: Worin liegt der Unterschied zwischen einer automatisierten SOC-Reaktion im Sinne der Incident-Response und den regulären automatischen Security-Controls einer IT, wie sie bereits zahllos im Einsatz sind?

Zu Letzteren gehören typischerweise Authentifizierungsverfahren, Firewall-basierte Zugriffsblockaden, Access-Listen oder File-Permissions zum gezielten Schutz von Files und Directories. Ihnen ist gemein, dass sie sich alle auf vorab definierte und als relevant eingestufte Situationen des regulären und inhaltlich bekannten IT-Betriebs beziehen. Das heißt, es handelt sich um ein relativ überraschungsfreies und interpretationsfreies Umfeld. Zweifelsohne stellen auch hier fehlerhafte Entscheidungen betriebliche Probleme dar, diese wurden meistens aber initial bei der Implementierung und Produktivnahme des Controls etabliert und eventuell korrigiert. Sie treten vorwiegend in kontrollierten und geplanten zeitlichen Momenten auf, beispielsweise bei geplanten Änderungen im Rahmen eines Wartungsfenstern – „no change, no drama.“

Im Vergleich dazu muss ein automatisches SOC-Control, zum Beispiel das einer Angriffsdetektion, in einer sehr viel offeneren, undefinierteren und überraschenden Situation entscheiden, agieren und mit dem Ergebnis zurechtkommen. Die Logik entsprechender Entscheidungsfindungen – in Form eines „Situation X liegt vor“- oder „liegt nicht vor“-Urteils – muss mit einer sehr viel höheren Unschärfe zurechtkommen und es muss zur Risikominimierung wesentlich mehr Aufwand betrieben werden. Deshalb liegen in diesem Bereich große Hoffnungen auf Verfahren der künstlichen Intelligenz.

Risikoanalyse entlang des „Audit Trails“

Die qualitative Hinterfragung eines nach Automation strebenden SOC-Konzepts oder -Betriebs im Sinne einer Risikoanalyse erfordert eine Wanderung entlang des gesamten Verarbeitungspfades, verbunden mit einer genauen Betrachtung der möglichen positiven wie negativen Einflussfaktoren an wichtigen Wegpunkten:

Phase 1: Detektion

In der ersten Phase detektieren und sammeln die Systeme zeitnah relevante Eventdaten auf den Clients und Servern. Das reicht von elementaren Ereignissen, wie Logins, bis hin zu den Ergebnissen eventueller Threat-Detektoren, wie Virenscanner, Vulnerability-Scanner und ATP-Detektoren.

  • Herausforderungen: „Anzapfen“ der Event-Quellen; Echtzeitfähigkeit; Identifikation und Detektion wirklich aller relevanten Ereignisse, also aller Events, die aus Compliance-, Security-, Detektionszielsetzungspflicht wichtig und notwendig sind
  • Risiken: Unkenntnis über relevante beziehungsweise verfügbare Events; Event-Verlust (z. B. durch Flutung oder „out of disk space“-Situationen); Software-Schwächen; für das Monitoring nachteilige Systemänderungen durch operative Abteilungen (z. B. Änderung der OS- bzw. Audit-Konfigurationen)
  • gezielt bösartige Einflussnahmen: gezielte Event- Unterdrückung (z. B. durch einen Angreifer oder privilegierte Software); Erzeugung von falschen Events zwecks Anschuldigung, Ablenkung oder gezielte Auslösung von Reaktionen; Stoppen der Agenten oder der Überwachungssoftware
  • Praxisempfehlung: Überwachung der Eventquellen in Bezug auf Manipulationen oder gezielte Fake-Anwendung; eventuell Redundanz in der Überwachung schaffen

Phase 2: Weiterleitung

Die von Servern und Clients gesammelten Event-Daten werden an die zentrale  Archivierung weitergeleitet und als forensisches Fundament abgespeichert.

  • Herausforderungen: unverfälschter, abhörsicherer, zuverlässiger und für die Echtzeitfähigkeit schneller Transfer; anschließende garantierte Entgegennahme der Eventdaten, verbunden mit der grundsätzlichen Registrierung und Speicherung sowie der Erkennung von Ausfall oder Lücken in der Belieferung; Synchronisierung aller auftretenden Timestamps
  • Risiken: Verlust oder Verzögerung beim Transfer beziehungsweise beim Empfang (z. B. UDP statt TCP, Collector ist „unten“, „out of xxx“-Fehler); Verschlüsselungsprobleme (z. B. abgelaufene Zertifikate); Lücken bleiben unbemerkt
  • gezielt bösartige Einflussnahmen: Blockieren oder Verzögern des Transferwegs durch Angriffs- oder Manipulationstechnik; Einschleusen von falschen Events
  • Praxisempfehlung: Von Anfang an wie im Kontext eines Service-Level-Agreements (SLAs) denken – das vereinfacht auch späteres eventuelles Outsourcen; bei der Implementierung stets alle notwendigen Überlegungen auf Client- und Server-Ebene für den Fall einschließen, dass Events nicht abgeliefert werden können (Für welchen Zeitraum ist ein Zwischenspeicher vorzusehen? Wie oft wird eine Nachlieferung probiert? Auf welche alternativen Empfänger könnte man ausweichen?)

Phase 3: Analyse

In dieser Phase analysiert das SIEM die Events über alle Gattungen und über alle Plattformen hinweg. Das erfolgt mithilfe schwellwertbasierter Verfahren, Korrelationen und eventuell mit Methoden der künstlichen Intelligenz und dient der Ableitung und damit Detektion spezifischer Sachverhalte oder Phänomene von unterschiedlicher Signifikanz und Kritikalität. Das kann von einem möglichen Verdacht bis hin zur „glasklaren“ Feststellung reichen.

  • Herausforderungen: Scannen der diversen Log- und Meldungsformate; ausreichendes (plattformbezogenes) Wissen über die für eine hohe Sicherheit notwendigen Analysen; die in der Praxis für das konkrete IT-Umfeld möglichen Szenarien kennen, inklusive firmenspezifisches operatives Wissen; die genannten Bereiche bezüglich der Relevanz risikomindernd einordnen; im Fall KI-basierter Verfahren über eine geeignete Lernbasis verfügen – vor dem Anlernen müssen alle Ebenen perfekt funktionieren, sonst wird Falsches antrainiert; Berücksichtigung und Kompensation von Latenzzeiten bei der Event-Anlieferung und unterschiedlicher Zeitzonen bei Timestamps
  • Risiken: Wissenslücken, Denk- und Logikfehler; bisher unbekannte Event- oder Format-Varianten (z. B. ändern sich Meldungsformate in Verbindung mit Updates (Phase 1) oder es ergeben sich plötzlich Zeilenumbrüche aufgrund unüblich langer Namen); fehlende Vorstellungs- oder Willenskraft der Mitarbeiter, die die Detektion implementieren; schlechtes Testen; potenzielle Unmöglichkeit des Testens in Form realen Nachstellens; im Fall generalisierter Detektionen (z. B. Failed-Logins), dass wirklich alle genutzten Plattformen „angekoppelt“ sind, also alle entsprechenden Event-IDs, alle Formate…; ungünstige Entscheidung zwischen White- und Blacklist-Verfahren (z. B. ist positives Auswählen relevanter Fälle fehlersensibler gegenüber Match-Fehlern oder Formatabweichungen als der Ausschluss irrelevanter Fälle)
  •  gezielt bösartige Einflussnahmen: gezieltes Ausspähen und Analyse der Regeln, um unter dem Radar zu bleiben, zum Beispiel eigene Prozesse analog zu Whitelist-Kandidaten benennen oder die Anzahl der Angriffsversuche pro Zeiteinheit durch Verteilung gezielt unter dem Schwellwert halten
  •  Praxisempfehlung: sämtliche Details über das SOC streng geheim halten; alle Mitwirkenden zu Vertraulichkeit verpflichten, besonders externe Mitarbeiter (Vertraulichkeitsvereinbarung mit Vertragsstrafe)

Phase 4: Melden

Die Ergebnisse müssen entsprechend visualisiert und an den First-Level-Verantwortlichen und das 24/7-SOC-Team weitergeleitet werden. Dazu gehören die inhaltliche Vermittlung der jeweiligen Sachverhalte und eventuelle Handlungsnotwendigkeiten (SOC-Handbuch).

  • Herausforderungen: adäquate Medien und Darstellungsformen auswählen; die Erkenntnisse korrekt klassifizieren und priorisieren; für das SOC-Team verständliche Dokumentationen zu den einzelnen Detektionen und den sich in ihnen begründenden Sachverhalten; ausreichende Anleitung zur Abwägung der Situation vor deren Eskalation beziehungsweise der Einleitung von Reaktionen; laufende fachliche Weiterbildung des SOC-Teams
  • Risiken: Detektion wird übersehen; Sachverhalt wird nicht oder falsch verstanden; falsche Rückschlüsse und damit inadäquate Maßnahmen; Team wird zu schnell nervös oder eskaliert zu schnell, um Verantwortung zügig und in Breite weiterzureichen; sprachliche Missverständnisse
  • gezielt bösartige Einflussnahmen: gezielte Beschäftigung und Ablenkung des SOC-Teams durch vorsätzlich erzeugte Events, zum Beispiel damit ein Top-10-Dashboard nur „Nebelkerzen“ umfasst; Auslösung nächtlicher Fehlalarme, gefolgt von eigentlicher Aktivität
  • Praxisempfehlung: In den Dokumentationen sind klar beide Extreme zu beschreiben: wann in jedem Fall und wann keinesfalls reagiert werden muss. Die Negativabgrenzung ist ebenso essenziell, um zu verhindern, dass fehlendes Wissen oder schlichtweg Verallgemeinerungen in der Dokumentation zu Fehlentscheidungen führen.

Phase 5: Automatische Reaktion

In dieser Phase findet eine automatische Reaktion statt. Das heißt, ein Sicherheitsprozess entscheidet autonom, ob es notwendig, sinnvoll und verhältnismäßig ist, auf den jeweiligen Vorfall zu reagieren, und leitet je nach Ergebnis vorbereitete Reaktionen ein. Dabei löst er diese direkt aus oder unterbreitet dem SOC-Team zunächst nur einen Vorschlag, den es dann bestätigen muss.

  • Herausforderungen: Implementierung absolut signifikanter Detektionen und Reaktionsregeln; ab einer bestimmten Kritikalität der ausgelösten Reaktion muss False-Positive-Freiheit quasi garantiert sein, ansonsten wird es teuer; die Logik muss „fail-safe“ sein in Bezug auf die aus den vorangehenden Phasen eventuell nicht erhaltenen Informationen – schwächelt das SOC operativ, z. B. liefern relevante Agenten seit geraumer Zeit keine Daten, darf auch nicht mehr automatisch reagiert werden
  • Risiken: Detektionen sind falsch oder unscharf; Reaktionen bewirken echten Schaden oder lösen eine Kettenreaktion aus; es gibt keine Limits für Reaktionsvolumen, -breite oder -dauer und es kommt zu einer „sich aufschaukelnden Schwingung“ („Fokushima“)
  • gezielt bösartige Einflussnahmen: gezieltes Auslösen von Reaktionen durch Vorgaukeln entsprechender Events, auf welchen die automatischen Reaktionen beruhen (eine Unterdrückung von Detektionen wäre ein Risiko in den Phasen 1 und 2); bei der Portierung der Detektionen und Reaktionen vom Test- oder Evaluierungssystem in die Produktion werden relevante Details übersehen
  • Praxisempfehlung: Entsprechende Reaktionen zunächst in einem „Warnmodus“ laufen lassen, statt sie gleich scharf zu schalten. Es gilt zu beachten, dass auch eine zeitlich lange Evaluierung im Testumfeld keinerlei Signifikanz für den produktiven Betrieb bewirkt (stets wieder „bei null Vertrauen“ beginnen).

Phase 6: Evaluierung

Es sollte regelmäßig durch Simulationen oder Testfälle evaluiert werden, dass das SOC wirksam arbeitet. Eine solche Prüfung muss auch erfolgen, wenn keinerlei Änderungen im SIEM, den Korrelationsregeln oder in anderen Systemen vorgenommen wurden, da sich das Umfeld beeinfl ussend geändert haben könnte.

  • Herausforderungen: Events zu testen, die eigentlich und hoffentlich niemals eintreten. Hierzu kann es notwendig sein, selbst das SIEM mit falschen Events zu befüllen.
  • Praxisempfehlung: so viele Tests wie möglich via Test-Jobs, -Prozeduren, -Skripte vornehmen, das erleichtert die Wiederholbarkeit; wie im Software-Test sollten für eine hohe Objektivität auch Mitarbeiter einbezogen werden, die nichts über die Details der Filter wissen

Ein generelles Risiko stellen Latenzzeiten und Timestamp-Unterschiede dar, die sich mit jeder Phase und jedem Übergang potenziell verbinden – beispielsweise vertragen zeitnahe Korrelationen keine zu sehr verspäteten Anlieferungen oder unkoordinierte Timestamps.

Risikovermeidung durch Objektivität

Es versteht sich für SOC-Mitarbeiter von selbst, dass jegliches Wissen über die Verfahren und Regeln des SOC streng vertraulich sind. Ansonsten können Angreifer Prozesse, Benutzer oder Dateien gezielt benennen oder Zeitpunkte auswählen, um in Whitelists einen „segnenden“ Match zu erzielen oder einen in Blacklists zu verhindern und so unentdeckt bleiben. Externe Mitarbeiter sind in ein SOC-Projekt nur im Rahmen einer sehr strengen Vertraulichkeitsvereinbarung mit Vertragsstrafe und „need to know“-Wissenszugriff einzubinden.

Achtung sollte man darüber hinaus auch dem nicht weniger wichtigen Güte- und Erfolgsfaktor für ein risikoarmes SOC schenken: ein sehr hohes Objektivitätsniveau [4]. Eigenbezüge, Verflechtungen und fehlende Unabhängigkeit haben „Schwäche“ zur Folge. So ist ein Security-Administrator, der gleichzeitig auch die Aufgabe des Auditors innehat, nicht objektiv. Problematisch ist auch ein Plattform-Outsourcing, bei dem der Auftragnehmer zugleich sämtliche Details und Techniken der für ihn vorgesehenen Überwachung mitbestimmt. Aber auch externe oder interne Entscheidungsträger oder „Meinungsmacher“, die verdeckt weiterhin früheren Interessen und Verpflichtungen folgen und entsprechende Entscheidungen treffen oder vorantreiben, mindern die Objektivität auf dem jeweiligen Gebiet. Insgesamt gibt es viele Gründe, wie sich in der SOC-Praxis ein Mangel an Objektivität einschleicht – von Vorsatz abgesehen, sind die Hauptursachen hierfür jedoch Kompetenzmangel oder Pragmatismus.

Im Rahmen einer SOC-Implementierung treten Objektivitätsmängel potenziell entlang des gesamten Phasenmodells in Form von Technik und Beteiligten auf, zum Beispiel bei der Auswahl der Scanner und Agenten. Die fehlende Objektivität und damit einhergehend die eventuell geringe Wirksamkeit resultiert daraus, dass die erhoffte Kraft und Stärke sich nur auf sich selbst bezieht. Man könnte auch vom „Münchhausen-Faktor“ einer Technik, Konzeption oder Organisation sprechen, wenn deren Wirksamkeit (Kraft) auf einem hohen Grad an Eigenbezug beruht – also einer Pseudokraft und -wirksamkeit analog zu Baron Münchhausen, der sich bekanntlich an den eigenen Haaren hat aus dem Sumpf ziehen können. Die Objektivität einer Überwachung schwindet beispielsweise, wenn deren Code und sogar die Administrationsdaten im überwachten Umfeld selbst enthalten sind, statt getrennt und damit neutral und geschützt zu sein.

Es gibt verschiedene mögliche Ansätze, um einen Objektivitätsfaktor (OF) mathematisch auszudrücken, also ein Maß für die Unabhängigkeit, Unbefangenheit und Neutralität einer Software-Komponente, eines Entscheidungsträgers oder auch Beraters zu finden. So bieten sich Key-Performance-Indikatoren (KPIs) aus dem Bereich „Software Reuse Metrics“ an – steigt die Reusability doch direkt mit ihrer Unabhängigkeit [5]. Denkbare Ansätze für einen Objektivitätsfaktor (OF) wären:

 

 

 

Objektivitätsfaktor
Objektivitätsfaktor

Der OF ist skaliert zwischen 0 und 1. Ein hoher OF bringt eine hohe Objektivität zum Ausdruck und damit einen hohen Grad an Unabhängigkeit und Entflechtung.

Aber was sollte den Leiter eines SOC oder einen Auditor veranlassen, über so etwas Abstraktes wie einen möglicherweise zu geringen Objektivierungsfaktor der Komponenten und Mitwirkenden nachzudenken? Es sind das hohe Vertrauen und die durch seine Gesamtkosten hervorgerufenen sehr hohen Erwartungen, denen ein SOC gerecht werden muss – schließlich sind in ihm alle Kräfte und damit Aufwände gebündelt worden. Spätestens mit der Implementierung automatischer Reaktionen steigt die Verantwortung in allen Phasen um ein Vielfaches, und entsprechend die Pflicht zur Suche nach versteckten Risiken – und das geht nur durch strikte Objektivierung.

Ursachen mangelnder Objektivität

Welche Rahmenbedingungen fördern nun das Risiko einer zu geringen Objektivität? In der Praxis lassen sich unter anderem folgende Faktoren identifizieren:

  • Oft fehlt es an Offenheit für verschiedene Hersteller im Bereich der Sicherheitslösungen. Eine solche Vielfalt ist sehr wichtig, allerdings ist sie nicht für alle Plattformen durch den sie umgebenden Software-Markt gegeben. Vielfalt bedeutet nämlich Wettbewerb, Unvoreingenommenheit, Unabhängigkeit, Druck zum Fortschritt, kurzum Objektivität dank Meinungsvielfalt. Während „alles integriert und aus einem Hause“ für das operative Zusammenspiel von Software ideal und dienlich ist, muss man im Bereich Sicherheit teilweise einem inversen Denkansatz folgen. Nicht ohne Grund bewertete das Bundesamt für Sicherheit in der Informationstechnik (BSI) im Bereich der Virenscanner [6]: „Je nach vorliegender Systemlandschaft können diese Ziele unter Umständen nicht durch die Auswahl eines einzelnen Viren-Schutzprogramms erreicht werden, sondern es müssen gegebenenfalls mehrere unterschiedliche Produkte beschafft und eingesetzt werden.“
  • Man hängt vollständig von externem Personal ab oder auch von einer einzelnen internen Person, die mit ihrem Wissen oder Willen faktisch alle Entscheidungen dominiert.
  • Das exzessive Einbinden externer Parteien birgt Objektivitäts- und Sicherheitsrisiken zugleich, wenn strenge Spielregeln und transparente Interessen fehlen.
  • Zu hoher Herstellerglaube und im Ansatz „verliebte Kritiklosigkeit“ gegenüber den Lösungen und Services.
  • Im Rahmen einer Outsourcing-Vertragsverhandlung sollte der Arbeitsort der später für das System faktisch verantwortlichen Spezialisten aufgesucht werden. Auch hier gilt es, zu objektivieren und zu prüfen, in welchen politisch oder korruptionsbelasteten Regionen die Dienstleister ansässig sind. Fördern eventuell Großraumbüros mit maximaler Packungsdichte potenziell massive Ausfälle durch Grippe, Pandemie, physische Zerstörung? All das kann zu einem hohen Risikopotenzial führen und ist im Fall eines SOC nur noch mit bewusst wenig Objektivierung akzeptabel.
  • Viel allgemein zugängliches Wissen über eine Sicherheitslösung und deren interne Funktionsweise macht es Angreifern definitiv leichter, einen optimalen Angriffsvektor zu finden. Ist eine solche Lösung objektiv betrachtet optimal sicher?

Beispiel Mainframe

Für eine Beispielanalyse der Objektivität eignet sich der Mainframe besonders gut, da er wichtig genug ist und gegebenenfalls einen IT-kritischen Charakter aufweist, zum Beispiel im Fall des Finanzsektors. In die Bewertung von Risiken fließen zwei wesentliche Faktoren ein, die Eintrittswahrscheinlichkeit und die Tragweite. In der Finanzindustrie ist die Tragweite meistens hoch und damit auch das Risiko, hier ist also „eigentlich alles riskant“. Glücklicherweise fördert die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) seit Jahren, dank ihrer Neutralität und den regelmäßigen Rundschreiben, nachhaltig den Geist der risikomindernden Objektivierung. Ihre Audits werden nicht unbegründet gefürchtet. Dieses Streben mündete zuletzt in den sogenannten „Bankaufsichtlichen Anforderungen an die IT (BAIT)“ [7].

Der Mainframe gilt als wichtige Plattform – die Erwartungen sind entsprechend hoch, nicht zuletzt wegen der grundsätzlich höheren Betriebskosten. Bei der Absicherung der Mainframe-Plattform ist auch deshalb auf besonders hohe Objektivität zu achten. Von den oben aufgeführten Risikofaktoren treffen in der Praxis einige auf den Mainframe zu. So hat das Bundeskartellamt in seiner im Juni dieses Jahres getroffenen Entscheidung über den Zusammenschluss von IBM und T-Systems auf dem Mainframe-Infrastruktur-Markt sogar offen zum Ausdruck gebracht [8]: „Für die Erbringung der Mainframe-Infrastruktur-Dienstleistungen ist geschultes und erfahrenes Personal von großer Bedeutung, aber auf dem betroffenen Markt wegen fehlenden Nachwuchses für die Legacy-Systeme sowie längerer Ausbildungszeiten knapp und gesucht.“ Das schwächt insgesamt die Chance für ein objektives Hinterfragen.

Als Beispiel für eine Eigenüberwachungstechnik mit potenziell geringerem Objektivierungsfaktor und möglicherweise fehlender Wirksamkeit bei hoher Professionalität im Angriffsvektor kann die Accessor-Environment-Element-(ACEE)-Manipulationsdetektion aufgeführt werden, die mit dem neuen Betriebssystemlevel z/OS 2.4 eingeführt wird [9]. Das ACEE ist ein Security-Kontrollblock, der sämtliche Berechtigungen und Privilegien des Benutzers in Form von Bits und Bytes kodiert beinhaltet. Das ACEE eines Benutzers wird mit dem Login anhand der Security-Datenbank aufgebaut. Mitunter ist es ein einzelnes Bit, das einen Benutzer zum Security-Administrator macht. Folglich ist es das Ziel eines professionellen Angreifers, das ACEE seines Prozesses so zu manipulieren [10], dass er danach mit all umfänglichen Rechten versorgt ist. Um das zu verhindern, liegt das ACEE in einem für normale Prozesse schreibgeschützten und nur lesbaren Speicher, den ausschließlich privilegierte Prozesse ändern können, zum Beispiel das Betriebs- oder Securitysystem selbst. Deswegen benötigt ein Angreifer entweder einen Exploit oder er ist ein Systemprogrammierer.

Die Ursachen für die potenziell geringe Objektivität dieser neuen Eigenüberwachung zur ACEE-Manipulationsdetektion sind in der hohen Verquickung von Programmcode beziehungsweise Steuerung und überwachtem Sicherheitssystem begründet:

  • Die Manipulationsüberwachung wird über das Securitysystem selbst ein- und ausgeschaltet, nämlich über die Aktivierung einer Ressourcen-Klasse.
  • Whitelists werden mithilfe ganz normaler Profile im Securitysystem selbst definiert, wie für gewöhnliche Ressourcen.
  • Wenn Angreifer eine Administrator-User-ID gekapert haben, können sie die notwendigen Whitelist-Definitionen im Sicherheitssystem sogar selbst hinzufügen.
  • Die Protokollierung erfolgt in einer so allgemeinen Form, dass Angreifer das Format imitieren und so falsche Events erzeugen können. Im Fall etablierter automatischer Reaktionen können diese gezielt ausgelöst werden.
  • Generell bestehen wesentliche Teile eines Angriffsvektors in der Ausnutzung von Schwachstellen. Lässt sich durch einen Exploit das Sicherheitssystem zielgerichtet außer Kraft setzen, schwächelt durch die enge Verflechtung, also der geringen Objektivität, mit hoher Wahrscheinlichkeit auch seine Eigenüberwachung. Denn hat der Angreifer erst einmal ein bestimmtes Privilegien-Niveau erreicht, kann er durch Ändern von ein paar Bits gleich noch die Eigenüberwachung des Sicherheitssystems deaktivieren. Ein in der Zielsetzung grundsätzlich positiv zu bewertendes Sicherheitsfeature verliert somit durch fehlende Objektivität seine Schutzfunktion.

Würde man diese Punkte in die obigen Formeln „einsetzen“, käme durch die hohe Verflechtung ein sehr geringer Objektivitätsfaktor (OF) heraus. Die Verantwortlichen hätten so die Möglichkeit, das im Rahmen eines SOC-Audits oder -Neuaufbaus zu thematisieren. Die hier angestellten Überlegungen zur Messung von Objektivität lassen sich auch analog auf andere Plattformen, Lösungen oder Verarbeitungsphasen übertragen.

Objektive Macht der Gurus
Objektive Macht der Gurus

Angriffsbeispiele

Wichtig für ein sicheres SOC ist, dass die Verantwortlichen die Qualität ständig hinterfragen: Wie unabhängig arbeitet das SOC? Wie eng sind Techniken, Mitarbeiter, Outsourcing-Dienstleister miteinander verzahnt? Das folgende Beispiel eines Angriffs auf eine IT-Infrastruktur zeigt, wie breit ausgelegt solche Risikoüberlegungen aussehen können.

Ziel

Kriminelle wollen einen Angriff auf die kritische IT-Infrastruktur eines größeren  Unternehmens unbemerkt ausüben, indem sie das „Radar des SOC unterfliegen“.

Kernherausforderungen

Von wem und wie können notwendige interne Security- und SOC-Details in Erfahrung gebracht werden? Wer kann sogar direkt im privilegierten Bereich Aktivitäten ausführen?

Ausgangslage

Eine negative Intention in Bezug auf das Unternehmen geht von einer oder mehreren IT-Fachleuten aus, nachfolgend „Angreifer“ genannt, von denen einer entweder a) im internen systemnahen IT-Betriebsumfeld (System-Technik) oder b) im Support eines der Software-Hersteller arbeitet.

Beispiel-Szenario 1: Outsourcing

Der Angreifer ist ein direkt am System arbeitender privilegierter Mitarbeiter des Outsourcing-Dienstleisters, zum Beispiel mit Sitz in politisch zu 99 Prozent stabilen Verhältnissen. Das Unternehmen hat viel nach außen vergeben und lebt das Motto „endlich alles weg“ (inkl. Know-how). Aufgrund des allgemeinen Spezialistenmangels befindet sich das betreuende Personal mit sehr hoher Wahrscheinlichkeit im osteuropäischen Ausland. Durch die per Job vorhandenen Privilegien ist es für den Angreifer einfach, die notwendigen Informationen zu erhalten oder entsprechende Konfigurationen vorzunehmen.

Beispiel-Szenario 2: Support

Der Angreifer ist ein im Software-Support-Umfeld tätiger Mitarbeiter, weltweit irgendwo lokalisiert. Bedingt durch einen Software-Fehler wird ein System-Dump von einem Produktionssystem des Unternehmens „gezogen“ und routinemäßig an das Service- und Support-Umfeld des zuständigen Herstellers übertragen. Grundsätzlich wurde vom Hersteller eine zur Datenschutzgrundverordnung (DSGVO) konforme Speicherung der Diagnosedaten in Europa garantiert. Das Risiko besteht nun darin, dass eine weltweit verteilte größere Anzahl Mitarbeiter auf diese in Europa gespeicherten Diagnosedaten zugreift, um aufgetretene Probleme zeitnah und kostenoptimal zu lösen. Werden diese Dokumente vor dem Versand nicht anonymisiert, kann der Angreifer die essenziellen Security-Konfigurationen und mögliche Systemschwachstellen ermitteln [11]. Faktisch mutieren Software-Hersteller und ihre Subunternehmer im Fall nicht anonymisierter Diagnosedokumente oder direktem Systemzugriff zu Insidern. Im Fall der Nutzung von Lösungen mit hoher allgemeiner Transparenz ihrer Interna steht dank des nicht anonymisierten Dumps eventuell auch Wissen über die Detektions- und Korrelationsregeln bereit.

Welche Rückschlüsse lassen sich nun aus den Beispielen ableiten? Für eine Absicherung des SOC gegen das Risiko verdeckter Informationspreisgabe und faktischer Insider sind folgende Schritte wichtig: strenge Grundregeln zur Geheimhaltung, strikte Anonymisierung von Logs und Dumps vor der Weiterreichung an Dritte und ergänzende Nutzung einer technisch unabhängigen und damit „OF-hohen“ Überwachungslösung.

Fazit und Kernempfehlungen

In der Praxis haben noch nicht alle Security-Operation-Center die höchste Reifestufe erreicht. Um ein sicheres SOC betreiben zu können, ist eine Risikoanalyse unumgänglich, denn SOC-eigene Risiken wachsen mit jeder weiteren Architekturstufe. Im Beitrag wurden besonders mit Blick auf automatische Reaktionen mögliche Risiken aufgezeigt und Beispiele präsentiert, wie sich diese reduzieren lassen. Dazu wurde der „Objektivitätsfaktor“ als Qualitätsgröße vorgestellt – und zwar als Idee für eine faktisch-sachliche Betrachtung von Technologie, Organisationen und Mitentscheidern. Der Faktor Objektivität ist besonders wichtig bei Vorhandensein großer fachlicher Abhängigkeiten und Herstellergläubigkeit, wie sie in der IT dank Spezialistenmangel und Outsourcing zunehmend vorkommt.

Insgesamt lassen sich folgende Kernempfehlungen zur Absicherung eines SOC zusammenfassen:

Detektion

  • Für Tests auch mal besonders lange und komplexe Meldungsinhalte erzeugen, um den möglichen Impakt zu ermitteln, zum Beispiel durch Zeilenumbrüche oder Textverluste.
  • Überwachte Systeme gezielt stressen, um die Auswirkungen von schlechter Performance, Plattenplatzmangel oder ähnlichen Beeinträchtigungen auf das Monitoring zu prüfen.
  • Filter und Korrelationen von objektiven Spezialisten testen lassen – also von solchen Personen, die aus praktischer Erfahrung und operativer Verantwortung wissen, was alles passieren kann, aber die Detektionen nicht konzipiert haben.
  • Prüfen, ob und in welchen gutartigen Fällen ähnliche oder dieselben Sachverhalte auftreten, um eine Meldung, Alarmierung oder gar automatische Reaktion zu unterbinden.
  • Meldungsbasierte Detektionen gegen gefälschte Events absichern. Prüfen, wie sich solche Events erkennen lassen, zum Beispiel setzen manche Betriebssysteme spezielle Kontrollzeichen vor eine Meldung, wenn diese nicht vom privilegierten Systemkern ausgegeben wurden. Die Meldungsfilter sollten das beachten und einen „Match“ umgehen, unter Abgabe eines „possible fake event“-Alerts.

Reaktionen

  • Einen Test- oder Warn-Modus vorsehen, in dem Reaktionen noch nicht faktisch erfolgen, sondern – wie ein Alert – nur gemeldet werden.
  • Im Test-System beginnen, dann Entwicklung und schließlich Produktion; bei jedem Übergang ist wieder neu im Test-Modus zu beginnen. Auftakt mit semi-automatischen Reaktionen, das heißt die finale Entscheidung liegt noch beim SOC-Team.
  • Im Fall vollautomatischer Reaktionen ist Perfektion Voraussetzung. Somit sollten die Filter auch erkennen, dass ihre Entscheidungsgrundlage suboptimal war und nur melden statt zu reagieren.
  • Generell sind vollautomatische Reaktionen auf ihr „Fukushima-Potenzial“ hin zu überprüfen und entsprechende Limitierungen einzubauen, zum Beispiel eine maximale Anzahl stoppbarer Systeme oder Benutzer, um rekursive (Endlos-)Loops zu verhindern.

Planung, Auswahl und Organisation

  • Das SOC-Handbuch ist Dreh- und Angelpunkt für ein erfolgreiches SOC und damit ein wichtiges Investment. Es erlöst insbesondere die Spezialisten vor unnötigen Nachteinsätzen.
  • Wissen über SOC-Details sind streng geheim zu halten, auch vor einem Plattform-Dienstleister.
  • Vertraulichkeitsvereinbarungen mit allen involvierten externen Parteien sind obligatorisch und immer mit Vertragsstrafen zu kombinieren.
  • Stets nachhaltig objektivieren und zu hohe externe Abhängigkeiten vermeiden.
  • Gedankengut analog des Service-Level-Agreements eines Dienstleisters auch auf das SOC anwenden.

Dr. Stephen Fedtke ist Spezialist für die Risikoanalyse und Absicherung kritischer und systemischer IT-Infrastrukturen. Kontakt: stfedtke@enterprise-it-security.com

Einige der dargestellten Szenarien wurden erfolgreich durchgeführt. Für weitere Details können sich Leser direkt an den Autor wenden.

Literatur

[1] Jürgen Schreier, KI allein schafft noch keine perfekte Cybersicherheit, Industry of Things, August 2018, www.industry-of-things.de/ki-allein-schafft-noch-keine-perfekte-cybersicherheit-a-745105/ [2] Oliver Rochford, Security Automation is About Trust, Not Technology, Security Week, Juli 2017, www.securityweek.com/security-automation-about-trust-nottechnology [3] Stephen Fedtke, Epische Macht, „Extremely Privileged IT Staff“ (EPIS) erfordert spezielle Zuverlässigkeits- oder Sicherheitsüberprüfungen, <kes> 2010#6, S. 6 (Zugriff nur für Abonnenten) [4] Wirtschaftspsychologische Gesellschaft, Objektivität als Gütekriterium, In: Forschungsergebnisse interpretieren, https://wpgs.de/fachtexte/ergebnisinterpretation/objektivitaet-als-guetekriterium/ [5] Dr. P. K. Suri, Neeraj Garg, Software Reuse Metrics: Measuring Component Independence and its applicability in Software Reuse, Mai 2009, https://pdfs.semanticscholar.org/3d44/60e875e3abbd88fe6468f406c4b8b4a97b1c.pdf [6] BSI, IT-Grundschutz-Kataloge, 15. Ergänzungslieferung, 2016, https://download.gsb.bund.de/BSI/ITGSK/IT-Grundschutz-Kataloge_2016_EL15_DE.pdf [7] PricewaterhouseCoopers GmbH, Internationale Bedrohung durch Cyberangriffe nimmt zu, Neue Hackermethoden erfordern flexibel agierende Security Operation Center (SOC), Oktober 2018, www.pwc.de/de/finanzdienstleistungen/digital/regelmaessige-soc-sicherheitschecks-gegen-cyberattacken.html [8] Bundeskartellamt, Fallbericht: Bundeskartellamt prüft Auswirkungen eines geplanten Vermögenserwerbs der IBM an T-Systems auf den Mainframe-Infrastruktur-Outsourcing-Markt, Juni 2019, www.bundeskartellamt.de/SharedDocs/Meldung/DE/AktuelleMeldungen/2019/19_06_2019_IBM_T_Systems.html [9] IBM, Mark Nelson, RACF for z/OS V2.4 Update, Mai 2019, https://cutt.ly/AwWuaXb [10] Stuart Henderson, How To Break Into z/OS Systems, Oktober 2013, www.stuhenderson.com/XBRKZTXT.PDF [11] Stephen Fedtke, Datenleck Dumps – Speicherauszüge und Protokolldateien als Geheimnisverräter, <kes> 2014#3, S. 26 (Zugriff nur für Abonennten)

Diesen Beitrag teilen:

Lesen Sie weiter

Diese Beiträge könnten Sie ebenfalls interessieren.