Mit <kes>+ lesen

KI braucht Zuwendung : Über die Arbeit mit regelbasierter und anomaliegestützter Bedrohungserkennung

Die Erwartungshaltung ist klar: Künstliche Intelligenz (KI) soll in der Informationssicherheit teure Analystenteams entlasten und so Personalkosten sparen. Anbieter versprechen und Kunden erwarten, dass die programmierten „Hacker-Jäger“ ihre Arbeit weitgehend selbsttätig tun. Uneins ist man sich allerdings darüber, ob regelbasierte oder anomaliegestützte Systeme insgesamt weniger Wartung benötigen. Die Antwort liegt dabei weniger in den beiden technischen Modellen als in der Charakteristik des Einsatzumfelds begründet.

Lesezeit 11 Min.

Von Bettina Weßelmann und Johannes Wiele, München

Diskussionen scheinen unvermeidlich, wenn es um die Auswahl von KI-Werkzeugen für Security-Operations-Center (SOC) geht: Schnell bricht Streit aus über die Vorzüge der bekanntesten Basistechniken – Anomalieerkennung und regelgestützte Detektion. Von Ersterer erwarten ihre Befürworter, dass sie ohne stetiges Füttern mit Use-Cases, Regeln und anderen Zuwendungen auskommt – „Aber dann hast du Fehlalarme ohne Ende“, wirft kurz darauf der erste Kontrahent ein, „Wer soll sich denn damit dauernd herumschlagen?“ – „Und du hast natürlich ein tolles Team, das maßgeschneiderte Regeln ausgerechnet für unser Haus entwickeln kann“, lautet dann eine gern gewählte Replik, um den Einsatz regelbasierter Systeme abzuwenden: „Du glaubst doch nicht, dass da irgendwas von der Stange weiterhilft?!“

Dummerweise sind beide Positionen gerechtfertigt: Anomalieerkennung arbeitet nach dem Prinzip, erst das „normale“ Geschehen im Netz einer Organisation für eine Weile zu beobachten und nach einem gegebenen Erfassungszeitraum immer dann Alarm zu schlagen, wenn etwas „nie Dagewesenes“ geschieht oder etwas Bekanntes gewisse Schwellenwerte überschreitet. Fehlalarme – die gefürchteten „False Positives“ – produziert diese Technik immer dann, wenn etwas Ungewohntes nicht bösartig ist, sondern beispielsweise auf einem zuvor nicht registrierten Arbeitsprozess beruht.

Regelbasierte Erkennung sucht wiederum nach zuvor von den Sicherheitsteams festgelegten Aktionsmustern im Netz. Sie erhält beispielsweise die Information, dass eine gewisse Zahl fehlgeschlagener Anmeldeversuche an einem bestimmten Datenbanktyp zusammen mit zuvor registrierten Konfigurationszugriffen an Firewalls oder Routern auf eine bereits bekannte Angriffstechnik hindeuten, die auf den Diebstahl von Daten hinausläuft. Dieses Modell funktioniert aber nur dann perfekt, wenn die konkrete Regel zum abstrakten Erkennungswunsch (dem Use-Case) gut genug dem jeweiligen Einsatzszenario angepasst wurde – und wenn das mit der Erkennung betraute System über hinreichende Informationen zur überwachten Umgebung verfügt.

Worin genau in beiden Fällen der Tuning-Bedarf besteht, soll später noch aufgelistet werden. Sichtbar wird aber wahrscheinlich schon hier, dass es eine wartungsfreie künstliche Intelligenz, die den Sicherheitsteams vom ersten Arbeitstag an erfolgreich zur Seite steht, einfach nicht gibt. Für KI gilt hier dasselbe wie für menschliche Intelligenz: Ohne Training, Zuwendung und Pflege verkümmert die teure Technik. Welcher der beiden Ansätze im jeweiligen Einsatz weniger Aufmerksamkeit erfordert und damit weniger Arbeit macht, hängt nicht so sehr vom Funktionsprinzip ab, sondern vielmehr vom Charakter der jeweiligen IT-Umgebung und davon, welche Fachkenntnisse im Haus des Anwenders in Gestalt von Mitarbeitern versammelt sind.

Kreative oder Gewohnheitstiere?

Einen ersten, relativ leicht nachvollziehbaren Hinweis darauf, mit welcher Technik für die Angriffsdetektion ein Unternehmen vermutlich besser fährt, birgt der Begriff „Anomalie“: Etwas, das nicht normal ist, muss sich gegenüber dem Normalen hinreichend abheben, um aufzufallen. Anomalie-Erkennung registriert Phänomene wie die Datenbewegungen in einem Netz in Bezug auf Menge und Häufigkeit, hält fest, wer gewöhnlich auf was zugreift, von wo aus und wann das geschieht, merkt sich Wartungs- und Backup-Zyklen und vieles mehr. Nach einem zuvor definierten Beobachtungszeitraum geht man davon aus, dass das System alles, was im Netz legitimerweise geschieht, einmal gesehen hat und dass es die Schwellenwerte etwa für zu transferierende Datenmengen kennt. Dann wird das Werkzeug „scharf geschaltet“ und darf Alarm schlagen, wenn irgendein Vorgang auftaucht, der den als „normal“ definierten Handlungsrahmen sprengt.

Dass bei dieser Funktionsweise hin und wieder Fehlalarme auftauchen müssen, ist klar, denn kein Unternehmen kommt monatelang ausschließlich mit bereits beobachteten Kommunikationsvorgängen im Netz aus. In einer kreativen, dynamischen Organisation mit hoher IT-Affinität, die vielleicht stetig wächst und dann wieder schrumpft, immer neue Geschäftsmodelle ausprobiert und ihren Mitarbeitern viele Freiheiten lässt, werden ungewöhnliche Vorgänge allerdings deutlich häufiger auftreten als in einer Organisation mit einer eher überschaubaren Bandbreite IT-gestützter Tätigkeiten oder in einem Netz einer gleichmäßig arbeitenden Produktionsanlage. Die Vielzahl von False Positives lässt sich in einem dynamischen Umfeld aber auch nicht beliebig begrenzen, indem man die Lernphase der Anomalieerkennung erweitert, denn irgendwann hat die Technik dann so viele Aktionen als normal erfasst, dass ihr auch tatsächliche Angriffsaktivitäten entgehen.

Bei kreativ oder flexibel genutzter IT ist es besser, die regelgestützte Alternative zu wählen: Man überlegt sich gut, wo die „Kronjuwelen“ des Hauses liegen und was genau ein Angreifer tun würde, wenn er sich an sie herantasten wollte. Als Ergebnis hält man Use-Cases fest, die nichts anderes sind als abstrakte Beschreibungen dessen, was man in der eigenen Umgebung als verdächtig einschätzt – und schreibt dazu technische Regeln für ein regelgestütztes Detektionssystem. Diese Regeln halten die Einzelphänomene fest, mit denen zu rechnen ist, wenn ein Angreifer voranschreitet.

Voraussetzung hierfür ist,

  • dass zuvor ein Risiko-Assessment stattgefunden hat, bei dem sich die wirklich kritischen Informationen und Systeme herauskristallisiert haben,
  • dass diese Systeme und Informationsbestände in einem für Menschen und Maschinen gleichermaßen lesbaren Repository erfasst wurden (CMDB, Asset-Datenbank) und
  • dass man die Übung, über Angriffsformen und Risiken nachzudenken, regelmäßig wiederholt.

Es gibt viele Organisationen, die sich mit genau diesen – durchaus aufwendigen und teuren – Maßnahmen extrem schwertun. Gehören sie überdies zur Kategorie der Häuser mit überschaubarem Tätigkeitsspektrum im Netz, sind sie mit der Anomalieerkennung besser bedient. Die Wirksamkeit beider Ansätze hängt zusätzlich davon ab, dass sie Zugriff auf alle Informationsquellen (Logs, Netzwerkgeräte) haben, an denen Indikatoren für Angriffsschritte auftreten können.

Ein wenig verhält es sich mit der anomalie- und der regelgestützten Angriffserkennung wie mit des Menschen liebsten Haustieren Katze und Hund: Katzen lernen selbst, aber nicht unbedingt primär das, was der Mensch ihnen beibringen will. Sie können durch pure Beobachtung herausfinden, wie man eine Tür öffnet, und passen ihre Kommunikationsmethoden einzelnen Menschen an. Wo Mäuse sind, muss man ihnen ebenfalls nicht erst zeigen. Einer Katze Unarten abzugewöhnen, ist andererseits zwar möglich, aber schwierig.

Außerdem gibt es aus gutem Grund keine Blindenkatzen, Drogenspürkatzen, Jagdkatzen oder Wachkatzen. Das Ausführen zielgerichteter „Arbeitsaufträge“ ist Hundedomäne: Hunde lassen sich tendenziell viel leichter zu dem ausbilden, was man von ihnen verlangt. Aber das dazu nötige Training muss man dann auch tatsächlich konsequent leisten und fortführen.

Aufwandsvergleich

Die folgenden Abschnitte versuchen einen qualitativen und in Ansätzen quantitativen Aufwandsvergleich für die Pflege von anomaliegestützten Systemen einerseits und regelbasierten Securitysystemen andererseits. Dem Autorenteam ist dabei bewusst, dass es Werkzeuge oder Werkzeugkombinationen gibt, die beide Funktionsprinzipien in sich vereinen, und dass Hersteller mit neuen KI-Algorithmen bestimmten Nachteilen der Basistechniken entgegenwirken. Dennoch lohnt es sich aber für den Anwender, den Nutzen beider Detektionsverfahren für sein Unternehmen gegeneinander abzuwägen und gezielt auszuwählen, welche Funktionen an welcher Stelle besser passen.

Füttern mit Lernstoff

Anomaliegestützt

Der Lernaufwand bei Anomalieerkennungen scheint auf den ersten Blick überschaubar: Das System muss ja nur, wie bereits erwähnt, eine Weile dem Normalbetrieb zuschauen und nach der Scharfschaltung darauf reagieren, wenn etwas anders läuft als gewohnt. Wer allerdings tatsächlich so vorgeht, riskiert für eine geraume Zeit ein erhöhtes Aufkommen an Fehlalarmen.

Es lohnt sich also, ein wenig Vorarbeit zu leisten:

  • Wie lang soll die Lernphase sein? Je länger sie dauert, desto mehr (auch ungewöhnliche) Erscheinungen erfasst das System. Es ist jedoch schwierig, sicherzustellen, dass darunter keine Fälle von Angriffsverhalten sind, die dann ebenfalls als „normal“ registriert werden. Sicherheitsteams müssen deshalb in der Lernphase einer Anomalieerkennung sehr genau selbst aufs Netzgeschehen blicken und durch Finetuning fehlerhafte Einschätzungen beheben. Das konkrete Werkzeug sollte diese Phase durch anschauliche Informationsdarstellung unterstützen.
  • Sinnvoll ist es auch, bewusst darauf zu achten, dass periodisch, aber eher selten wiederkehrende Aktionen wie extrem große Datentransfers entweder mit in die Lernphase einfließen oder bewusst ausgeschlossen werden, wenn sie einem Angriffsverhalten zu sehr ähneln. In diesem Fall ist es angebracht, sie in einem Betriebshandbuch oder Runbook explizit zu erwähnen – damit sie später, wenn sie als „Anomalie“ auftauchen, durch das Monitoring-Team schnell abgehakt werden können. Diese Vorkehrung bedingt allerdings eine intensive Auseinandersetzung mit Angriffsszenarien. Generell gilt es außerdem, sich genau zu überlegen, wie mit einem unerwartet hohen False-Positives-Aufkommen nach der Scharfschaltung umzugehen ist. Der Hersteller des Tools sollte dann in der Lage sein, bei der Eindämmung der Fehlalarm-Flut zu helfen.

Regelbasiert

Beim regelbasierten Ansatz ist zunächst genau festzulegen, was erkannt werden soll und was nicht. Dazu definiert man gewöhnlich zuerst, welche Systeme überhaupt beobachtet werden sollen und für welche sich dieser Aufwand nicht lohnt (Risiko-Assessment). Aber Vorsicht: Auch ein unwichtig erscheinendes System gehört dann ins Blickfeld des Monitoringtools, wenn es ein mögliches Sprungbrett zu bedeutsameren Assets darstellt. Das „Scoping“ erfordert also Liebe zum Detail und damit Zeit und Mühe.

Hat man die Use-Cases identifiziert, muss man sie in technische Regeln fürs konkrete System gießen. Teilweise ist dazu individuelle Entwicklungsarbeit notwendig, was entsprechendes Fachpersonal oder Services des Herstellers erfordert –
teilweise lassen sich vom Hersteller des gewählten Werkzeugs zur Verfügung gestellte Standard-Use-Cases und Regeln mehr oder weniger leicht anpassen.

Hinzu kommt, dass nahezu jeder Anbieter über seine Security-Intelligence-Feeds regelmäßige Updates mit neuen Erkennungsregeln liefert, die irgendwo in der Welt bereits aufgetretene Angriffstaktiken aufgreifen. Hier müssen Security-Teams darauf achten, nur diejenigen Regelupdates zu abonnieren, die fürs eigene Unternehmen überhaupt wichtig sind, und daran denken, dass die Updates auch gesichtet und eingepasst werden müssen, um keine False Positives zu generieren. Vieles davon lässt sich als Managed Service buchen, kostet damit aber auch Geld. Und: Hier die richtigen Entscheidungen zu treffen, ist ebenfalls ein Arbeitsprozess, der finanziell und durch die Belastung der Mitarbeiter zu Buche schlägt.

Arbeitsfeld definieren/ eingrenzen

Anomaliegestützt

Für viele engagierte Security-Teams ist es eine durchaus bittere Erkenntnis, dass ihre pure personelle Leistungsfähigkeit und Teamgröße den Schutz limitiert, den sie ihren Organisationen bieten könnten. Es nützt nichts, perspektivisch alle Anomalien in allen Winkeln der IT-Umgebung in den Monitoring-Scope aufzunehmen, wenn dann nur ein Bruchteil der Erkenntnisse tatsächlich gesichtet werden kann – von genauer Analyse ganz zu schweigen. Scope-Justierungen in Bezug auf die beobachteten Systeme und Schwellenwerte sind also ebenfalls ein Teil der Pflegearbeit, die eine Anomalieerkennung benötigt. Dabei liegt die größte Herausforderung darin, so vorzugehen, dass wichtige Vorkommnisse mit hoher Wahrscheinlichkeit noch erkannt werden. Deshalb kommt auch ein SOC-Team, das eine Anomalieerkennung als zentrales Detektionswerkzeug nutzt, zuweilen nicht umhin, Risikoüberlegungen anzustellen und über mögliche Angriffswege nachzudenken – sofern es nicht einfach akzeptieren will, dass pro Zeiteinheit eine gewisse Zahl von Meldungen schlicht „unter den Tisch fällt“.

Regelbasiert

Wer auf regelbasierte Systeme setzt, muss an gleich mehreren Stellschrauben drehen, um sein Werkzeug auf eine zum Unternehmen passende Erkennungsleistung einzustellen: geschickte Auswahl der Log- oder Security-Sensor-Quellen, sinnvolle Auswahl der Use-Cases, Bestimmung von Schwellenwerten für die Alarmauslösung. Die kosten- und arbeitsträchtigsten Faktoren sind hier wiederum die zugrunde liegenden Risikoerhebungen und die Umsetzung der Ergebnisse in Steuerdaten fürs System. Auch hier ist der Arbeitsaufwand für die Pflege beträchtlich und muss von Beginn an nach Erfahrungswerten des Herstellers oder anderer Anwender eingeplant werden.

Kontext vermitteln

Gleich, welchen grundsätzlichen Ansatz zur Bedrohungserkennung man wählt: Die Systeme und die damit arbeitenden Menschen brauchen Kontextinformationen zu den überwachten Assets im Netz (vgl. [1]). Entdeckt ein Sicherheitswerkzeug entweder eine Anomalie oder eine per Regel definierte verdächtige Aktion an einem Server X, muss unverzüglich erkennbar sein, welcher Risikoeinschätzung dieser Server unterliegt und welche Art von Informationen er beherbergt – etwa Geschäftsgeheimnisse oder personenbezogene Daten. Das Ergebnis entscheidet über die Priorität der Response. Gute Tools können die Priorisierung bis zu einem gewissen Grad schon selbst vornehmen, in anderen Fällen übernimmt der Analyst an der Konsole diesen Part. Die fraglichen Informationen sollten in einer Configuration-Management-Database (CMDB) oder einem vergleichbaren Repository zur Verfügung stehen, sonst sind die Entscheider hilflos. Will ein Unternehmen Use-Cases implementieren, die sich auf bestimmte Datentypen richten (etwa, indem es Regeln entwickelt oder zukauft, die typische Angriffe auf personenbezogene Daten abbilden), scheitert bereits die pure Erkennung, wenn die entsprechenden Kontextinformationen zu den eigenen Assets gar nicht vorliegen. Damit gehört eine gut bestückte CMDB zu den wichtigsten Voraussetzungen für einen effektiven KI-Einsatz, der tatsächlich Fachkräfte entlastet.

Incident-Management

Wer den Aufwand für den KI-Einsatz im Security-Umfeld einschätzen will, sollte neben den direkten Pflegearbeiten an seinen KI-Tools auch die Nachbearbeitung der Ergebnisse im Blick haben. Incident-Management etwa muss immer betrieben werden: Für dringende Fälle wie laufende Angriffe muss ein Computer-Emergency-Response-Team (CERT) bereitstehen – weniger akute Vorfälle müssen zumindest fürs Finetuning der Sicherheitswerkzeuge und zur Schärfung der jeweils aktuellen Risikobewertungen herangezogen werden. Wenn nicht für jede dieser Tätigkeiten spezielle Teams aufgebaut werden können, muss das Gesamt-Team zumindest groß genug und hinreichend gut ausgebildet sein, um die unterschiedlichen Tätigkeiten ausführen zu können. Dabei gilt: Je spezieller eine IT-Umgebung ist, desto weniger können eine KI selbst oder ein dazu gebuchter Managed Service die Response, also die Gegenwehr, übernehmen. Maßnahmen wie Isolierungen von Servern oder Systemabschaltungen, die keine Rücksicht auf den Einsatzzweck von IT-Systemen nehmen, richten nämlich schnell größeren Schaden an als das Angriffsgeschehen selbst. Die Planung von Arbeitsabläufen und die beschriebenen Teamdefinitionen sind somit ebenfalls Faktoren, die sich in Arbeitsbelastung und Kosten niederschlagen.

Fazit

Die KI braucht den Menschen genauso wie der Mensch die KI. „Die beste“ KI-Lösung für alle Typen von Organisationen gibt es zudem nicht: Mal passt der anomaliegestützte Ansatz besser, mal ist es der regelbasierte. Welches Modell im konkreten Fall pflegeleichter ist, lässt sich nur durch eine Vorab-Analyse der Arbeitsszenarien am Einsatzort klären. Geht es allein um die Leistung und nicht ums Budget, ist eine Kombination beider Ansätze sinnvoll.

Bettina Weßelmann (bettina@wesselmann.com) ist Beraterin für Unternehmenskommunikation und Fachautorin mit dem Spezialgebiet Informationssicherheit. Dr. Johannes Wiele (johannes@wiele.com) ist freier Autor sowie GDD-geprüfter Datenschutzbeauftragter und arbeitet als Senior-Manager in der Cybersecurity-Beratung.

Literatur

[1] Bettina Weßelmann, Johannes Wiele, Haie fischt man nicht im Trüben, Grüße von der langen Bank – Dauerbaustellen der Security (2), <kes> 2016#4, S. 26

Diesen Beitrag teilen: