TIBER-EU Framework - Threat Intelligence-basiertes Red Teaming

TIBER-EU Framework

Threat Intelligence-basiertes Red Teaming

Dominik Altermatt
von Dominik Altermatt
am 19. November 2020
Lesezeit: 16 Minuten

Keypoints

Das bringt das TIBER-EU Framework

  • Das Framework deckt viele wichtige Faktoren von erfolgreichen Red Teamings ab
  • TIBER-EU strebt einen "Real-World"-Ansatz an
  • Der TIBER-EU Prozess kann jedoch Red Teams einschränken und somit allenfalls Ineffizienzen verursachen
  • scip AG setzt mehr auf effektive Detektion von Schwachstellen anstatt auf den Anspruch möglichst "Real-World" zu agieren

scip AG führt seit bald 20 Jahren erfolgreich Red Teaming Projekte und Angriffs-Simulationen durch. Dabei sind unsere Kunden Organisationen, welche eine gewisse Maturität bezüglich Informationssicherheit aufweisen. Vor allem der Finanz-Sektor ist dabei als Kunde gut vertreten. Mit TIBER-EU (Red Teaming auf der Basis von Threat Intelligence) wurde 2018 durch die Europäische Zentral Bank ein Framework für Red Teaming Projekte veröffentlicht. In diesem Beitrag beschäftigen wir uns mit diesem Framework, um einen Überblick zu verschaffen und dessen Anforderungen und Empfehlungen gegenüber unseren praktischen Erfahrungen zu vergleichen.

Das TIBER-EU Framework wurde mit dem Ziel, das Vorgehen für Red Teaming Projekte für nationale Zentralbanken sowie als kritisch bezeichnete Funktionen im EU-Finanz-Sektor, zu standardisieren. Das Framework kann aktuell freiwillig national adaptiert werden. Eine nationale TIBER-Implementationen wird mit dem entsprechenden Landeskürzel versehen, z.B. TIBER-BE (Belgien) oder TIBER-NL (Niederlande).

Es wird einerseits eine Governance-Struktur zur korrekten und sicheren Durchführen beschrieben. Diese soll sicherstellen, dass Red Teaming Projekte vergleichbar und EU-weit anerkannt werden können, sowie die Möglichkeit Lesons Learned zu sammeln und in Verbesserungen einfliessen zu lassen.

Dies soll z.B mit der Etablierung einer entsprechenden Stelle (TIBER Cyber Team, TCT) auf nationaler Ebene sowie einem zentralen Team (TIBER-EU Knowledge Center) auf europäischer Ebene erreicht werden. Ausserdem wird detailliert beschrieben, welche Stakeholder in welcher Funktion involviert werden können oder müssen.

Andererseits beschreibt das Framework, wie die Test-Phase End-to-End durchzuführen ist und gibt konkrete Anforderungen vor sowie Empfehlungen ab. Dabei sollten möglichst reelle, aktuelle oder gar zukünftige Angriffs-Szenarien durch Threat Intelligence Aktivitäten erarbeitet und anschliessend mittels Red Teaming auf den produktiven Systemen der Ziel-Organisation imitiert werden, um die aktuelle Resilienz der Ziel-Organisation zu prüfen.

Kurz gesagt, verfolgt TIBER-EU folgende Ziele:

Was ist “Threat Intelligence Based Red Teaming”?

TIBER-EU definiert eine Bedrohung (engl. Threat) als:

Auf dieser Basis wird Threat Intelligence wie folgt definiert:

Informationen, die ein relevantes und ausreichendes Verständnis für die Mitigation der Auswirkungen eines potenziell schädlichen Ereignisses liefern.

Threat Intelligence umfasst:

Ein intelligence-geführter Red Team Test imitiert die TTPs (Taktiken, Techniken und Prozeduren) echter Angreifer auf der Grundlage massgeschneiderter Bedrohungsinformationen. Dabei zielt es auf die Personen, Prozesse und Technologien ab, die den kritischen Funktionen der Ziel-Organisation zugrunde liegen, um deren Schutz-, Detektions- und Reaktionsfähigkeit ohne Vorwissen zu testen. Dies ermöglicht es der Ziel-Organisation, ihre reale Widerstandsfähigkeit zu verstehen, indem sie alle Elemente ihrer Geschäftstätigkeit gegen die TTPs der Bedrohungsakteure stellt.

Der TIBER-EU Prozess

Neben den notwendigen Eigenschaften für eine europaweite Akzeptanz über unterschiedliche Gerichtsbarkeiten, interessiert uns vor allem der effektive Prozess zur durchführen von Red Team Projekten. Daher werden wir die übergeordneten Aspekte und Prozesse, nicht weiter im Detail betrachten.

Grob folgt der TIBER-EU Prozess einem klassischen Projekt-Ansatz. Optional wird als initiale Ausgangslage eine Analyse des gesamten Finanzplatzes, in welcher sich die Ziel-Organisationen befindet, empfohlen.

TIBER-EU High-Level Prozess

Für den Prozess Threat Intelligence (TI) und Red Teaming (RT) müssen unabhängige dritte Provider hinzugezogen werden. Die gesamte Projektleitung übernimmt das sogenannte White Team (WT), welches aus Personal der Ziel-Organisation besteht mit der entsprechenden Unterstützung des TCT.

TIBER-EU zwingende Anforderungen:

TIBER-EU Empfehlungen:

Vorbereitungs-Phase

Die Vorbereitungs-Phase beinhaltet neben dem klassischen Projekt-Start auch die Beschaffung der IT und RT Provider, den Scoping-Prozess und die Entwicklung des Projekt-Plans. Der Auswahl der TI und RT Provider wird besondere Aufmerksamkeit geschenkt, so ist deren Können und Qualität massgeblich für den Wert des Tests aber auch für eine reibungslose und sichere Durchführung.

TIBER-EU Vorbereitungs-Prozess

Beschaffung der TI und RT Provider

Für die TI und RT Provider werden hohen Anforderungen angesetzt, damit die notwendige Qualität und Sorgfalt für den sensitiven Test gewährleistet werden kann.

TIBER-EU empfiehlt nur zertifizierte Provider zu wählen, jedoch existiert heute noch keine entsprechende Zertifikations-Stelle.

Daher müssen Ziel-Organisationen die nötige Due Diligence bei der Auswahl selbst durchführen. In den TIBER-EU Beschaffungs-Guidelines und Checklisten werden jedoch detaillierte minimale Anforderungen für die externen Provider dokumentiert. TIBER-EU beschreibt, dass die Verantwortung der Auswahl der TI und RT Provider bei der Ziel-Organisation liegt.

TIBER-EU zwingend Anforderungen:

TIBER-EU Empfehlungen:

Scoping-Prozess

Neben der Auswahl der externen Provider ist der Scoping-Prozess der zweite ausschlaggebende Faktor bei der Planung und Durchführung eines RT-Tests, da er den Rahmen und Inhalt des Tests definiert und damit die Aussagekraft des Reports massgeblich bestimmt.

Anhand von kritischen Funktionen (CF) soll der Scope aufgebaut werden. CFs werden wie folgt definiert: Die Personen, Prozesse und Technologien, die die Ziel-Organisation benötigt, um eine Kerndienstleistung zu erbringen, deren Unterbrechung sich nachteilig auf die finanzielle Stabilität, die Sicherheit und Integrität der Organisation, den Kundenstamm des Unternehmens oder das Marktverhalten der Organisation auswirken könnte.

Anschliessend sollen anhand der CFs Flags (Capture the flag) definiert werden, also die Beschreibung von Aktionen, respektive Zielen, welche einen erfolgreichen Angriff des RT bestätigen. Ein Beispiel dazu könnte sein: Die unbemerkte Exfiltrierung von Kunden-Daten aus einer PCI-Zone.

TIBER-EU zwingende Anforderungen:

TIBER-EU Empfehlungen:

Test-Phase

Das aktive Testen besteht aus zwei Phasen:

  1. Threat Intelligence
  2. Red Teaming

Threat Intelligence

TIBER-EU definiert, dass als Ausgangslage für das Red Teaming definierte Angriffs-Szenarien erarbeitet werden sollen. Diese wiederum sollten auf einem Threat Intelligence Report aufgebaut werden. Damit sollen möglichst relevante und realistische Angriffs-Szenarien abgeleitet werden können, respektive eine reale Bedrohungslage mit ihren Akteuren gezeichnet werden.

Als erstes Resultat soll ein Targeted Threat Intelligence Report (TTI) geliefert werden. TIBER-EU empfiehlt für diese Aktivitäten einen Zeitraum von ca. vier Wochen ein zu planen.

Unteranderem werden folgende Ziele genannt:

Das Ergebnis dieser Aktivität ist die Identifizierung der Angriffsflächen von Personen, Prozessen und Technologien in Bezug auf die Ziel-Organisation und ihren globalen digitalen Fussabdruck auf einer CF-orientierten, systembezogenen Basis.

Weiter soll anhand der gewonnen Erkenntnissen effektive Angriffsszenarien entlang des Projekt-Scopes definiert werden. Diese Szenarien bilden die Verbindung zum RT.

TIBER-EU zwingende Anforderungen:

TIBER-EU Empfehlungen:

Red Teaming

Die RT-Phase ist entsprechend schnell erklärt. Durch die Vorbereitungen wird dem Team anhand der Scope-Definition und den Szenarien ein klarer Auftrag erteilt. Das RT definiert anhand der Szenarien einen konkreten RT-Test-Plan. Dabei sollen einerseits sehr detaillierte Angaben zu TTPs in Bezug zu den Angriffszielen vorab dokumentiert werden. TIBER-EU räumt aber dabei explizit ein, dass Scope, Flags und TTPs während des Testverlaufes geändert werden können sowie auch, dass dem RT grösste mögliche Flexibilität und Kreativität eingeräumt werden soll.

Als Output entsteht der Report des RT, welcher die Befunde dokumentiert.

TIBER-EU zwingende Anforderungen:

TIBER-EU Empfehlungen:

Abschluss-Phase

Das Blue Team (BT) der Ziel-Organisation wird nun über den Test in Kenntnis gesetzt und soll anhand des RT-Reports einen BT-Report mit entsprechenden Gegenmassnahmen erstellen. Mit Workshops sollen RT und BT die Details klären und allenfalls Wiederholungen von gewissen RT-Aktionen durchführen, um Vorgänge besser verstehen zu können.

Natürlich sollte die Ziel-Organisation nun die Implementationen von allfällig geeigneten Gegenmassnahmen planen und durchführen.

TIBER-EU zwingende Anforderungen:

TIBER-EU Empfehlungen:

Fazit

Das TIBER-EU Framework erschient grundsätzlich als solides Werk, viele sinnvolle Anforderungen und Hinweise für eine erfolgreiches Red Teaming sind dokumentiert. Natürlich bringt das Framework ein gewissen Grad an Formalismus und damit die entsprechende Bürokratie mit sich, was aber für die Übergeordnete Akzeptanz des Frameworks sowie der gewünschten Qualität absolut erforderlich erscheint. Dies kann jedoch – je nach Auslegungs-Art – auch negative Einflüsse auf die Arbeit der TI/RT Teams verursachen. TIBER-EU begegneten diesen Risiken jedoch mit den klaren Hinweisen bezüglich der nötigen Flexibilität und dynamischen Scoping währen der Test-Phasen.

In vielen Details deckten sich die Anforderungen mit dem Vorgehen, welches auch wir mit unseren Angriffs-Simulationen anstreben. Jedoch unterscheidet sich unser übergeordneter Ansatz etwas. TIBER-EU strebt ein möglichst realistisches Szenario an, daher auch die vorab Entwicklung von “Real-World” Szenarien durch das TI-Team. Auch das Scoping wird früh im Prozess durch die Ziel-Organisation mit Hilfe des TCT definiert. Durch diese detaillierten Scope- und Szenarien-Definition entsteht das Risiko, dass das Red Team zu stärkt eingeschränkt wird und obwohl dem RT viel Kreativität eingeräumt wird, kann durch eine zu strenge Auslegung des definierten Scope und Szenarien allenfalls wertvolle Information durch das Red Team nicht an den Tag gebracht werden. Daher ist dabei zu empfehlen, dass Vorschlägen vom Red Team grosszügig während der Test-Phase stattgegeben werden sowie auch, dass das RT unbedingt bei der Scoping-Phase Teil der Diskussion sein muss.

Die Erwartungshaltung, dass ein RT in der Lage ist einfach alle möglichen TTPs in einer sehr technischen Tiefe “im Peto” zu haben, scheint nicht ganz realistisch. Der entsprechende Engineering-Aufwand, der dazu notwendig wäre, rechnet sich wohl für viele Offensive Security Unternehmen nicht. Sowie den Hinweis durch TIBER-EU, dass “gute” RTs in der Lage sein sollen Nation-State-Actors zu imitieren, ist etwas speziell. Technisch mag dies teilweise zutreffen, jedoch viele andere Aspekte, wie z.B. der Zugriff auf effektive nachrichtendienstliche Information, wie z.B. Daten von Internet-Providern, oder auch grundsätzlich den Umfang und Qualität von Ressourcen (Budget, Personal, Equipment, etc.) ist bei kommerziellen Anbietern wohl eher selten auf Nation-State-Actor-Level gegeben.

Unser Ansatz verfolgt einen pragmatischen und wirtschaftlich effektiven Weg. Bei vielen Punkten unterscheidet sich dieser nicht von TIBER-EU, jedoch tendieren wir mehr auf simulierte als auf möglichst realistische Szenarien. Dabei zeigt unsere Erfahrung, dass der Kunde innerhalb des gegeben Budgets mehr Schwachstellen/Erkenntnisse gewinnen kann. Dabei setzen wir auf einen möglichst breiten Scope, respektive die gesamte Ziel-Organisation wird idealerweise als Scope definiert und entsprechende CF analog TIBER-EU werden dokumentiert an das RT abgegeben. Weiter raten wir, das Szenario eines kompromittierten Clients als Ausgangslage zu definieren. Die Initiale Kompromittierung bieten wir gerne als separates Modul an, damit eine durchgängige Story dokumentiert werden kann.

Von einem kompromittierten Client-/Rouge Employee-Szenario ausgehend, wird Reconnaissance betrieben und Privilege Escalation und Lateral-Movement Schritt für Schritt analysiert und ausgeführt. Dabei entstehen diverse Angriffs-Pfade, welche entweder zur Kompromittierung von CFs führt oder auch nicht. Mit diesem Ansatz werden unabhängig von definierten Real-Word-Szenarien diverse Schwachstellen in der gesamten Ziel-Organisation zu Tage geführt. Dass detektierte Schwachstellen und erfolgreiche Angriffs-Pfade durch bösartige Akteure ausgenutzt werden können und werden, erscheint in der heutigen Welt leider als gegeben. Daher verzichten wir in RT-Projekten oft auf die ausführliche TI-Analyse und dem Beweis dieser Tatsache.

Dies bedeutet jedoch nicht, dass TI nicht relevant wäre. Wir würden Analysen in diesem Bereich jedoch unabhängig von RT-Projekten als separate Aufgabe durchführen. Auch entsprechende Schwachstellen-Analysen des Perimeters sowie etwa OSINT würde wir als Module lose kapseln.

Ob sich TIBER-EU in der aktuellen Form weiter durchsetz, wird sich zeigen. Diverse europäische Länder haben bereits ihre eigenen Adaptionen umgesetzt oder arbeiten daran. Auch ein allfälliges Obligatorium solcher Tests durch den Regulator könnten sehr interessante Effekte haben.

Über den Autor

Dominik Altermatt

Dominik Altermatt arbeitet seit 2003 in der IT-Branche. Unter anderem hat er sich mehrere Jahre mit Data Leakage Prevention bei einer Grossbank beschäftigt. Heute liegen seine Schwerpunkte neben klassischen Penetration Tests bei der Einführung und der Weiterentwicklung von IT-Security-Management-Prozessen. (ORCID 0000-0003-4575-4597)

Links

Ihr Blue Team braucht Unterstützung?

Unsere Spezialisten kontaktieren Sie gern!

×
Traffic-Analyse mit Windows-Boardmitteln

Traffic-Analyse mit Windows-Boardmitteln

Dominik Altermatt

Cisco WebEx Online Meeting Security

Cisco WebEx Online Meeting Security

Dominik Altermatt

SANS SEC503 Intrusion Detection In-Depth

SANS SEC503 Intrusion Detection In-Depth

Dominik Altermatt

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv