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ührung beschrieben. Diese soll sicherstellen, dass Red Teaming Projekte vergleichbar und EU-weit anerkannt werden können, sowie die Möglichkeit Lessons 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:

• Die Cyber-Resilienz von Finanz-Unternehmen und des Finanzsektors im Allgemeinen zu verbessern
• Die Standardisierung und Harmonisierung von Red Teaming Projekten bei Finanz Unternehmen in der gesamten EU, während gleichzeitig jeder Gerichtsbarkeit ein gewisses Mass an Flexibilität eingeräumt wird

Was ist “Threat Intelligence Based Red Teaming”?

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

• Ausdruck der Absicht, Schaden anzurichten, zu berauben, zu schwächen, zu beschädigen oder zu zerstören
• Hinweis auf einen unmittelbar bevorstehenden Schaden
• Mittel, das als schädlich angesehen wird
• Handlungen eines schädlichen Akteurs

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:

• Die technischen Einzelheiten des Angriffs (Indikatoren für eine Kompromittierung oder das Was, Wann und Wo)
• Die hinter dem Angriff stehenden TTPs (das Wie)
• Die Einzelheiten der Angreifer selbst und ihre Beweggründe (das Wer und Warum)

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.

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:

• Für jeden Test wird ein TCT und WT sowie ein Start-Meeting benötigt
• Koordination mit dem TIBER-EU TCT
• Das Drei-Phasen Vorgehen
• Der Test dürfen nur im Wissen einer kleiner ausgewählten Gruppe (WT, TCT, RT und TI) durchgeführt werden
• Tests müssen auf produktiven Systemen durchgeführt werden
• Das WT muss ein Risiko-Management für ein sicheren und kontrollierten Test etablieren
• Für jegliche Kommunikation und Dokumentation muss einen Codenamen für die Ziel-Organisation verwendet werden, um dessen Identität zu schützen

TIBER-EU Empfehlungen:

• Der freie Fluss von Information zwischen den Stakeholder ist essentiell für das gute Gelingen. Entsprechend sollten Barrieren z.B. mit NDAs abgebaut werden
• Die Ziel-Organisation sollte im Risiko-Management verschiedene Aspekte beachten
  • Gute Planung und Verfügbarkeit entsprechender Key Stakeholder
  • Verschlüsselte Kommunikation/ Datenaustausch
  • Funktionierendes Backup/Restore-Konzept für involvierte Komponente
  • Gut funktionierende Eskalation-Prozesse während der Test-Phase, respektive Zugriff auf Personal mit Entscheidungsbefugnissen
• National Nachrichtendienste, Cybersecurity-Stellen oder kriminalistische Einheiten können für TI-Input herangezogen werden

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.

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:

• TI & RT Provider müssen mit soliden Verträgen gebunden werden
• TI & RT müssen unabhängige Provider sein und minimalen Anforderungen erfüllen
  • Referenz-Projekte (TI: 3 Stück, RT: 5 Stück) müssen durch die Provider vorgelegt werden
  • Angemessene Haftpflichtversicherung, die Aktivitäten abdeckt, die nicht im Vertrag vereinbart wurden und/oder die auf Fehlverhalten, Fahrlässigkeit zurückzuführen sind
  • TI/RT Teams müssen aus einem Manager und Mitgliedern bestehen
  • Manager
    • Mindestens fünf Jahre TI/RT Erfahrung inkl. Reporting
    • Mindestens drei Jahre Erfahrung im Finanz-Sektor
    • Background Check und aktuelles CV mit den letzten drei Referenzen
  • Mitglieder
    • Mindestens zwei Jahre TI/RT Erfahrung
    • Background Check und aktuelles CV
    • Multidisziplinäre Zusammensetzung der Teams

TIBER-EU Empfehlungen:

• Provider sollen exzellente Reputation, solide ethischen Standards und eine einwandfreie Vergangenheit aufweisen
• Provider sollen eine robuste Methodologie für ihre Aktivitäten aufweisen, welche sie vorab glaubhaft darstellen können. Z.B. mit der der Fähigkeit Nation-State Actors zu imitieren zu können
• Provider sollen nachvollziehbar ihr Risiko-Management im Umgang mit sensitiven Daten vorab darstellen können. Daher sollen z.B. ein eigenes ISMS nach z.B. ISO 27001 oder NIST betreiben werden, was mit entsprechenden Beweisen belegt werden soll
• Die Firmenkultur der Provider soll Forschung und Entwicklung (R&D) beinhalten, respektive entsprechende Kapazitäten sollen vorhanden sein
• Einsatzregeln sollen mit den Providern klar definiert werden
• Idealerweise, können die TI/RT Manager und Mitglieder entsprechende Zertifikationen vorweisen:
  • Manager: Zum Beispiel: CCTIM oder OSCE
  • Mitglieder: Zum Beispiel: CCSAS oder OSCP

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:

• Das TIBER-EU Scoping Specification Template muss verwendet werden
• CFs und ihre unterstützenden Komponenten sowie entsprechende Flags müssen definiert sein
• Der Scope muss durch das TCT und das Board-Level der Ziel-Organisation abgenommen werden
• Die Flags müssen durch das WT und TCT abgenommen werden

TIBER-EU Empfehlungen:

• Wenn nötig, können während der Test-Phase der Scope sowie die Flags angepasst werden
• TI und RT Provider können bereits in den Scoping Prozess miteinbezogen werden
• Auch nicht-produktive Systeme können in den Scope aufgenommen werden
• In einem entsprechenden Workshop sollten alle Details des Scopes den TI/RT Provider erklärt und wenn nötig weiter ergänzt werden

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:

• Target Identifikation: Erlangen von Erkenntnissen über potenzielle Angriffsflächen in der gesamten Ziel-Organisation
• Threat Identifikation: Erlangen von Erkenntnissen über relevante Bedrohungsakteure und wahrscheinliche Bedrohungsszenarien

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:

• Die Produktion eines TTI-Report
• Mehrere Angriffs-Szenarien müssen erarbeitet werden

TIBER-EU Empfehlungen:

• Ziel-Organisationen sollten möglichst viele Informationen (Technische Übersichten von jeder CF, Threat-Register, Beispiele von aktuellen Angriffen) dem TI zur Verfügung stellen. Dazu existiert ein entsprechendes TIBER-EU Template namens Input for the Targeted Threat Intelligence.

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:

• Angriffe müssen basierend auf den von TI beschrieben Szenarien durchgeführt werden. Alle Phasen der Entsprechenden Kill-Chain müssen durchgeführt werden.
• Wenn nötigt, muss dem RT mit einem Leg-up geholfen werden. Falls eine Phase der Kill-Chain nicht zeitgereicht erledigt werden kann, soll mit der Hilfe der Ziel-Organisation den Zugriff auf das “nächste” System gewährt werden
• Das RT informiert das WT und TCT über alle Aktivitäten auf einer Schritt-für-Schritt Basis
• Die Dauer des RT-Test muss entsprechenden auf das Scoping massgeschneidert werden, damit aussagekräftige Resultate erarbeitet werden können
• Die Befunde und deren Root-Causes, Kritikalität und Empfehlungen müssen in einem Report nachvollziehbar und detailliert dokumentiert werden
• Alle Artefakte, welche durch das RT auf Ziel-Systemen “übrig” gelassen wurden, müssen dokumentiert werden
• Entsprechende Log-Files und Beweise der RT-Aktivitäten müssen dokumentiert werden
• Der Draft RT-Report muss zwei Wochen nach Abschluss der RT-Aktivitäten geliefert werden

TIBER-EU Empfehlungen:

• Die Nutzung von physischen Aktivitäten, zum Beispiel die Platzierung von Rouge-Devices, kann in Betracht gezogen werden
• Die Dauer der RT Test Phase liegt erfahrungsgemäss bei 10 bis 12 Wochen

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:

• Das BT muss den RT-Report erhalten und ein BT-Report mit geeigneten Gegenmassnahmen erstellen
• In einem entsprechenden Workshop wiederholen RT, BT und WT gewisse RT-Aktionen, um diese besser zu verstehen und live nachverfolgen zu können
• Abschluss-Reports und -Meetings, Zusammenfassungen sowie entsprechende Attestierungen durch TI und RT müssen erledigt werden

TIBER-EU Empfehlungen:

• TCT sind idealweise auch Teil des Workshops
• Über die Workshops hinaus können Purple-Team Aktivitäten mit RT und BT angestrebt werden

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 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

• https://attack.mitre.org/
• https://crest-approved.org/examination/crest-certified-threat-intelligence-manager/index.html
• https://www.crest-approved.org/examination/certified-simulated-attack-specialist/index.html
• https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
• https://www.iso.org/isoiec-27001-information-security.html
• https://www.nist.gov/cyberframework
• https://www.offensive-security.com/offsec/retiring-ctp-intro-new-courses/
• https://www.offensive-security.com/pwk-oscp/
• https://www.pcisecuritystandards.org/