Über die Aufdeckung der Langsamkeit : Möglichkeiten zur Erkennung geduldiger Angreifer
Unternehmen, die mit gezielten Angriffen rechnen, investieren zur Abwehr in SIEM-Systeme oder vergleichbare Netzwerk-Monitoring-Ansätze, bauen ein Security-Operations-Center(SOC) auf und professionalisieren ihr Vorfalls-Management. In der üblichen Auslegung helfen solche Maßnahmen aber nicht automatisch auch gegen Widersacher, die extremgeduldig und in kleinen Schritten vorgehen. Wo derartige Bedrohungen zu befürchten sind, kann eine geeignete, gar nicht einmal so außergewöhnliche Justierung der Sicherheitsmaßnahmen und -prozesse helfen – und auch spezielle SIEM-Technik steht zur Verfügung.
Von Johannes Wiele, München
Die moderne Cyber-Sicherheit hat gelernt, dass reine Prävention keinen ausreichenden Schutz gegen alle Gefährdungen bieten kann. Der Aufbau von Detektions- und Reaktionskapazitäten steht immer häufiger in den Security-Programmen von Organisationen, die mit gezielten Ausforschungen oder Sabotageversuchen rechnen. Dies wiederum kalkulieren aber auch die Angreifer ein, die mit speziellen Strategien die wachsenden Monitoring-Fähigkeiten der Unternehmen austricksen wollen.
Eine Vorgehensweise zur Umgehung moderner Überwachungswerkzeuge ist die bewusste „Entschleunigung“ eines Angriffs. Moderne Erkennungs- und Vorfallsmanagement-Werkzeuge, wie etwa Security-Information- und -Event-Management-Systeme (SIEM), arbeiten mit Korrelationstechniken, um bekannte oder erwartete Vorgehensweisen von Angreifern zu erkennen. Dazu suchen sie nach Beziehungen zwischen Einzelereignissen: Setzt beispielsweise ein Datendiebstahl aus einer Datenbank voraus, dass zuvor bestimmte Firewallregeln geändert, eine interne Identität gekapert und Zugriffsprivilegien erweitert werden müssen und danach bestimmte Datenbewegungen stattfinden, so wird dieser Ablauf (Kill-Chain) in eine Erkennungsregel gegossen und die potenziell betroffene Umgebung vom Detektionssystem permanent auf das Eintreten der Aktionsabfolgen hin überwacht.
Ein anderes Konzept setzt auf die Erkennung von Anomalien, sucht also im Umfeld eines wichtigen Assets nach Vorgängen, die dort normalerweise nicht vorkommen. Dazu muss man allerdings zuerst über eine gewisse Zeit den Normalbetrieb erheben und als solchen definieren. Regel- und Anomalie-basierte Detektion lassen sich zudem auch in Kombination einsetzen.

(Vermeintlich) langsam muss nicht ungefährlich sein – kampferprobte Schnappschildkröte in Angriffsstellung
Korrelation mit Spam-Bremse
Um SOC-Teams von unwichtigen Nachforschungen und „False Positives“ zu entlasten, sind SIEM- und Network-Monitoring-Systeme aber nicht immer so eingestellt, dass sie beim Auftreten jedes einzelnen Schritts aus einer potenziellen Kill-Chain oder jeder winzigen Anomalie Alarm schlagen. Sie tun dies vielmehr nur dann, wenn mehrere Anzeichen für einen Angriffsverlauf in gewisser zeitlicher Nähe zueinander auftreten. Bei einer schnellen Folge vieler missglückter Anmeldeversuche an einem kritischen System werden sie etwa mit Sicherheit eine Meldung absetzen – bei einzelnen Auffälligkeiten in größeren Abständen aber nicht. Dabei schlägt auch zu Buche, wie viele Logdaten ein System aus Kapazitätsgründen überhaupt aktiv in einem gewissen Zeitfenster betrachten kann. Nach einer gewissen Zeit werden die Informationen deshalb abgelegt und für forensische Analysezwecke langzeitgespeichert.
Zieht somit ein Angreifer die Schritte seiner Attacke – aus Sicht der Sicherheits-Teams also die möglichen „Indicators of Compromise“ (IoCs) – zeitlich weit genug auseinander, besteht die Gefahr, dass das Opfer sie erst dann bemerkt, wenn der Vorfall bereits stattgefunden hat und somit alles zu spät ist. Dies gilt zumindest dann, wenn das Security-Team allein den Standard-Prozeduren gängiger SOC-Werkzeuge vertraut.
Ähnlich problematisch sieht es aus, wenn die Erkennung von Angriffen Anomalie-basiert erfolgt: Auch hier können notwendige Schwellenwert-Einstellungen verhindern, dass es zum Alarm kommt. Und auch andere Aspekte können Angreifern in die Hände spielen: Hat ein Unternehmen etwa eine eher liberale Haltung zur Vergabe von Administrationsrechten an Endgeräten, kann sie nicht jede Handlung, die davon Gebrauch macht, automatisch als Sicherheitsverstoß werten.
Es hängt also viel von der Qualität der Definition des Normalzustands oder Normalbetriebs ab – und davon, ob überhaupt trennscharf zwischen normalen und anormalen Vorgängen unterschieden werden kann. Sind hauptsächlich menschliche Anwender in einem kreativen Umfeld mit wechselnden Tätigkeiten im Spiel, erzielt speziell das Modell der Anomalie-Erkennung eventuell nur eine geringe Effektivität.
Piratenschatz und Königskind
oder: Gezielte Angriffe sind nicht immer Prio 1!
War das ein altes Kinderbuch oder ein Film? Eine Familie hatte sich ein Haus am Strand gebaut und genoss das Leben am Meer. Aber irgendwann wurde das Glück gestört: Finstere Gestalten lauerten den Kindern an der Schule auf und stellten seltsame Fragen. Jemand brach ein und stahl nichts, aber hinterließ Löcher im Kellerboden. Es stellte sich heraus, dass das Haus genau auf einen vergrabenen Piratenschatz gebaut wurde und dass die Nachfahren der Freibeuter davon Wind bekommen hatten.
Oder dieses alte Märchen, in dem ein redliches Bauernpaar ein Findelkind aufnimmt und Jahre später plötzlich von fremden Rittern und Räubern bedrängt wird. Die Lösung: Der unbekannte Junge ist ein Königssohn und Thronfolger, den skrupellose Rivalen aus dem Weg räumen wollen. Beiden Geschichten gemeinsam ist der Charakter der Bedrohungslage: Niemand vermag sich gegen derart spezielle Gefahren zu wappnen. So kann etwa nicht jeder Bauherr vor der Grundsteinlegung erst nach vergrabenen Schätzen oder Hinweisen darauf fahnden.
Der unmögliche Schutz gegen das Unvorstellbare beschäftigt die Menschheit schon immer und steckt deshalb hinter so manchem Mythos, Märchen und Roman. Wen wundert’s, dass die historisch so junge Informationssicherheit damit erst recht Probleme hat? Zuweilen überschätzt sie allerdings das Problem der gezielten, ausgefeilten Angriffe bei Weitem und vernachlässigt dafür viel wahrscheinlichere Gefahren.
Opportunistisch versus gezielt
Ein Beispiel aus der realen Beratungswelt: Während eines Assessments fällt auf, dass das untersuchte Unternehmen beträchtliche Ressourcen in den Aufbau einer SIEM/SOC-Struktur investiert, Projekte zur Netzwerk-Segmentierung und zur Reduktion der intern weit verbreiteten Admin-Rechte auf Clients aber auf die lange Bank schiebt. Käme es zu einem Ransomware-Ausbruch, also einer ungezielten und opportunistischen Attacke, könnte aufgrund der Aufstellung auch das SOC nicht mehr helfen: Die Malware würde sich so schnell und ungehindert im Netz verbreiten, dass das SOC den Vorfall nur noch melden könnte – und zwar zu einem Zeitpunkt, zu dem die Verschlüsselung von Computern den Mitarbeitern ohnehin schon längst auffiele. Noch schlimmer: Weil die Produktionsanlagen des Beispiel-Unternehmens in ungewöhnlichem Maße auch von leidlich aktuellen Windows-Systemen gesteuert werden, könnte Ransomware vermutlich auch diesen Bereich schnell lahmlegen.
Demgegenüber zeigt eine schnell durchgeführte Bedrohungsanalyse, dass das Unternehmen überhaupt kein typischer Kandidat für gezielte Attacken von innen oder außen ist: Das zentrale Produkt des Hauses wird weithin geschätzt, es hat sich über die Jahre hinweg evolutionär gut in Richtung Umweltneutralität entwickelt, der Anbieter gilt in seiner Region als beliebter Arbeitgeber und ist von der Größe und Struktur her unauffällig. Wollte ein Konkurrent wirklich einmal die technische Struktur der Produkte ausforschen, um etwas abzukupfern, könnte er sich einfach eines kaufen und es demontieren – das wäre weitaus billiger, weniger risikoträchtig und aussagekräftiger als ein komplexer Angriff auf die IT des Herstellers.
Somit entfallen die wichtigsten Argumente für eine Priorisierung der Abwehr gezielter Attacken:
- Betriebsgeheimnisse, die nur über einen Angriff auf die IT auszuforschen sind
- Reibungsflächen und Ansatzpunkte für Aktivisten oder Terroristen unterschiedlichster Couleur
- verärgerte Mitarbeiter, die sich gegen das eigene Unternehmen wenden
Als die Auditoren beim Sicherheitsmanagement nachfragen, warum angesichts dieser Ausgangslage trotzdem das SOC-Thema und die Detektion komplexer Kill-Chains priorisiert wurden, zeigt sich schnell eine Gemengelage von Handlungshindernissen: Für die dem Team durchaus bewussten Mängel bei der internen Segmentierung würde man personelle Ressourcen benötigen, die einfach noch fehlen – und beim Entzug individueller Admin-Rechte befürchtet man Widerstände. Das SOC dagegen ließ sich vergleichsweise schnell über einen externen Managed-Service-Anbieter realisieren. Der wiederum hatte allerdings nicht darauf hingewiesen, dass die Schwächen bei der präventiven Sicherheit die Effizienz des SOC stark reduzieren würden. Hinzu kam, dass sich das Thema SOC gegenüber der Unternehmensleitung leicht präsentieren ließ.
Und die Moral von der Geschicht: Der in diesem Beitrag diskutierte Schutz gegen extrem ausgefuchste, geduldige Angriffe ist für manche Unternehmen von großer Bedeutung – für viele aber auch nicht. Eine gründliche Bedrohungsanalyse muss immer in eine konsequente Priorisierung münden, sonst wirft man leicht das knappe Security-Budget zum Fenster hinaus oder schafft an anderer Stelle zu viele Schwachstellen (vgl. S. 6).
Geduld trifft Mehrdimensionalität
Man könnte nun einwenden, dass ein langsames Vorgehen auch die Angreifer selbst ausbremst und somit weniger gefährlich macht. Immerhin verlangen beispielsweise die üblichen Methoden, um ein Kennwort zu erraten, bei halbwegs starken Kennwörtern nach Brute-Force-Attacken mit einer ungeheuren Zahl von Versuchen in schneller Folge. Deshalb greift man ja häufig auch zum Mittel der Zwangswartezeit nach einer einstellbaren Zahl von aufeinanderfolgenden Fehleingaben, um einen möglichen Angreifer bewusst in Warteschleifen zu schicken. Muss also ein langsamer Angreifer nicht ohnehin schon so lange am Ball bleiben, dass sich sein Unterfangen kaum lohnt oder sich der ursprüngliche Angriffsgrund einfach von selbst erledigt?
Nein, denn dieser Gedanke lässt außer Acht, dass Cyberkriminelle bei einer gezielten Attacke mit hoher Wahrscheinlichkeit auch weiteren Aufwand in Gestalt von Social Engineering und Vor-Ort-Spionage (z. B. Dumpster-Diving) betreiben, um die Zielgenauigkeit ihrer bewusst vereinzelten technischen Angriffsschritte zu erhöhen. Um zum Kennwort-Beispiel zurückzukehren: Statt viele zufällige Passwörter zu verwenden, probieren sie wenige, die mit einer gewissen Wahrscheinlichkeit richtig sind – etwa, weil der Nutzer, dessen Identität sie kapern wollen, diese Kennwörter schon anderswo verwendet hat oder per Phishing preisgegeben hat oder weil diese einen Bezug zu seinem Leben haben (Name von Partner, Hund, Katze oder Yacht, Daten wie Hochzeits- oder Geburtstag usw.).
Aktionen, mit denen Kriminelle derartige Informationen erheben, liegen aber gewöhnlich außerhalb der Reichweite technischer Security-Sensorik – und ein internes Meldewesen für sicherheitsrelevante Beobachtungen, das diese blinden Flecke wettmacht, existiert kaum irgendwo und würde auch nur dann funktionieren, wenn irgendwem die physischen und psychologisch-kommunikativen Schritte der Angreifer überhaupt auffielen.
Anders ausgedrückt: Die Langsamkeit, von der hier die Rede ist, geht nicht automatisch mit einer geringen Intensität der Angriffstätigkeit als Ganzes einher! Sie bedeutet lediglich, dass ein Großteil der gefährlichen Aktivitäten unter dem Radar der gewöhnlichen Monitoring-Systeme bleibt.
Eine gängige Reaktion auf solche Überlegungen ist es, gezielte Attacken der beschriebenen Art als „unerkennbar“ zu betrachten und in die Rubrik Restrisiko einzusortieren. Tatsächlich kann aber das richtige Maßnahmenbündel auch diese zu einem guten Teil enttarnen.
Die im Folgenden dargestellte Strategie basiert dabei auf zwei zentralen Annahmen:
- Der Aufwand, den Angreifer bei langsam getakteten Vorgehensweisen treiben müssen, lohnt sich nur bei extrem wertvollen Zielen.
- Wie auch immer sich Kriminelle verbergen: Sie können bestimmte Handlungen, die sie zum Ziel führen – also etwa den eigentlichen Datendiebstahl oder die eigentliche Betriebsstörung einer Produktionsanlage – nicht auslassen und nicht endlos aufschieben.
Beide Aspekte ermöglichen es, auch geduldige Vorgehensweisen aufzudecken, wenn man dafür bestimmte Voraussetzungen schafft. Die meisten davon sind nicht einmal nur speziell gegen die hier behandelte Angriffsform wirksam, sondern erhöhen generell die Widerstandskraft einer Organisation gegen Cyber-Attacken. Grundsätzlich geht es größtenteils darum, bei kritischen Zielen in einer Organisation den Fokus der Erkennung gezielt auch auf Einzelereignisse zu richten, ohne damit das Gesamtaufkommen zu untersuchender Vorkommnisse (zu stark) zu erhöhen.
Bedrohungsanalyse
Bevor eine Institution größeren Aufwand gegen gezielte Attacken und gegen den noch spezielleren Fall der zeitlich ausgedehnten Kill-Chains treibt, sollte sie zunächst klären, ob die entsprechenden Gefahren für sie überhaupt relevant sind (siehe Kasten auf S. 11). Nicht gegen jedes Unternehmen lohnt sich eine entsprechend komplexe Angriffsstrategie – nur dann, wenn der Charakter der dort vorhandenen Informationen oder Produktionsprozesse einen derart aufwändigen Angriff rechtfertigt, sollten personelle und finanzielle Ressourcen darauf fokussiert werden.
Risikoanalyse und risikobasiertes Monitoring
Hält ein Securityteam ausgefeilte Angriffe für möglich oder gar wahrscheinlich, kann es immer noch sein, dass die damit verbundenen Risiken trotzdem gering sind. Ein Beispiel: Ein Produzent technischer Gase betreibt zwar potenziell gemeingefährliche Anlagen, aber diese sind mit nachweislich wirkungsvollen, von der IT völlig unberührten Schutzmaßnahmen (z. B. mechanische Sicherheitsventile und Not-Abschaltung) ausgestattet, die auch per IT mutwillig ausgelöste Fehlfunktionen sicher abfangen können. Dann besteht zwar immer noch das Restrisiko eines Produktionsausfalls, aber nicht das einer menschen- und umweltgefärdenden Katastrophe.
Die Risikoanalyse muss also nicht nur die kritischen Informationen, Prozesse und Systeme im Unternehmen, sondern auch deren tatsächliche Bedrohung durch Cyber-Angriffe sichtbar machen. Bei allen Assets, bei denen tatsächlich ein hohes Cyber-Restrisiko besteht, sollten die Sicherheitsteams eine Alarmierung dann auch bei verdächtigen Einzel-Ereignissen zulassen.
Die strenge Risikobasierung eines Sicherheitsmonitorings ermöglicht es besser als jeder sonstige Automatismus, gezielt zu überwachen und dennoch die Zahl der behandlungsbedürftigen Alarme zu reduzieren. Das fällt umso leichter, je gründlicher Risiko- und Kontextinformationen zu Systemen und Informationen in einer für Menschen und (Sicherheits-) Maschinen lesbaren Asset-Datenbank nachgeführt werden.
Zugriffssteuerung und Rechtevergabe
Ein Schritt, um den auch ein geduldiger Angreifer auf keinen Fall herumkommen kann, ist das Kapern einer Identität mit Zugriffsrechten auf das Zielsystem. Das Ausprobieren von Credentials wird, wenn es nur hin und wieder stattfindet, im Rauschen der unbeabsichtigten Fehleingaben untergehen.
Was man erschweren kann, ist beispielsweise die Erweiterung von Zugriffsrechten auf ein kritisches System, gleich ob es sich dabei um ein produktives Asset oder ein Sicherheitssystem wie etwa eine Firewall mit restriktivem Regelsatz vor einem relevanten Netzwerksegment handelt. Ist jeder Vorgang der Rechteerweiterung – genau wie andere sicherheitsrelevante Vorgänge, wie etwa die Änderung der Konfiguration von Sicherheitswerkzeugen – einem strikt einzuhaltenden Change-Management-Prozess unterworfen, lässt sich auch jede einzelne Abweichung davon prinzipiell als sicherheitsrelevanter Vorfall werten, der einen Alarm verdient, sodass eine zeitliche Entzerrung von Versuchen dem Angreifer nichts bringt. Viele „False Positives“ sollte es bei konsequenten Regelungen in diesem Bereich nicht geben. Voraussetzung ist natürlich, dass man Administrationsrechte generell so sparsam wie irgend möglich vergibt.
Die Aktionen von Mitarbeitern, die bereits weitreichende Rechte haben und auch häufig damit arbeiten, sollten bei wichtigen Vorgängen mit Zwei-Faktor-Authentifizierung oder Sicherheits-Rückfragen abgesichert werden. Darüber hinaus sind für diese Gruppe Awareness-Maßnahmen sinnvoll, die auch ein Training gegen Social Engineering umfassen, um dem gezielten Ausforschen im Rahmen fokussierter Attacken etwas entgegenzusetzen.
Präventive Forensik
Langsam ablaufende Kill-Chains haben einen Vorteil: Sie verstecken sich zwar gut, lassen aber auch dem Opfer mehr Zeit. In hoch riskanten Umgebungen lohnt es sich, über mögliche böswillige Vorgehensweisen nachzudenken und von Zeit zu Zeit gezielt im Langzeit-Datenbestand danach zu suchen – etwa danach, ob ein bestimmter Anwender oder sogar eine externe IP-Adresse zwar selten, aber konsequent versucht, Zugriffsrechte auf hoch vertrauliche Daten zu erlangen.
Diese Form des „Fischens im Trüben“ ist zwar eine mühsame Angelegenheit, kann neben Angriffen aber auch andere Aspekte der IT-gestützten Arbeit sichtbar machen – etwa unzureichende Prozesse, die Mitarbeiter zuweilen zu „kreativen Umgehungsversuchen“ verleiten.
SIEM mit Seeblick
Der Vollständigkeit halber sei noch erwähnt, dass eine heute immer beliebtere SIEM-Technik dem Vorgehen gegen Schritt-für-Schritt-Attacken sehr entgegenkommt. Es handelt sich dabei um Systeme, die Logdaten permanent zunächst normalisiert und um Kontext-Daten angereichert in sogenannten Data-Lakes ablegen und die korrelierende Suche nach Kill-Chains grundsätzlich in Form rasend schnell durchgeführter Suchanfragen abhandeln.
Die Trennung zwischen Logdaten, die das System noch aktiv analysiert, und solchen, die längerfristig aufbewahrt werden, ist hier weniger strikt, was das Schreiben von Detektionsregeln erleichtert, die Vorgänge auch über einen langen Zeitraum zueinander in Beziehung setzen.
Die Basis hierfür ist häufig der sogenannte Open- und Closed-Source-„ELK-Stack“ aus Elasticsearch, Kibana, Beats und Logstash, ergänzt um selbst entwickelte SIEM-Routinen oder kommerzielle Zusatzwerkzeuge – auch der Anbieter Securonix gehört in das entsprechende konzeptionelle Umfeld.
Der generelle Vorteil dieses Ansatzes liegt darin begründet, dass sich kreativ immer neue Untersuchungsanfragen an einen relevanten Datenbestand richten lassen. Unternehmen, die sich für ein derartiges Konzept entschieden haben, können die Suche nach Langzeit-Kill-Chains damit möglicherweise leichter automatisieren als Nutzer anderer Monitoring-Systeme.
SIEM-Systeme, die sich aus zunächst securityfremden Log-Management-Lösungen zu Sicherheitswerkzeugen entwickelt haben, bieten bei Bedrohungen durch Langzeit-Angriffe offenbar generell eine größere Flexibilität – eben weil man bei ihnen von vornherein damit gerechnet hat, dass man auf den einmal erhobenen Datenbeständen später immer wieder neue Analysen anwenden will.
Ein bekanntes Beispiel dafür ist auch Splunk: Hier sind laut Hersteller Korrelations-Zeiträume von 90 Tagen, 180 Tagen oder sogar einem Jahr durchaus üblich. Bei Falschanmeldungen greifen Anwender häufig zu einem „Throtteling“ (Aggregierung der Alarme) pro User über 24 Stunden. Im Falle von Use-Cases für erstmalige Nutzung („First-Use“-Szenarien) ist es nicht ungewöhnlich, auch einmal 90–120 Tage lang nach potenziell zugehörigen Aktionen zu fahnden – etwa, wenn ein Nutzer eine neue Business-Applikation verwendet oder auf ein neues Netzlaufwerk zugreift oder ein privilegierter Administrator sich auf einem System / von einem System lokal zum ersten Mal einloggt. Letztlich kann die User-Behaviour-Analytics (UBA) von Splunk mit Baselines von drei Jahren arbeiten. Anhand dieser Daten lässt sich schon erkennen, dass hier eher typische Compliance- und Ressourcen-bedingte Aufbewahrungs- und Löschfristen als technische Vorbedingungen die Grenzen festlegen.
Wahrscheinlich wird kaum ein Unternehmen ein SIEM-System primär danach auswählen müssen, wie gut es mit Langzeit-Kill-Chains umgehen kann. Bei Organisationen mit einem hohen Risikolevel in diesem Bereich lohnt es sich aber, den Aspekt beim Auswahlprozess mit zu berücksichtigen und bei Lösungen, die prinzipbedingt weniger auf den beschriebenen Sonderfall ausgelegt sind, den Hersteller nach Workarounds zu fragen. QRadar von IBM etwa, um einmal ein „klassischeres“ SIEM zu erwähnen, hebt Log-Dateien bei Bedarf auch über längere Zeiträume auf. Will man hier von Zeit zu Zeit „präventive Forensik“ betreiben, sollte der Anbieter oder das implementierende Beraterteam in der Lage sein, diesen Vorgang auch bei solchen Systemen so weit wie möglich zu automatisieren.
Fazit
Geduldige Cyberkriminelle, die sich Schritt für Schritt immer näher an kritische Systeme im Unternehmensnetz heranschleichen, sind eines jener Schreckgespenster, deren effektive Abwehr manchen Security-Spezialisten fast unmöglich erscheint. Dabei hält sich die Wirksamkeit des langsamen Vorgehens durchaus in Grenzen, wenn Unternehmen ihre kritischen Systeme kennen und diese geschickt intensiver schützen und überwachen als die übrigen Systeme im Netz.
Damit verliert die Taktik des „Versteckens in der Zeit“ dann auch schon fast ihren Status als Besonderheit unter den Bedrohungen: Wo immer Angreifer fokussiert und priorisiert vorgehen, muss man dem eine entsprechende Abwehr entgegenstellen – und deren Basis ist und bleibt eine intensive Risiko-Analyse.
Dr. Johannes Wiele (johannes@wiele.com) ist freier Autor sowie GDD-geprüfter Datenschutzbeauftragter und arbeitet als Senior-Manager in der Cybersecurity-Beratung.