Canarys & Co. : Von Theorie und Philosophie zur Praxis – wie man Unentscheidbarkeit zugunsten der Verteidigung einsetzen kann

Fiese Folgen

Und spätestens jetzt sind wir in der Praxis der heutigen Informatik angelangt: Denn so harmlos sich das Halteproblem auf den ersten Blick anhört, so einschneidend ist es für die Computerindustrie und vor allem für Software-Entwickler. Stellt man sich vor, es hätte weder Gödel noch Turing gegeben und erst recht kein Halteproblem: Dann würden heute alle frisch entwickelten Programme in eine Maschine – nennen wir sie der Einfachheit halber „Scotty“ – gefüttert, welche die neue Software mithilfe eines cleveren Algorithmus daraufhin untersucht, ob sie jemals „anhält“, also zu einem Abschluss/Ergebnis (Programmende) gelangt.

Manche Software-Entwickler würden jetzt wohl entgegnen, dass sie sich überhaupt nicht dafür interessierten, ob ihr Programm „anhält“, denn das solle es ohnehin niemals tun – es wäre gar nicht gebaut dafür, immerhin sei es ja eine Web-Anwendung. Der Konter hierzu ist das fiktive Hilfsprogramm „Warp-9“, das genau dann anhält, wenn die zu prüfende Web-Anwendung korrekt arbeitet, sonst aber nicht. Gödel hat gezeigt, dass es „Warp-9“ nicht geben kann – und Turing hat bewiesen, dass „Scotty“ leider immer Fiktion bleiben wird.

Die Unmöglichkeit eines universellen Prüfprogramms ist jammerschade für die Qualität und Zuverlässigkeit unserer IT-Landschaften –schließlich hätte es viel Frust, Patch-Aufwand und viele Abstürze (auch von physischen Dingen wie Ariane-5-Raketen) vermeiden können.

Unentscheidbarkeit und Security

Wie sich das für eine universelle Grenze gehört, gilt diese naturgemäß auch in jedem Teilbereich ihrer Wissenschaft – und im Rest dieses Artikels ist damit die IT-Sicherheit gemeint. Auch wenn Gödel und Turing mit „Security“ nichts am Hut hatten, gelten Unvollständigkeit und Halteproblem beziehungsweise das Prinzip der Unentscheidbarkeit auch für alle Systeme der IT-Security. Und hier gibt es jede Menge bedeutsame Anwendungsfälle: Keine Firewall kann zwischen „permit“ und „deny“ automatisch und immer richtig entscheiden, kein Antivirenprogramm blockiert jede Malware korrekt als bösartig und lässt jede gutartige Datei anstandslos passieren – und auch URL-Scanner werden niemals fehlerfrei arbeiten können. Es bleibt zwangsläufig beim bekannten „Haseund-Igel-Rennen“ zwischen Angriff und Verteidigung.

Wer Gödel und Turing verstanden hat, glaubt keinem „IT-Security“-Hersteller aus dem „Snakeoil“-Konzern, der ihm die ultimative Lösung „Scotty“ und das Erweiterungsmodul „Warp-9“ dazu andrehen will! Denn er weiß, dass diese gar nicht funktionieren können und das viele Geld niemals wert sein werden.

Letztlich halten Turing und Gödel – vermutlich ohne es zu wollen und sicher ohne es geahnt zu haben – zwei ganze Industriezweige in Lohn und Brot: die IT-Security- Hersteller auf der „guten Seite der Macht“ und natürlich auch die „Black Hats“ und Cyberkriminellen, die mittlerweile hochindustrialisiert von neun bis fünf Uhr einem festen Beruf mit (nahezu) festem Einkommen nachgehen – dass sich hieran nichts grundlegendes ändern wird, mag der Autor heute ohne Risiko prophezeien und nimmt jede entsprechende Wette siegesgewiss an.

Kleiner Seitenhieb auf die künstliche Intelligenz (KI): Solange Large Language-Models (LLMs) wie das bekannte und gehypte ChatGPT auch nur auf ganz gewöhnlichen Servern laufen, sind sie grundsätzlich nicht mächtiger als Turingmaschinen. Das bedeutet aber auch, dass selbst in einer Zukunft, wo fortgeschrittene Chat-Bots beim sogenannten „Turingtest“ – wo Maschinen einem Menschen gegenüber einen Menschen vortäuschen – irgendwann nicht mehr versagen dürften, trotzdem kein solcher Bot jemals in der Lage sein wird, beispielsweise jede (!) Zero-Day-Malware sicher (!) von einem seriösen Computerprogramm zu unterscheiden.

Gut und Böse

Wenn schon Maschinen nicht eindeutig zwischen „Gut“ und „Böse“ unterscheiden können, sind dann wenigstens Menschen mit ihrer höheren Intelligenz dazu in der Lage? Auch diese Frage lässt sich nur in Einzelfällen objektiv beantworten: Denn sobald es beispielsweise politisch wird, liegt die Einschätzung meistens im Auge des Betrachters – ein Autokrat wird etwas Anderes als „gut“ empfinden als ein Demokrat. Oder nehmen wir die Hackergruppe „Lazarus Group“, die wohl im Auftrag der Regierung Nordkoreas versucht, Rüstungsunternehmen des Westens auszuspionieren: Aus dem Blickwinkel Kim Jong- Uns betrachtet, leisten deren Mitglieder eine gute Arbeit – die betroffenen Unternehmen sehen das sicherlich anders.

Überträgt man diesen „ethischen Score“ auf Software (die aus den eben genannten Gründen nicht „Malware“ heißen sollte), so dürfte die Einschätzung einer Analysesoftware (Firewall, Antivirenprogramm etc.) in erster Linie davon abhängen, wer diese konfiguriert hat, wessen ethische Standards oder Absichten also hinter der Grundkonfiguration stecken.

Programmcode kann per se weder „gut“ noch „böse“ sein und auch die Einschätzung durch eine Maschine oder einen Bot dazu kann richtig, falsch oder sogar undefiniert sein. Die hiermit verbundene Entscheidungsfindung hängt von sehr vielen Parametern ab: von den Eigenschaften und der Güte der Analysesoftware, von ihrer Konfiguration, aber natürlich auch vom untersuchten Muster, das nicht zuletzt ein Programmcode sein kann, vor dem selbst eine hochkomplexe und mehr oder minder universell einsetzbare Sandbox (auch eine Art Turingmaschine) im Zweifel kapitulieren wird. In der Praxis wird ein Sicherheitssystem naturgemäß nicht kundtun „ich weiß nicht, ob das Muster gut oder böse ist“, sondern mit einem Score antworten.

Es hat sich dabei eingebürgert, dass ein Score von 100 so viel bedeutet wie „ich bin sicher, dass das Muster böse ist“ und demgegenüber ein Score von 0 die feste Überzeugung darstellt, das Muster sei gutartig. Bei allen übrigen Zahlenwerten bleibt aber ein Rest an Unsicherheit – eine Datei mit Score 99 könnte also trotz aller Anzeichen harmlos sein und ein Score von 10 bietet keinerlei Gewähr, dass man nicht trotzdem einem Zero-Day-Angriff aufsitzen könnte, wenn man das untersuchte Programm tatsächlich auf einem produktiven Rechner startet. Die Fachwelt spricht bei diesen Irrtümern von False Negative oder False Positive, was den Makel einer glatten Fehlentscheidung etwas kaschiert.

Wahrscheinlichkeit statt (Un-)Entscheidbarkeit

Diese Situation ist prinzipiell unvermeidlich und tritt in der IT-Security viel öfter auf als in anderen IT-Bereichen – und viel öfter als uns lieb sein kann. Dagegen ist im Grunde auch nichts einzuwenden außer der Beobachtung, dass einige Hersteller weder eine Begründung für diese Unsicherheit liefern noch ihre Kunden darüber aufklären, mit welcher Genauigkeit ihre Lösungen Scores abschätzen. Das bedeutet für die Käufer vieler solcher „Sicherheitslösungen“ (!) im Gegenzug aber auch, dass sie eigentlich „Unsicherheitslösungen“ kaufen: Wegen der fehlenden finalen Entscheidbarkeit zwischen Gut und Böse müssen sie sich mit einer nicht zu vernachlässigenden Restwahrscheinlichkeit abfinden, die Konsequenzen dieser Unsicherheit – trotz teilweise erheblichen finanziellen Aufwands für die „Lösungen“ – letztlich doch selbst tragen zu müssen.

Sweet Spot und der Impact

Es gibt genügend Anwendungsfälle, in denen die Konfiguration einer Sicherheitslösung darüber entscheidet, wo der „Sweet Spot“ zwischen False Positives und False Negatives liegt – wo man also durch die Wahl bestimmter Parameterwerte darauf Einfluss nehmen kann, ob es eher weniger False Positives auf Kosten von mehr False Negatives gibt oder genau umgekehrt. Wo wir selbst durch die bestmögliche Konfiguration ein Systems niemals so einstellen können, dass es keine Fehlentscheidungen liefert, sollten wir zumindest die bestmögliche Konfiguration dafür suchen, um die Auswirkungen von Fehlentscheidungen möglichst gering zu halten.

Auch hier sind viele Hersteller jedoch noch nicht so weit, dass sie den „Risk Appetite“ ihrer Kunden ganz selbstverständlich einfordern und verarbeiten können. Könnte man dem System einfach mitteilen „ein False Positive kostet uns x €, ein False Negative kostet uns y €“, würde das erheblich erleichtern, den Business-Impact der Lösung optimal zu justieren. Im Endeffekt bräuchte es dafür nicht einmal KI, sondern lediglich eine Art selbstoptimierendes System.

Interpretation: Permit oder Deny?

Dass ein (Risiko-) Score von 0 zu einem „Permit“, ein Score von 100 zu einem „Deny“ führt, erscheint relativ klar. Doch wie geht man mit allen Werten dazwischen um? Und bleibt eine derartige Interpretation dauerhaft gleich/gültig? Es könnte ja schließlich schon morgen eine Vulnerability bekannt werden, durch die genau dieses oder jenes betrachtete Netzwerkpaket bekanntermaßen zu einem Major Incident führen würde?

In manchen Situationen kann man Entscheidungen zeitlich aufschieben (Stichwort Quarantäne) – in allzu vielen anderen muss aber in Echtzeit gehandelt werden. Als Rettungsanker bleibt nur das Protokollieren einer möglicherweise übersehenen Kompromittierung für eine spätere Forensik.

Next-Generation-Firewalls oder andere moderne Techniken entscheiden natürlich oft nicht mehr nur auf der Grundlage eines einzigen Netzwerkpakets, sondern berücksichtigen eine ganze oder sogar viele Sitzungen oder E-Mails im Kontext. Die Qualität der Entscheidungen wird dadurch sicherlich steigen, ein Restrisiko bleibt aber.

Umkehr der Unentscheidbarkeit

Die Unentscheidbarkeit in der Informatik erweist sich also als eine Art Zaubertrank für Angreifer beziehungsweise Achillesferse der Verteidiger. Eine digitale Welt ohne Unentscheidbarkeit würde hingegen kein Phishing, keine APTs, keine Zero-Day-Angriffe et cetera kennen – denn für jede dieser Gemeinheiten hätte sich längst ein Hersteller gefunden, der sie technisch unfehlbar erkennen und abwehren könnte. Jeder hätte „Spam-Phishing- Abwehr-Scotty9“ auf seinem PC installiert und wäre die meisten seiner täglichen IT-Security-Sorgen los.

Nun hat IT-Security zwar nichts mit sportlicher Fairness zu tun, aber ein Grundgedanke aus dem Sport bietet sich in diesem Kontext dennoch an, nämlich „gleiche Regeln für alle“. Auf die IT-Security bezogen bedeutet das, die Unentscheidbarkeit von Informatik Problemen auch für die eigenen Zwecke einzusetzen, wo immer das möglich ist. Denn diese Grenze gilt ja generell auch für Angreifer: Auch diese können mit keinem noch so komplexen und ausgefeilten Programm entscheiden, was aus prinzipiellen Gründen einfach nicht entschieden werden kann.

Selbst Angreifer müssen immer damit rechnen, dass ihre „Reconnaissance“ nicht nur nützliche Erkenntnisse liefert, sondern bis zu einem gewissen Grad (mit einer Restwahrscheinlichkeit größer Null) auch Falschinformation umfasst, die sich von richtiger und wichtiger Information einfach nicht zuverlässig unterscheiden lässt.

Insofern ist die Wissenschaft Informatik und gerade die Logik durchaus fair beziehungsweise „gerecht“. Das Prinzip „Falschinformation“ beziehungsweise „Täuschung“ an sich ist auch schon ziemlich alt, nur wird es in der IT-Branche oft nicht als wertvoll erkannt und nur allzu selten aktiv eingesetzt – denn in der IT geht es bekanntermaßen in erster Linie darum, richtige Informationen zu liefern.

Honeypots

Der wohl populärste und allen Experten geläufige Ansatz, Angreifer mithilfe von Täuschung zu schlagen, ist ein sogenannter „Honeypot“ (bzw. gleich ein ganzes Honeynet). Die Verteidigung baut zu diesem Zweck ein komplettes System einzig und allein dafür auf, dass es angegriffen wird, und will den oder die Angreifer gezielt dabei beobachten, wie sie vorgehen. Richtig zu stehlen oder zu modifizieren (z. B. durch Ransomware) gibt es dabei nichts und selbst die Verfügbarkeit des Honeypots stellt kein Schutzziel dar – schließlich lässt er sich jederzeit auf Knopfdruck wieder komplett neu aufsetzen.

Die Zaubertrank-Eigenschaft der Unentscheidbarkeit wird hier bereits sichtbar, denn die Verteidiger können ihre Honeypots durch kleine Änderungen jederzeit mit relativ wenig Aufwand so verändern, dass es einem potenziellen Angreifer praktisch unmöglich ist, die Täuschung sofort zu erkennen.

Der Nachteil dieses Konzepts ist jedoch der immense Aufwand: Man braucht für jeden Angreifer ein komplett neues System oder Netzwerk mit anderen Eigenschaften oder gezielt eingebauten oder „naturbelassenen“ Schwächen sowie regelmäßige Pflege. Außerdem müssen die gewinnbaren Erkenntnisse auch gezielt eingesammelt werden: Worauf und in welcher Reihenfolge greift der typische Angreifer zu? Für welche Informationen interessiert er sich? Wie verschleiert er sein Eindringen oder bereitet er seine Rückkehr vor?

Das erste Werkzeug, das systematisch solche Daten erhob, war Tripwire, zu Deutsch „Stolperdraht“, ein hostbasiertes Intrusion-Detection-System (HIDS): Wie bei einem Einbrecher, der einen stillen Alarm auslöst, indem er unsichtbare Drähte zerreißt oder Infrarot Lichtschranke unterbricht, kann man auch auf einem IT-System sicher detektieren, wenn für den Betrieb wichtige Dateien modifiziert oder „schlafende Daten“ urplötzlich zum Lesen geöffnet werden, ohne dass dafür ein triftiger Grund vorläge. Tripwire half dabei, ein System so zu konfigurieren, dass man Angriff e erkennen und im Nachhinein wieder aus einem Backup bereinigen konnte.

Zusätzlich zur Überwachung verschiedener Zeitstempel des Dateisystems (mtime, atime, aber auch ctime) konnte man auch Hashwerte besonders wichtiger Dateien errechnen, die zwar separat gespeichert werden mussten, es einem Angreifer aber praktisch unmöglich machten, eine Datei so abzuändern, dass die neuen Hashwerte immer noch mit den Originalwerten übereinstimmten.

Das Wirkprinzip von Tripwire ist allerdings nicht die Unentscheidbarkeit (wenn man davon absieht, dass ein Einbrecher von außen nicht entscheiden kann, ob sein Zielobjekt mit „Stolperdrähten“ versehen ist), sondern die zuverlässige Erkennung und Alarmierung sowie das Gewinnen forensischer Erkenntnisse.

Canarys

Durch Kombination einiger Prinzipien von Honeypots und Tripwire zu einem neuen Konzept entstanden die sogenannten Canarys: Der Begriff kommt ursprünglich aus dem Bergbau und bezeichnete schlicht Kanarienvögel, die man nur deshalb mit in Bergwerke genommen hat, weil sie besonders sensibel (jedenfalls früher als Bergarbeiter) auf giftige Gase reagieren.

IT-Canarys sind Objekte, die nur dazu platziert werden, damit Angreifer nach ihnen greifen und dadurch einen stillen Alarm auslösen. Anders als Honeypots, die als komplexes System ja praktisch ausschließlich aus Canarys bestehen, hilft dem Verteidiger das Prinzip der Unentscheidbarkeit hier methodisch dabei, sein zu schützendes System immer noch hauptsächlich für den eigentlichen produktiven Zweck einsetzen zu können. Bildlich gesprochen genügt ein kleiner Kanarienvogelkäfig in jedem Stollen, um alle Bergarbeiter darin wirksam zu schützen: Ein Angreifer kann unmöglich zuverlässig entscheiden, welches der angetroffenen Objekte produktiv und welches nur ein Lockvogel ist, von dem er besser die Finger lassen sollte.

Die Grundidee von Tripwire muss anschließend nur noch auf alle Canarys angewendet werden: Eine besonders sorgfältige Überwachung aller Zugriffe genügt für diese Objekte, muss sich jedoch nicht auf die Mehrheit produktiv genutzter Daten und Zugänge erstrecken. Das vereinfacht die Konfiguration erheblich und spart Rechenleistung – etwa für die ständige Neuberechnung von Hashwerten nach legitimen Änderungen.

Canary-Dateien

Will man 99 Dateien auf einem Fileserver vor der Verschlüsselung durch Ransomware schützen und fügt zu diesem Zweck eine einzige Canary-Datei hinzu, für die jeder Zugriff einen stillen Alarm auslöst, dann muss ein Angreifer (zufällige Verteilung vorausgesetzt) auf alle Dateien zugreifen, damit die Alarmglocke sicher schrillt. Soll ein Alarm wahrscheinlicher sein, als das unerkannte Entkommen eines Angreifers, ist dessen Zugriff auf mindestens 50 Dateien erforderlich.

Beide Ergebnisse sind nur im Fall einer Ransomware zufriedenstellend, die letztlich alle zu schützenden Dateien inklusive aller Canary Dateien verschlüsseln will. Ist hingegen zu erwarten, dass ein Angreifer sein Tun schon nach 10 % der Dateien stoppt, muss man dafür sorgen, dass eine Canary-Datei zu diesen ersten 10 % gehört. Die Verteilung ist definitiv fast nie rein zufällig: Auch Ransomware möchte ihre Tätigkeit „schnell“ und erfolgreich durchführen und trifft die Auswahl der zu verschlüsselnden Dateien meist aufgrund folgender Kriterien: Dateiname, -größe, -typ (vermuteter Inhalt), Ort im Dateisystem (Betriebssystemdateien werden in der Regel ausgeklammert, damit das System weiterhin startet und die Erpresserbotschaft anzeigen kann) und manchmal auch bestimmte Kombinationen von Dateiattributen.

Es lohnt sich also, Köder gezielt so auszulegen, dass sie schon möglichst zu Beginn gefressen werden.

Canary-Konten

Noch Erfolg versprechender ist es, sogenannte Canary-Konten einzurichten: besondere Nutzerkonten auf allen produktiven Systemen, die zwar grundsätzlich eine Anmeldung auf dem betroffenen System erlauben, anschließend aber keine weiteren Aktionen mehr zulassen (bes. keine schädlichen wie den Diebstahl von Dateien, Lateral Movements oder den Upload von Malware) – außer vielleicht noch den Zugriff auf Köder, also Canary-Dateien.

Ein schöner Nebeneffekt dieser Verteidigungstechnik ist es, dass man durch die gezielte Vergabe des zugehörigen Kennworts recht brauchbar einstellen kann, welche Angriffstechnik provoziert werden soll: Credential- Stuffing, Wörterbuchangriffe oder (Reverse-) Brute-Force-Attacken – einen Sonderfall stellt die gezielte Abwehr von Datendiebstahl durch Insider dar (siehe unten).

Eigentlich sollte man jedes herstellermäßige Standard- Administratorkonto auf jedem System grundsätzlich zu einem Canary-Konto umbauen. Angreifer kennen schließlich solche Standard-Konten und testen sie mit sehr hoher Wahrscheinlichkeit bereits zu Beginn.

Canary-AD-Objekte

Fast jedes Auskundschaften (Reconnaissance) durch menschliche Angreifer beginnt mit dem Erfassen (Enumeration) aller Objekte aus dem Active Directory (AD) – zumindest sofern nicht ausschließlich Linux oder MacOS im Einsatz sind. Verteidiger sollten diese Neugier gezielt gegen Angreifer einsetzen und darauf wetten, dass diese sich zuerst einen Überblick über mögliche Ziele und Opfer verschaffen wollen. Diese Technik gehört heute in den Werkzeugkasten praktisch jedes ernst zu nehmenden ISMS.

Es gibt mittlerweile brauchbare kostenfreie Tools, um verschiedene Köder-Objekte in einem AD auszulegen oder auch regelmäßig an neue Angriffstechniken oder Situationen (siehe Abschnitt „Innentäter“) anzupassen. Solche Tools können teilweise sogar die Regeln gleich mit anlegen, die bei Zugriffen Alarm auslösen. Ausgereift erscheint beispielsweise AD-Canaries von AirbusProtect (https://github.com/AirbusProtect/AD-Canaries).

Unentscheidbar für Maschine und Mensch

Für eine Ransomware ist es quasi „per Naturgesetz“ unmöglich zu entscheiden, ob die nächste Datei, die sie verschlüsseln will, produktiv genutzte Daten enthält oder ein Canary ist. Und keine noch so perfekte Malware kann „von der Stange“ (also ohne korrekte und vollständige Vorabkonfiguration) sicher vermeiden, dass sich ihr nächstes Lateral Movement nicht ausgerechnet ein Canary-Konto oder -AD-Objekt vorknöpft und ihr verbotenes Treiben so innerhalb von Minuten (oder wenigstens Stunden) aufgedeckt wird.

Für Menschen existiert zwar kein Turingsches Halteproblem, aber – wie die Erfahrung zeigt – treffen menschliche Angreifer sogar eher häufiger Fehlentscheidungen als maschinelle Attacken (außer diese sind KI-gestützt und leiden unter Halluzinationen): „Offenbar gibt es etliche Benutzerkonten mit bekannten Namen auf diesem System. Gegen welches soll ich den ersten Credential- Stuffing-Angriff starten?“ oder „Anscheinend hat der Nutzer eine Datei namens ‚Kennwörter.txt‘ in seinem Home-Directory. Soll ich diese herunterladen und auf meinem PC öffnen?“ ist ohne Hintergrundwissen zum Opfersystem nicht „fehlerfrei“ zu entscheiden: Ergattert man einen Jackpot oder doch nur einen vergifteten Köder?

Empfehlungen

Jeder Verteidiger hat nur eine begrenzte Menge Energie zur Abwehr von Angriffen. Angriffstechniken gibt es leider sehr viele, Angriffswege noch viel mehr und es stellt sich immer die zentrale Frage, wo man seine (im Vergleich zur Masse aller Angreifer) wenige Energie am sinnvollsten einsetzen sollte.

Mehr Energie, Scotty!

Dem Autor drängt sich der Eindruck auf, dass gerade in der letzten Zeit, wo Quantität und Qualität der Angriffe immer mehr zunehmen, leider viel Budget, Arbeitszeit und allgemein Abwehrkräfte in Techniken angelegt und vergeudet werden, die schon allein aufgrund theoretischer Schranken nicht hinreichend viel Schutz bieten können – seien es Next-Generation-Firewalls, Network-Behavior-Anomaly-Detection, Extended Detection and Response (EDR) und so weiter. Diese sind zwar bis zu einem gewissen Punkt nützlich, durch die ständige Nachpflege und den enormen Anpassungsaufwand aber auch ressourcenintensiv.

Gerade für Anwendungen im kleinen Maßstab (bes. kleinere Organisationen mit beschränkten Budgets) erscheinen solche Verfahren nicht immer angemessen.

Best Practice für alle

Ein wichtiges Plädoyer im Umgang mit IT-Sicherheitsrisiken muss also sein, die kleinen, aber ungemein effektiven Dinge in der Abwehr nicht zu vernachlässigen und von Anfang an in jede Sicherheitsarchitektur einzubauen – und dazu gehören unbedingt auch Canarys.

Es sollte Best Practice jedes CISO oder IT-Sicherheitsverantwortlichen sein – und mehr noch für alle „Einzelkämpfer“, hinter denen keine schlagkräftige Organisation steht –, die in diesem Beitrag genannten Maßnahmen einzuführen. Direkte Kosten entstehen dadurch normalerweise keine (falls man nicht zu viele oder zu große Canary-Dateien anlegt oder zusätzlichen Lizenzen oder Tools zu deren Einrichtung benötigt).

Indirekt kommt möglicherweise einmaliger oder sogar regelmäßiger Aufwand für den Betrieb einer Alarmierungslösung hinzu (z. B. neue Use-Cases für das SIEM), doch sollten sich diese in einem überschaubaren Rahmen bewegen. Notwendige neue Regeln sind meistens recht knapp und präzise zu beschreiben und erfordern keine aufwendige Korrelation mit anderen Regeln.

Anomaly-Detection vs. Key-Risk-Indicator

Anomaly-Detection kann als ein teures und aufwendig zu pflegendes System mit einer hoffentlich hohen Wahrscheinlichkeit abnormales Nutzerverhalten erkennen und Alarm schlagen. Aber was genau ist „abnormal“? Was ist gerade noch innerhalb der Norm? Wo setzt man die Grenze optimal, um den Sweet Spot aus möglichst wenigen False Positives bei gleichzeitig möglichst wenigen False Negatives zu treffen?

Die Suche nach geeigneten Indicators of Compromise (IoC) und passenden Schwellwerten kann ziemlich aufwendig werden, es sei denn, man definiert ersteres gleich selbst und kann dadurch auf zweiteres komplett verzichten – kommt also zum Ziel, ohne auf die Produkte von Technologieanbietern oder die Dienste von Beratern angewiesen zu sein.

Auch die Messung eines passenden Key-Risk-Indicators (KRI) gestaltet sich durchaus einfach: Man zähle die Canary-Incidents und ziehe etwaige False Positives davon ab. Bleibt eine positive Zahl übrig, dann zeigt sich nicht nur ein Trend, sondern in der Regel sogar mindestens ein „Major Incident“, für das man sodann das passende (und hoffentlich rechtzeitig vorbereitete) Playbook zu Rate ziehen kann.

(Keine) Geheimsachen

Die Tatsache, dass eine Organisation Canarys einsetzt, mögen einige für vertraulich oder sogar streng vertraulich halten. Das ist sie aber nicht unbedingt: Angreifer sind sich dieses Risikos ohnehin bewusst (zumindest sollten sie es sein, falls sie ihr „Handwerk“ beherrschen), könnten dagegen aber als einzige wirklich effektive Gegenmaßnahme schlicht nur davon absehen, eine Organisation überhaupt anzugreifen – Ziel erreicht.

Akzeptiert ein Einbrecher aber das Risiko, erwischt zu werden, dann ist es für die Verteidigung lediglich sehr wichtig, dass der Alarm nicht mit lautem Getöse losgeht: Je weniger und später der Eindringling darüber erfährt, dass er bereits entdeckt wurde, desto mehr Zeit bleibt den Verteidigern, ihre Playbooks hervorzukramen, weitere Abwehrmaßnahmen zu ergreifen und die Forensik zu starten.

Was man hingegen grundsätzlich immer streng geheim behandeln und mit möglichst wenigen Personen teilen sollte, sind die strategischen Entscheidungen bezüglich der tatsächlichen Auswahl und Platzierung von Canarys. Käme diese Information in die falschen Hände, würde das diese spezifische Abwehrstrategie wertlos machen: Ein Einbrecher, der weiß, in welchen Räumen wo und wie Lichtschranken angebracht sind, kann diese eventuell geschickt umgehen. Das Risiko ertappt zu werden, steigt hingegen mit jedem unvorhergesehenen Canary.

Innentäter

Gegen versierte Insider ist fast kein Kraut gewachsen – das gilt leider auch für Canarys: Was bei externen Angreifern den Ausschlag gibt, nämlich die Unentscheidbarkeit oder das Unwissen über getroffene Abwehrmaßnahmen, versagt bei Innentätern leider allzu oft. Auch darum ist das Wissen über die Auswahl und Platzierung von Canary-Objekten mit möglichst wenigen Kollegen zu teilen.

Ist man aus technischen oder organisatorischen Gründen dazu gezwungen, könnte man zumindest dazu übergehen, mehrere getrennte Canary-Segmente aufzubauen und zu betreiben. Denn auch Innentäter sind Menschen und handeln fehlbar, indem sie etwa in eine zweite Falle tappen, um der ersten geschickt auszuweichen. Gerade anonyme Nutzerkonten werden gerne dazu missbraucht, um im Wissen um vorhandene Audit-Trails wertvolle Daten stehlen zu können – vermeintlich ohne dabei Spuren zu hinterlassen.

False Positives im SIEM

Auch für Canarys gibt es Sweet-Spot-Überlegungen: Der direkte Impact von False Negatives (ein Angreifer schluckt keinen einzigen der ausgelegten Köder) auf das Business ist zwar vordergründig gleich Null – denn es entstehen ja praktisch keine Kosten für die Köder und diese behindern die Geschäftstätigkeit auch nicht wirklich. Allerdings zeigen die Canarys dann auch keinen Nutzen.

Der Impact von False Positives – greift zum Beispiel ein legitimer Nutzer auf ein Canary zu oder der neue Werkstudent ist neugierig, was „diese komische Datei“ auf seinem Laptop bedeuten mag – ist im Zweifel sogar eher positiv als negativ zu bewerten: Natürlich geht hierdurch hin und wieder ein falscher Alarm los, man bekommt ein Ticket im Incident-Management und die CSIRT-Maschine läuft an und belegt Ressourcen.

Aus einer anderen Perspektive betrachtet weiß man nun allerdings, dass der Köder gut ausgelegt ist, dass Logging und SIEM prinzipiell korrekt konfiguriert und programmiert wurden und dass Incident-Management und CSIRT auf Zack sind. Der Werkstudent (oder wer auch immer) bekommt dann hoffentlich ein Sonderlob vom CISO, lernt etwas Nützliches über IT-Security und Awareness und wird gleichzeitig noch davon abgeschreckt, sich im Unternehmen irgendwann als Innentäter auszuprobieren.

Security-Organisationen sollten solche falschen Alarme immer dazu verwenden, um das Logging zu verfeinern, die Schwellenwerte in SIEM-Regeln zu verbessern oder neue Korrelationen zeitlich miteinander auftretender Ereignisse einzuführen. Das Ziel muss langfristig eine möglichst hohe Trennschärfe zwischen den Hypothesen „echter Angriff“ und „harmloser Zugriff“ sein, um die Effizienz von Canarys zu optimieren ohne gleichzeitig ihre Wirksamkeit zu beeinträchtigen.

Fazit

Canarys sind keine typische, neu anzuschaffende „Technologie“, sondern eher Prozesse beziehungsweise Policies zur frühzeitigen Erkennung von Gefahren und zur Reduzierung von Risiken. Sie eignen sich für Organisationen jeder Größenordnung – besonders effektiv sind sie aber bei jedem mit einem begrenzten Budget für IT-Sicherheit oder sehr kompakten IT-Sicherheits-Teams.

Canarys stärken gleichzeitig die Security-Awareness, indem sie allen Teilen der Organisation ständig bewusst machen, dass Prozesse und adäquates Verhalten und Zusammenarbeit der Mitarbeiter mindestens ebenso nützlich sein können wie alle noch so ausgefeilten technischen Controls.

Kurz und knapp: Jede Organisation sollte Canarys einsetzen – und in der Ausbildung zur IT-Security dürfen sie keinesfalls fehlen!

Andreas Englisch (www.linkedin.com/in/englisch) arbeitet derzeit als IT-Security-Officer, hält eine CISM- sowie CISSP-Zertifizierung und hat bereits diverse Fachartikel im Bereich Cyber-Security veröffentlicht.