Warum Analytics-Driven Security heute notwendig ist – Wie aus „Intrusion Prevention“ „Assume Breached“ wurde

Oft heißt es in den Medien und in der Fachliteratur: „Wir haben den Kampf gegen die Angreifer längst verloren“. Das ist wohl vor allem drei Tatsachen geschuldet:

1. Die IT-Industrie hat immer noch kein probates Mittel zur verlässlichen Vermeidung von Software-Schwachstellen gefunden.
   
   
2. Angreifer treten immer organisierter und professioneller auf.
   
   
3. Wir befinden uns in einem asymmetrischen Krieg, in dem wir alle offenen Türen (System- und Software-Schwachstellen) bewachen müssen, während Angreifer lediglich durch eine einzige unbewachte Tür schlüpfen müssen.

Aber so schlimm ist es eigentlich gar nicht. Es besteht nämlich Hoffnung – je nachdem welchen Blickwinkel man einnimmt. 

Wenn man den Blickwinkel „Intrusion Prevention um jeden Preis“ einnimmt, dann kann man nur verlieren, denn der Angreifer wird solange versuchen sich Zutritt zu verschaffen, bis er es eben geschafft hat (siehe asymmetrische Gemengelage oben).

Wenn wir aber auch einen Schwerpunkt auf Detektion und Spurensuche legen, dann haben wir eine echte Chance dem Angreifer ein Schnippchen zu schlagen. Das bringt uns zu „Assume Breached“

„Assume Breached,“ ist also der Paradigmenwechsel in der IT-Security weg von der Annahme, man könne das Unternehmen so „abdichten,“ dass kein Angreifer reinkommt, hin zu der Annahme, dass sich der Angreifer bereits Zutritt verschafft hat und es nun darauf ankommt den Angreifer so schnell wie möglich zu erkennen, so dass dieser seine Ziele nicht erreichen kann. 

Denn das es der Angreifer geschafft hat Systeme zu infizieren und „einen Fuß in der Tür“  des Unternehmensnetzwerks hat, ist im Grunde nicht das Problem. Das wirkliche Problem manifestiert sich, wenn man dem Angreifer das gibt, was er am meisten braucht: Zeit! Zeit, um wertvolle Assets zu finden, zu stehlen, zu verschlüsseln, zu zerstören oder was auch immer das Ziel des Angreifers ist. 

Auf die Cyber-Killchain projiziert sieht das Problem also folgendermaßen aus:

Was hat dies nun mit eurer Security-Analyse bzw. eurem SIEM zu tun?

Um dies zu erläutern, möchte ich hier kurz die zwei Begriffe „Intrusion Prevention“ und „Assume Breached“ im Kontext der Security-Analyse bzw. des SIEM erläutern:

„Zielgerichtete und persistente Angriffe spielen sich in den wenigsten Fällen in Minuten ab, sondern in Tagen, Wochen und Monaten.“

Intrusion Prevention:

Die ersten SIEM-Systeme haben sich auf In-Memory-Korrelation eines bekannten Datenformats fokussiert, um Angriffe wie Virenausbrüche und Denial-of-Service schnellstmöglich zu erkennen und einzudämmen. So z. B. meldet die Firewall Traffic auf einem bestimmten Port und kurze Zeit später schlägt das IDS (Intrusion Detection System) an. Das Hauptaugenmerk ist auf „kurze Zeit später” zu richten. Legacy-SIEM-Systeme sind aufgrund der Datennormalisierung während der Datenaufnahme und dem Datenbank-basierten Ansatz sehr schnell was die Korrelation bekannter Felder innerhalb einer kurzen Zeitspanne (meist Minuten oder wenige Stunden) angeht.

Zielgerichtete und persistente Angriffe spielen sich jedoch in den wenigsten Fällen in Minuten ab, sondern eher in Tagen, Wochen und Monaten. Angreifer, die ein bestimmtes Unternehmen als Ziel ausgewählt haben, werden solange versuchen in das Netzwerk zu kommen, bis sie es letztendlich geschafft haben. Intrusion Prevention ist also für diese Art von Angriffen defacto nicht möglich und es kommt nun darauf an, ob ihr die Angreifer im Netzwerk rechtzeitig identifizieren und deren Ziel (z. B. Data Exfiltration) verhindern könnt. SIEMs mit einem sehr kurzen Korrelationsfenster sind hierfür also praktisch „blind” (weitere Einschränkungen von Legacy SIEMs und was außerdem noch essentiell für ein funktionierendes und zeitgemäßes SIEM ist, erfahrt ihr übrigens hier).

Bei Splunk kann der Zeitraum für die Korrelation frei gewählt werden. Die Daten werden erst zur Laufzeit bzw. zur Suchzeit formatiert und normalisiert (Schema-On-Read), d.h. ihr könnt genauso flexibel sein, wie die Angreifer. Wenn ein neues Angriffsmuster bekannt wird und ein neues Feld für die Korrelation/Forensik extrahiert werden muss, dann kann das in Splunk jederzeit sehr einfach via der Abfragesprache (SPL) gemacht und auf alle bestehenden und zukünftigen Daten angewendet werden, ohne den Mechanismus der Datenaufnahme zu verändern oder zu unterbrechen. Bei Splunk werden die Daten immer im RAW-Format aufgenommen und gespeichert. Das Angriffsmuster bzw. die Angriffstechniken können dann z. B. via MITRE ATT&CK beschrieben und deren Erkennung in Splunk getestet werden.

Eine tolle Einführung auf Deutsch in das Thema MITRE ATT&CK findet ihr hier. Außerdem haben wir eine Liste mit 10 Wegen, wie ihr das MITRE ATT&CK-Framework in die Praxis umsetzt zusammengestellt. Und falls ihr ein praktisches Beispiel für den Einsatz des Frameworks sucht, seht euch einfach das Webinar „Wie DATEV mithilfe von MITRE ATT&CK sein SOC auf das nächste Level heben konnte“ an. Empfehlenswert ist außerdem der englischsprachige Artikel unseres Security Research Teams „Using Splunk Attack Range to Test and Detect Data Destruction“.

„Ein Medienbruch zwischen Monitoring, Korrelation und Investigation ist nicht nur hinderlich, sondern ein K.O Kriterium!”

Assume Breached:

Wie bereits angesprochen, hat sich in der IT-Security-Industrie aus dem Sachverhalt oben das Verständnis entwickelt, dass man grundsätzlich davon ausgehen sollte, dass sich der Angreifer bereits Zugang zum Netzwerk verschafft hat und es nur noch darauf ankommt, wie schnell man dies erkennt bzw. ob man den Angreifer vor der Erreichung seines Ziels stoppen kann. Hierbei ist der investigative Ansatz immanent wichtig und ein Medienbruch zwischen Monitoring, Korrelation und Investigation ist nicht nur hinderlich, sondern ein K.O Kriterium! 

Mit anderen Worten: Um den Medienbruch zu verhindern, sollten Security Analysten für sämtliche Tätigkeiten im SOC (Level 1-3, von der Triage über die Analyse bis hin zum Threat Hunting und der Automatisierung) eine einzige Abfragesprache für ein einziges (Big-Data) Daten-Repository nutzen. Dies ist mit Splunk ohne Probleme möglich.

Letztendlich muss folgender IT-Security Super-GAU verhindert werden: Das Unternehmen (und der Rest der Welt) erfährt von einer Kompromittierung durch einen Artikel in der Presse. Für einen kontrollierten Incident-Response-Ablauf ist es dann viel zu spät.

Die Zeit zwischen der initialen Infiltration und der Erkennung des Incidents nennen wir Mean-Time-To-Detect (MTTD). Im Falle des Super-GAUs „In the News“ ist diese zu groß und der Angreifer hat längst sein Ziel erreicht.

Es kommt also darauf an, die MTTD so zu verkürzen, dass überhaupt die Chance besteht eine Reaktion einzuleiten (Mean-Time-To-Respond, MTTR), bevor der Angreifer das Ende der Cyber-KillChain und somit sein niederträchtiges Ziel erreicht. 

Wenn das der Fall ist, dann gewinnen die Guten. Wie gesagt, es besteht Hoffnung!

Wie Splunk die Spurensuche ermöglicht und die Indizien korreliert (rote Punkte in der Grafik, Indicator of Compromise) ist sehr schön in dieser Blog Sammlung dargestellt: Hunting with Splunk

So weit so gut – wir sind nun also in der Lage einen Angriff rechtzeitig zu erkennen und entsprechende Warnmeldungen auszulösen. Wenn die Reaktion aber nicht zeitnah erfolgt, dann war alles umsonst. Das allseits (in einem SOC) bekannte Problem ist: Es gibt zu viele Alarme und zu wenig Personal (Security Analysten), um diese zeitnah abzuarbeiten und es entsteht immer wieder die Situation, dass man den Wald vor lauter Bäumen nicht sieht und die wirklich wichtigen Benachrichtigungen im Rauschen untergehen.

Um also die Zeitspanne/MTTR so klein wie möglich zu halten ist Automatisierung essentiell wichtig. Wie ihr dies erreicht und welche weiteren Vorteile sich dadurch ergeben, erfahrt ihr in Kürze hier, in einem weiteren Blog-Artikel. Um diesen nicht zu verpassen, abonniert am besten gleich hier unseren Blog.

In der Zwischenzeit kann ich diese Lektür zum Thema SOAR wärmstens empfehlen, ebenso wie unsere englischen Blog-Posts „Confessions of Security Analysts“ und „Too Many Security Alerts, Not Enough Time: Automation to the Rescue“.

Viel Erfolg & bis demnächst!

Angelo