scip Monthly Security Summary Ausgabe November 2024

Ich möchte ein Red Teaming: Wieso Terminologie entscheidend ist

bear in wild long shot

Editorial

November 2024: Wenn die Bären los sind

Vielleicht ist es Ihnen aufgefallen, dass wir in unseren Teams mit verschiedenen Symbolen arbeiten, um unsere Tätigkeiten bei der scip AG zu beschreiben. Im Red Team beispielsweise ziert der Bär das Logo unserer Offensiv-Kraft. Bären sind erstaunliche Wesen: Sie sind sehr agil für ihre Grösse, sind Allesfresser, anpassungsfähig und richtige Überlebenskünstler, da sie sich ihren natürlichen Bedingungen problemlos anpassen können. Bären kennzeichnen sich dadurch aus, dass sie sehr friedlich sind, solange sie nicht einer Bedrohung ausgesetzt sind. Aggressive Verhaltensreaktionen zeigen sie nur, wenn sie glauben, sich in Gefahr zu befinden. Michael Schneider hat in seinem November-Beitrag nicht etwa über Bären selbst geschrieben, sondern ist auf das Thema Terminologie eingegangen. Dabei spricht Michael beispielsweise davon, auf welche Herausforderungen man stösst, wenn man Angriffstechniken unterschiedlich definiert. Im Spezifischen zeigt er auf, wie wir Red Teamings determinieren, und wie sich solche Assessments grundsätzlich von einem Pentest oder Review unterscheiden.

Ein Red-Teaming hat irgendwie schon Gemeinsamkeiten mit einem Bären: Das Team muss sich seiner Umgebung stets anpassen, sich agil fortbewegen, und wie ein Allesfresser auch mit allen mögichen Tools und Techniken arbeiten können. Ein Take-Away ist besonders wichtig: Dass man gemeinsam das richtige Training defniert, damit aussagekräftige Erkenntnisse gewonnen werden, und somit die Abwehr- und Detektionsfähigkeit von Unternehmen effektiv verbessert wird. Wir wünschen Ihnen einen bärenstarken Monat und viel Spass beim Lesen unseres monatlichen Newsletters!

Serena Bolt, Business Analystin

News

Das ist bei uns passiert

Vorlesung an der HWZ

Marisa Tschopp durfte letzte Woche an der Hochschule für Wirtschaft in Zürich am CAS Women Leading Digital unterrichten. Kern der Vorlesung war das Thema Conversational Agents und Companion AIs, wie diese im Alltag eingesetzt werden und wie eine mögliche Zusammenarbeit mit solchen Agenten aussehen könnte. Tschopp gab den Teilnehmenden dabei einen Einblick in ihre aktuelle Forschung: Gegenstand der Untersuchung ist, wie Menschen Conversational Agents (CA’s) wahrnehmen, und wie diese Wahrnehmung das menschliche Verhalten beeinflusst.

Betrug via Booking-Chat

Marc Ruef konnte zu den aktuellen Betrugsversuchen via Booking-Chat seine Einschätzung in einem Artikel auf 20 Minuten teilen. Derzeit kursiert eine perfide Betrugsmasche von Kriminellen, die über die Chatfunktion von Booking Kreditkarteninformationen von Nutzern erschleichen wollen. Ruef sagt dabei, das Booking wenig Möglichkeiten zur Behebung hat, sofern die Schwachstelle direkt von den Hotels, und nicht von Booking selber ausgeht. Falls man betroffen sein sollte rät Ruef, die Kreditkartenfirma und Behörden direkt zu kontaktieren. Ausserdem hilft es, stets kritisch zu bleiben, falls mit einer plötzlichen Stornierung gedroht wird.

Grosse KI-Reportage im Sonntagsblick

In der gestrigen Ausgabe des Sonntagsblicks wurde ein KI-Beitrag mit Marisa Tschopp veröffentlicht. Tschopp teilte ihre Expertise mit Journalist Dennis Baumann, der sich an ein KI-Selbstexperiment gewagt hat und ein älterer Bruder hat generieren lassen. Einige Learnings, zum Beispiel dass Chatbots eigene Konversationen vergessen, keine Mundart-Kenntnisse aufweisen oder kein wirklicher Ersatz für menschliche Interaktionen sind, werden von Tschopp kommentiert. Tschopp, die die Beziehung zwischen Mensch und Maschine erforscht, stellt indes die Frage, ob man sich überhaupt eine KI in unserem Sozialleben wünscht. Obwohl die Interkation mit sogenannten AI-Companions noch ausbaufähig ist, können sie dennoch künftig zu einem potenziellen Suchtverhalten führen. Deswegen sei eine frühzeitige kritische Auseinandersetzung mit KI unerlässlich, denn auch KI-Bots sind eine Flucht aus der Realität, so Marisa. Der Blick-Artikel ist als zweiteilige Serie hier und hier online einsehbar.

Fachartikel

Aktuelle Erkenntnisse

Patrick Thomas, Security Partner bei Netflix, schrieb im November 2016 in einem Twitter-Post über die überladene Definition des Begriffs Penetration Test und zeigte in einer Grafik, warum der Ausgangspunkt eines Sicherheitstests eine Diskussion zwischen Kunde und Tester über das Ziel sein sollte. Einige Jahre später ist das Thema immer noch aktuell, aber der Begriff hat sich in “Red Teaming” geändert.

Was "Ich möchte einen Pentest" alles bedeuten kann

Das Konzept des Red und Blue Teaming entstand in den 1960er Jahren und eines der ersten Beispiele war der Think Tank RAND Corporation, der während des Kalten Krieges Simulationen für das US-Militär durchführte. In der Informationssicherheit bezeichnet Red Teaming die Überprüfung der Sicherheit einer Organisation durch den Versuch, ihre IT-Infrastruktur zu infiltrieren.

In der Ausgangsdiskussion wird geklärt, welche Bedürfnisse der Kunde hat, über welche Maturität sein Abwehrdispositiv verfügt und ob der Kunde wirklich alle Phasen und Besonderheiten eines Red Team Assessments benötigt. Um dies herausfinden zu können, müssen zunächst die Grundbegriffe geklärt und die möglichen Dienstleistungen und Vorgehensweisen definiert werden.

Definition von Sicherheitstests

Es gibt keine einheitliche Definition für Sicherheitstests, die Bezeichnungen und Leistungen unterscheiden sich von Dienstleister zu Dienstleister. Der Name einer solchen Prüfung ist aus technischer Sicht zweitrangig. Wichtig ist, was ein solcher Test beinhaltet, wie sie durchgeführt wird und welche Voraussetzungen erfüllt sein müssen.

Wir unterscheiden drei Arten von Sicherheitstests:

  • Review
  • Penetration Test
  • Assessment

Bei einem Review wird ein Testziel anhand von Dokumentation, Interviews und lesendem Zugriff auf das Zielobjekt beurteilt. Ebenso kann die Auswertung bereits vorhandenen Berichten wie zum Beispiel eines Vulnerability Scans oder eines Baseline-Audits in den Review einfliessen. Reviews umfassen die Überprüfung der Architektur einer Lösung, die Konfiguration von Komponenten oder auch des Source Codes. Ein Review wird in der Regel gemeinsam mit Fachexperten durchgeführt und alle Informationen werden den Testern zur Verfügung gestellt.

Ein Penetration Test überprüft ein spezifisches Testziel anhand eines definierten Scopes. Dazu können Testing Guides oder Checklisten verwendet werden. Bei einem Penetration Test dokumentieren wir, was wir geprüft haben und führen im Bericht auch auf, bei welchen Tests keine Schwachstellen gefunden wurden (Einstufung Passed). Mit einem Penetration Test können unter anderem Web- oder Mobile-Applikationen überprüft werden. Ein Penetration Test umfasst aber auch die Überprüfung eines Laptops oder die Durchführung einer Phishing-Übung.

Sollen mehrere Komponenten oder eine Infrastruktur mit offenem Scope überprüft werden, sprechen wir von einem Assessment. Dabei können einzelne Schwachstellen zu Angriffspfaden zusammengefasst werden, um die Ausnutzung der Schwachstellen und dessen Auswirkung zu demonstrieren. Der Report umfasst die Dokumentation des Angriffspfads und den Schwachstellen anstelle einer Checkliste. Assessments umfassen die Überprüfung der Baseline Security, die Durchführung von Angriffssimulationen sowie Red und Purple Team Assessments.

Die Testarten können kombiniert werden, wenn zum Beispiel eine Web-Applikation nach OWASP Application Security Verification Standard (ASVS) Level 2 (L2) oder Level 3 (L3) geprüft werden soll, kann dies nicht mit einem Penetration Test abgedeckt werden. Für L2 und L3 ist der Zugriff zu Dokumentation, Source Code, Konfiguration und Interviews mit dem Entwicklungsteam erforderlich.

Assessments

Wenn ein Kunde ein “Red Teaming” wünscht, soll in der Regel die IT-Infrastruktur seiner Organisation überprüft oder ein spezifisches Szenario innerhalb der Infrastruktur durchgeführt werden. Im Artikel Security Testing – Von der Hypothese zum Experiment hat Tomaso Vasella bereits Unterschiede zwischen einem Penetration Test und einem Red Team Assessment aufgezeigt.

In der Phase Pre-Engagement geht es darum, im Gespräch mit dem Kunden herauszufinden, welche Form des Assessments für seine Bedürfnisse am besten geeignet ist.

Wir unterscheiden diese vier Formen von Assessments:

  • Baseline Security Assessment
  • Attack Simulation Assessment
  • Red Team Assessment
  • Purple Team Assessment

Unterschiede

Die Assessments unterscheiden hinsichtlich der Vorgehensweise der Angreifer, der Interaktion mit den Mitarbeitern des Kunden und der Maturität der Verteidiger. Die Tabelle gibt einen Überblick über die wichtigsten Unterschiede:

Baseline Security Assessment Attack Simulation Assessment Red Team Assessment Purple Team Assessment
Ziel, Vorgehen Durchführung von automatisierten Scans externer/interner Ziele und manueller Verifikation, mit oder ohne Begleitung der IT/Security Simulation von Angriffspfaden in Begleitung der IT/Security Angriff auf die Infrastruktur, nur Schlüsselpersonen sind informiert Angriffstechniken/-szenarien werden nacheinander ausgeführt und Detektion gemessen in Zusammenarbeit mit SOC
Länge (abhängig vom Szenario) 5-10 Tage 10-20 Tage 30-60 Tage 15-30 Tage
Maturität Geeignet für tiefe Maturität in Resilienz und Erkennungsfähigkeiten Geeignet für tiefe bis hohe Maturität in Resilienz und Erkennungsfähigkeiten Hohe Maturität in Resilienz und Erkennungsfähigkeiten erforderlich Mittlere bis hohe Maturität in Erkennungsfähigkeiten erforderlich
Stealth Kein Fokus auf Stealth Stealth je nach Maturität und zur Verfügung stehender Zeit Fokus auf Stealth Abhängig von Detektionsfähigkeit
Tools / Schwachstellenerkennung Einsatz von Open Source Tools, automatisierte und manuelle Tests zur Schwachstellenerkennung Einsatz von Open Source Tools, automatisierte und manuelle Tests Identifikation von Angriffspfaden Einsatz von angepassten Open Source Tools, Eigenentwicklungen, Identifikation von Schwachstellen für Angriffspfad zur Zielerreichung Einsatz von Open Source Tools, abgesprochene Angriffsziele und Use Cases
Detektion Keine Messung/Protokollierung zur Detektion Erstellung eines Angriffsprotokoll, das nach Assessment an SOC übergeben wird Erstellung eines Angriffsprotokoll, das nach Assessment an SOC übergeben wird Jedes Angriffsszenario wird gemessen, detaillierte Auswertung
Access Je nach Ziel wird der Zugriff zur Verfügung gestellt Initialer Zugriff wird zur Verfügung gestellt Je nach Szenario kein Zugriff oder Zugriff mit niedrigen Berechtigungen Zugriff anhand der Use Cases

Grundsätzlich halten wir ein Red Team Assessment für Kunden ohne Security Operation Center (SOC) und ohne Angriffserkennungsfähigkeiten nicht für angemessen, da ein wesentlicher Teil des Assessments darin besteht, unentdeckt zu bleiben und alle Operationen vorsichtig durchzuführen. Wenn keine Erkennungsfähigkeit vorhanden ist, sollte der Schwerpunkt nicht darauf liegen, möglichst unentdeckt zu bleiben, sondern der Aufwand sollte in die Suche nach Schwachstellen und Angriffspfaden investiert werden.

Möchte ein Kunde explizit verschiedene Komponenten seiner Infrastruktur überprüfen und beispielsweise Aussagen zur Resilienz des Clients, der VPN-Lösung und des IT-Ticket-Portals erhalten, empfehlen wir die Durchführung einer Attack Simulation auf diese Komponenten. Dabei werden diese auf Schwachstellen untersucht, die sich zu einem Angriffspfad kombinieren lassen und beispielsweise zur Kompromittierung eines Laptops und anschliessenden Lateral Movement im Netzwerk führen können. Bei einem Red Team Assessment hingegen suchen wir als Angreifer nach dem geeignetsten Angriffspfad, um unsere Ziele zu erreichen. Möglicherweise beinhaltet dieser Pfad keine der Komponenten, die der Kunde explizit überprüft haben möchte. Bei einem Red Team Assessment werden die Ziele vorgegeben, aber der Weg dorthin wird von den Angreifern bestimmt.

Das Budget für einen Sicherheitstest hat auch einen Einfluss auf die Wahl des Assessments. Es ist unrealistisch, innerhalb von 10 Tagen ein vollständiges Red Team Assessment durchzuführen. Je nach Reifegrad des Abwehrdispositivs empfiehlt es sich, bei einem Budget von 10 Tagen ein Baseline Security oder ein Attack Simulation Assessment durchzuführen. Beim Baseline Security Assessment ist der Fokus auf der Suche nach Schwachstellen, zum Beispiel durch die automatisierte Prüfung nach erreichbaren Freigaben oder eine Untersuchung nach den am häufigsten vorkommenden Fehlkonfiguration in Active Directory, Active Directory Certificate Services (ADCS) oder der Microsoft Cloud. Solange viele solcher leicht ausnutzbaren Schwachstellen in der Infrastruktur existieren, bringt ein verdeckter Ansatz oder die Entwicklung eigener Angriffswerkzeuge keinen Mehrwert. Wurden jedoch bereits mehrere Sicherheitstests in der Infrastruktur durchgeführt, bringt ein Red Team Assessment einen zusätzlichen Nutzen, da die Organisation auch auf ihre Detektionsfähigkeit und Reaktion auf Sicherheitsvorfälle geprüft werden kann.

Für das Auffinden und Ausnutzen von Schwachstellen werden das Attack Simulation und vor allem das Baseline Security Assessment mit automatisierten Prozessen und Open Source Tools durchgeführt. In einem Red Team Assessment werden speziell für den Einsatzzweck zugeschnittene Werkzeuge eingesetzt und Zeit aufgewendet, um Sicherheitstools umgehen zu können. Dazu kann die Kundenumgebung soweit als möglich und nötig in unserem Test-Lab simuliert werden.

Bei einem Purple Team Assessment wird explizit die Detektionsfähigkeit überprüft. Dazu werden im Vorfeld gemeinsam mit dem Kunden Use Cases erarbeitet und in Zusammenarbeit mit dem SOC abgearbeitet. Dabei durchläuft jeder Use Case einen Workflow, in dem gemessen wird, ob eine Angriffstechnik detektiert, nur aufgezeichnet respektive protokolliert, oder gar nicht erkannt wurde. Wenn eine Angriffstechnik aufgrund von Sicherheitsmassnahmen nicht ausgeführt werden kann, wird dies auch im Protokoll des Use Cases festgehalten. Ein Use Cases wird so lange wiederholt, bis eine Detektionsregel erstellt und erfolgreich getestet wurde beziehungsweise der gewünschte Zustand für den Use Case erreicht wurde.

Fazit

Um die Sicherheit der Infrastruktur einer Organisation zu überprüfen, gibt es verschiedene Vorgehensweisen. Je nach Ziel der Überprüfung und eigener Maturität in Bezug auf Resilienz und Detektionsfähigkeit ist ein Attack Simulation Assessment, ein Red Team Assessment oder ein Purple Team Assessment besser geeignet. Für die Durchführung eines “Red Teamings” ist die Pre-Engagement-Phase und somit das Bestimmen der Art des Assessments von entscheidender Bedeutung, um das für die Organisation geeignete Training zu definieren. Nur so können aussagekräftige Erkenntnisse gewonnen und somit die Abwehr- und Detektionsfähigkeiten verbessert werden.

Sind Sie bereit?

Unsere Spezialisten kontaktieren Sie gern!

Über den smSS

Das scip Monthly Security Summary erscheint monatlich und ist kostenlos.

  • Anmeldung: smss-subscribe@scip.ch
  • Abmeldung: smss-unsubscribe@scip.ch

Informationen zum Datenschutz.

Eine Haftung für die Richtigkeit der Veröffentlichungen kann trotz sorgfältiger Prüfung durch die Redaktion des Herausgebers, den Redaktoren und Autoren nicht übernommen werden. Die geltenden gesetzlichen und postalischen Bestimmungen bei Erwerb, Errichtung und Inbetriebnahme von elektronischen Geräten sowie Sende- und Empfangseinrichtungen sind zu beachten.

Über scip AG

Wir überzeugen durch unsere Leistungen. Die scip AG wurde im Jahr 2002 gegründet. Innovation, Nachhaltigkeit, Transparenz und Freude am Themengebiet sind unsere treibenden Faktoren. Dank der vollständigen Eigenfinanzierung sehen wir uns in der sehr komfortablen Lage, vollumfänglich herstellerunabhängig und neutral agieren zu können und setzen dies auch gewissenhaft um. Durch die Fokussierung auf den Bereich Information Security und die stetige Weiterbildung vermögen unsere Mitarbeiter mit hochspezialisiertem Expertenwissen aufzuwarten.

Immer auf dem neuesten Stand

Abonnieren Sie unser monatliches Magazin