Red Team Assessments zielen darauf ab, die Sicherheit eines Unternehmens ganzheitlich zu überprüfen. Dies schließt so ziemlich alle TOM (technisch-organisatorische Maßnahmen) mit ein, inklusive Erkennung von Angriffen (Detection) und Reaktion auf Angriffe (Response). Wenn TOM nicht vorhanden sind, können diese auch nicht geprüft werden. Daher sind Red Team Engagements dann sinnvoll, wenn ein Unternehmen schon mehr als nur grundlegende Sicherheitsmaßnahmen oder zumindest dediziertes Sicherheitspersonal (Blue Team, SOC, Security Administrators, Security Operations…) im Betrieb hat. Zumindest sollte bereits ein Penetrationstest auf die eigene Infrastruktur, sowohl von außen (externer Penetrationstest) wie auch von innen (interner Penetrationstest) durchgeführt worden sein.
Ein Red Team Assessment besteht üblicherweise aus den folgenden Phasen:
- Vorbereitungsphase
- Festlegen von Testzielen (Critical Functions und Critical Assets)
- Erstellen eines Testplans, erlaubter Vorgehensweisen und nicht erlaubter Taktiken/Techniken (TTPs)
- Testphase (orientiert sich grob an der sogenannten „Cyber Kill Chain“ und MITRE ATT&CK)
- Informationsbeschaffung über das Ziel (bestehend aus Target Intelligence via OSINT/WEBINT/GEOINT/SOCMINT usw., Footprinting, Attack Surface Mapping, FIngerprinting, Scanning und manuellen Analysen)
- Vorbereitung & Weaponization (Aufsetzen der Infrastruktur, Vorbereitung von Malware, Erstellen von Social Engineering-Skripten, Kreieren von Phishing-Szenarien, usw.)
- Durchbruch von außen (auf verschiedenen Wegen: Ausnutzen von externen Schwachstellen, Social Engineering, physischer Einbruch, Phishing, Malware…)
- Persistenz & C2: Permanentes Einnisten im Zielnetz und Aufbau von Kommunikationskanälen
- Lateral Movement & Privilege Escalation: Ausbreiten im Zielnetz und Erhöhen der Rechte
- Objective Achievement: Zugriff auf Critical Functions oder Critical Assets
- Abschluss- und Nachbereitungsphase
- Erstellen eines ausführlichen Berichts mit allen Funden, Sicherheitsproblemen, umfangreichen Empfehlungen zur Behebung
- Auf Kundenwunsch: Wiederholung einzelner Angriffsschritte oder Purple Team Workshop
- Beratung & Abschlussgespräche
NSIDE hat bereits ausführliche Erfahrungen mit der Amazon-Cloud (Amazon AWS) sowie der Microsoft-Cloud (Microsoft Azure) gesammelt. Hier haben wir bereits komplizierte Setups geprüft, die viel auf cloud-nativen Mechanismen und Diensten aufbauen. Auch in anderen Clouds haben wir bereits Sicherheitstests durchgeführt.
NSIDE zählt Unternehmen aus allen Branchen der Wirtschaft sowie der öffentlichen Hand zu ihren Kunden. Einige Beispiele für Branchen, mit denen wir regelmäßig Projekte durchführen:
- Energieerzeuger und Versorgung
- Finanzen, Banken und Versicherungen
- Industrie, fertigendes Gewerbe und Maschinenbau
- IT
- Telekommunikation & ISPs
- Strafverfolgungsbehörden
- Universitäten und Fachhochschulen
- Öffentliche Verwaltungen (Städte, Landkreise)
- Dienstleistung
- Chemie
- Medien (Print, Fernsehen und Online)
- uvm.
Wir freuen uns, somit einen Beitrag zur Sicherheit in nahezu allen Sektoren Deutschlands leisten zu können.
Schwachstellenscans sind dann geeignet, wenn man eine große Zahl von Systemen möglichst schnell auf sehr grundlegende oder einfach zu findende Schwachstellen überprüfen möchte. Ein Schwachstellenscan ist dann ein geeignetes Mittel, wenn Geschwindigkeit, Effizienz oder Automatisierung gewünscht sind. Wenn hingegen ein Prüfobjekt (egal ob ein einzelnes System, eine Anwendung, eine Umgebung oder ein ganzes Netzwerk) eingehend auf Sicherheitsprobleme geprüft werden soll, sind Vulnerability Scans meist nicht ausreichend. Automatische Schwachstellenscans übersehen leider viele Schwachstellen.
Grundsätzlich gesagt: nein. Für manche Einsatzzwecke mag ein automatisierter Penetrationstest gut funktionieren, es stimmt auch dass manche Aspekte sogar effizienter und gründlicher von automatisierten Werkzeugen erledigt werden können wir empfehlen den Einsatz von automatisierten Vorgehensweisen auch in manchen Situationen. Aber generell wird die Qualität eines (gut ausgeführten) manuellen Penetrationstests immer höher sein, als die eines automatisierten. Der Grund ist eigentlich simpel: Sicherheitslücken entstehen durch Situationen die ein Architekt/Entwickler des Systems nicht vorhergesehen hat wie soll ein automatisiertes Werkzeug diese nun plötzlich erahnen können? Nicht umsonst ist, ähnlich zu Software-Entwicklung, ein Penetrationstest ein kreativer Prozess. Wie gut hat das Automatisieren von kreativen Prozessen Ihrer Erfahrung nach bisher funktioniert?
Aus eigener Erfahrung sollten keine Red Team Tests mit einer Dauer von weniger als 40 Personentagen durchgeführt werden, um sinnvolle Erkenntnisse und Ergebnisse generieren zu können. Laut TIBER-Rahmenwerk für Ethical Red Teaming sollte für die Testphase eines Red Team Engagements mit circa 16 bis 18 Wochen gerechnet werden, wobei ca. 4 bis 6 auf Intelligence und 12 auf Red Teaming entfallen sollten. Dies entspricht ca. 20 bis 30 Personentagen für Intelligence und ca. 60 Personentagen für Red Teaming. NSIDE versucht, diese Vorgaben auf den jeweiligen Kunden anzupassen und so effizient wie möglich zu arbeiten. Dennoch sollten diese Werte nicht zu stark unterschritten werden.
Es kommt darauf an, was das Ziel ist. Möchte ich alle Sicherheitsmaßnahmen meiner Organisation ganzheitlich einer möglichst realistischen Probe aufs Exempel unterziehen? Möchte ich herausfinden, welche Risiken durch Angriffe wirklich für mein Unternehmen bestehen, ob und wie Angreifer an meine wichtigsten Daten und Systeme gelangen könnten? Dann sollte man sich für ein Red Team Assessment entscheiden. Möchte ich hingegen meine Verteidigungsmaßnahmen und mein Blue Team (oder SOC oder Administratoren) so schnell wie möglich in einer kollaborativen, offenen Übung so weit wie möglich stärken und trainieren? Sollen die eigenen Verteidigungsmaßnahmen so schnell wie möglich ausgebaut und Blind Spots entdeckt werden? Dann sollte ich für meine Organisation ein Purple Team-Projekt durchführen lassen.
Unsere Mitarbeiter haben eine Vielzahl verschiedener Zertifizierungen im Bereich IT-Sicherheit erlangt. Hierzu gehören zum Beispiel, aber nicht nur, folgende:
- OSCP (Offensive Security Certified Professional)
- OSWE (Offensive Security Web Expert)
- OSWP (Offensive Security Wireless Professional)
Penetrationstests sind unter folgenden Umständen sinnvoll:
Ich möchte eine verlässliche Aussage über die technische Sicherheit eines oder mehrerer technischer Systeme, einer Anwendung (Web-Anwendung, Mobile App o.ä.), einer technischen Umgebung oder eines ganzen Netzwerkes erlangen.
Ich möchte eine möglichst vollständige Liste aller technischen Schwachstellen im Prüfobjekt (eines oder mehrere technische Systeme, Anwendung (Web-Anwendung, Mobile App o.ä.), technische Umgebung, ganzes Netzwerk) erhalten, um danach so viele wie möglich schließen zu können.
Ich möchte technische Sicherheitsrisiken so stark und vollständig wie möglich reduzieren.
Ich möchte ein System, eine Anwendung, eine Umgebung oder ein Netzwerk gegen Hackerangriffe absichern.
Ich möchte meine Daten oder meine Systeme gegen unbefugte Zugriffe schützen und diesen Schutz einem praktischen Test unterziehen.
Ein bereits in der Vergangenheit durch einen Penetrationstest überprüftes System wurde signifikant geändert oder weiterentwickelt.
Ein bereits in der Vergangenheit durch einen Penetrationstest überprüftes System wurde sehr lange nicht mehr geprüft.
Offensive Cyber Security ist ein Begriff in der IT-Sicherheit, der beschreibt, dass man diese betreffend die Angreifersicht einnimmt. NSIDE ist der festen Überzeugung, dass nur dadurch wirkliche Sicherheit erreicht werden kann. Kenntnis über die Angreifer und ihre Methoden ist essenziell, um IT-Sicherheit wirklich effektiv gestalten zu können.
Penetrationstests sind manuelle Sicherheitstests mit menschlicher Intelligenz, während Schwachstellenscans (Vulnerability Scans) vollständig automatisiert sind. Schwachstellenscans haben mehrere signifikante Nachteile gegenüber Penetrationstests. Die wichtigsten Nachteile sind, dass Schwachstellenscans nur solche Sicherheitsprobleme finden, die leicht zu entdecken sind und die in ihrer Erscheinung nicht stark von anderen, bereits bekannten Schwachstellen abweichen. Somit können Schwachstellenscanner oft nur zuvor publik gemachte Schwachstellen (somit mit CVE-Nummer) finden. Insgesamt kann man sagen, dass Penetrationstests effektiver sind und mehr Schwachstellen finden, während Schwachstellenscans effizienter und schneller sind. Im Gegensatz zu Vulnerability Scans finden Penetrationstests auch solche Schwachstellen, die Verständnis des Prüfobjekts und Kreativität oder Intelligenz erfordern. Wir empfehlen Vulnerability Scans dann, wenn sehr viele Prüfobjekte in kurzer Zeit gescannt werden müssen. Für tiefe Tests eines Prüfobjekts sind sie nicht gut geeignet. Schwachstellenscans können außerdem als regelmäßige Maßnahme (z.B. einmal monatlich) die eigene Sicherheit stärken und nachverfolgen, sind aber kein Ersatz für Penetrationstests.
Aspekt | Red Team Exercise | Penetrationstest |
Testgegenstand | Organisation oder Organisationseinheit | Technische Systeme, Anwendungen, Umgebungen, Infrastrukturen |
Dimensionen | Ganzheitlich: Technisch, menschlich, organisatorisch | Technisch |
Perspektivischer Fokus | Strategisch und taktisch, teils technisch-operativ | Technisch-operativ, teils strategisch und taktisch |
Testziel | Beantwortung der Frage: Können Angreifer an meine „Kronjuwelen“ (Critical Assets) gelangen oder Kontrolle über meine wichtigsten Systeme oder Geschäftsprozesse (Critical Functions) erlangen? Wenn ja, wie? Wie sind meine Erkennungs- und Gegenmaßnahmen? | Aufspüren möglichst vieler technischer Schwachstellen |
Aussagen & Fragestellungen | Wie sicher ist mein Unternehmen als Ganzes? Welche Schwachstellen habe ich, die Angreifer zu Critical Assets und Critical Functions verhelfen? Wie gut sind meine Response-Prozesse? Wie gut kann ich Angriffe proaktiv blockieren? Wie gut kann ich Angriffe erkennen und auf diese reagieren? | Wie sicher ist das Prüfobjekt und welche Schwachstellen existieren darin? |
Erkenntnisgewinn | Welche wichtigsten technischen, menschlichen, organisatorischen/prozessualen Schwachstellen hat meine Organisation? Wie gut ist meine Verteidigung aufgestellt? Was sind die Risiken für mein Business als Ganzes? | Welche Risiken ergeben sich für das Prüfobjekt, die darauf gespeicherten Daten und dessen Nutzer? Was genau sind die Schwachstellen und wie kann ich sie beheben? |
Vollständigkeit | Wichtigste Schwachstellen der Organisation im Bereich Technik, Prozesse/Organisation und Menschen | Möglichst vollständig, Aufdeckung so vieler technischer Schwachstellen im Prüfobjekt wie möglich |
Empfehlungen & Ergebnisse | Eliminierung von Blind Spots in der Erkennung, Behebung von Schwachstellen in den drei Dimensionen (technisch/prozessual-organisatorisch/menschlich), Stärkung der Reaktion auf Angriffe gegen die Organisation, Verbesserung der proaktiven und präventiven Maßnahmen für die Unternehmenssicherheit, allgemeine Stärkung der Abwehr von Angriffen (Cyber Resilience & Posture), Verbesserung von Prozessen, Richtungsweiser für Sicherheitsstrategie, Risikoeinschätzung | Absicherung des Prüfobjekts gegen Hackerangriffe und technische Risiken, Empfehlungen & Anleitungen zur Behebung der Schwachstellen |
Angreifermodell | Professionelle menschliche Angreifer mit bösartigen Absichten gegen meine eigene Organisation | Beliebige Angreifer |
Eingeweihte auf Kundenseite | Nur ein oder zwei Schlüsselpersonen, sonst niemand | Projekt- und Systemverantwortliche, keine besonderen Beschränkungen |
Einer unserer Mitarbeiter war im Gewinner-Team (1. Platz) der German Cyber Security Challenge (GCSC) 2016. Ein weiterer unserer Mitarbeiter belegte im Jahr 2015 den 1. Platz des CAST-Förderpreises für IT-Sicherheit des Center for Applied Security Technology (CAST).
Bei NSIDE kommt eine Mischung aus öffentlich verfügbaren Tools (Open Source Tools), kommerziellen Tools sowie Eigenentwicklungen zum Einsatz. Welche Tools genau verwendet werden, hängt vom konkreten Projekt ab. Die Menge an Tools beträgt jedoch viele Dutzend.
Für Phishing-Simulationen verwendet NSIDE ein selbst entwickeltes Framework. Dieses erlaubt es uns, Phishings unter Wahrung aller datenschutzrechtlichen Bestimmungen durchzuführen, indem es Nutzerverhalten nur anonymisiert verfolgt und anonyme Statistiken erstellt. Es erlaubt uns außerdem, neue Phishing-Szenarien und Cover Stories zu entwickeln und schnell einzusetzen.
Die Berichte der NSIDE bestehen immer aus folgenden 4 Teilen:
- Management Summary: Zusammenfassung und Erklärung aller Ergebnisse für eine nicht-technische Zielgruppe, inkl. grafischer Auswertung, textueller Beschreibung der Befunde in einfacher Sprache und strategischer Empfehlungen
- Befundtabelle (Schwachstellentabelle): Auflistung aller gefundenen Sicherheitsprobleme, ihrer Ursachen, ihrer Auswirkungen sowie detaillierter Empfehlungen zur Behebung.
- Testdetails: Liste ausgeführter Tests (Prüfprotokoll) sowie der Prüfergebnisse. Hiermit kann nachvollzogen werden, welche Einzelprüfungen genau durchgeführt wurden.
- Anhang (Appendix): Testmodalitäten, Risikobewertungsskala und alles, was nicht in die anderen Teile passt.