Die Uhr läuft: Warum die Post-Quanten-Migration jetzt beginnen muss

Be liberal in what you accept – don’t trust anything. Das Thema Vertrauen in Netzwerken hat einen radikalen Wandel vollzogen. Wo es in den Anfangszeiten der modernen IT noch mit einer guten Portion Vertrauensvorschuss voranging, ist heute große Skepsis angebracht. Und mit Quantencomputern steht bereits der nächste Paradigmenwechsel bevor.

Vertrauen im Wandel – eine kurze Geschichte der Netzwerksicherheit

In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.” Diesen Satz formulierte Jon Postel in den Anfangstagen des Internets. Mit diesem Satz in seinem RFC 760 zum Internet-Protokoll im Jahr 1980 sollte er die Netzwerkentwicklung nachhaltig prägen. Nur ein Jahr später, im RFC 793 zur Spezifikation des TCP, erhob er diesen Gedanken explizit zum Robustheitsprinzip: „Be conservative in what you do, be liberal in what you accept from others.

Zum damaligen Zeitpunkt galt dies als pragmatische Ingenieursweisheit. Es entsprach dem Geist einer Zeit, in der das Netz eine überschaubare Gemeinschaft von Universitäten und Forschungseinrichtungen verband. Man kannte sich. Man vertraute sich. Und genau dieses Grundvertrauen wurde zum Fundament eines Netzwerks, das nie für das gebaut wurde, was es heute ist: Ein globales Netzwerk, wo die nächste Gefahr fürs eigene Netzwerksegment nur einen Hop entfernt ist.

Als das Internet in den 1990er-Jahren seinen Weg in Unternehmen fand, wurde schnell klar, dass Postels großzügiges Prinzip allein nicht ausreichen würde. Nicht jeder Teilnehmende im Netz hatte gute Absichten. Die Antwort der IT-Sicherheit folgte einer Logik, die so alt ist wie die Zivilisation selbst: Man baute eine Mauer. Das Modell des Perimeterschutzes war geboren – eine klare Grenze zwischen Innen und Außen. Firewalls filterten den Datenverkehr an den Toren. Was innerhalb der Mauern lag, galt als vertrauenswürdig. Postels Prinzip der Großzügigkeit lebte dort weiter – aber nur noch im geschützten Inneren.

Doch Mauern haben ein grundsätzliches Problem: Sie schützen nur, solange niemand sie überwindet. Wer einmal drinnen ist – ob berechtigt oder nicht – genießt volles Vertrauen. Und die Welt jenseits der Mauern wurde größer, feindseliger, unübersichtlicher.

Parallel dazu reiften kryptografische Verfahren heran, die eine fundamental andere Art von Vertrauen ermöglichten: nicht mehr Vertrauen durch Zugehörigkeit zu einem Netzwerk, sondern Vertrauen durch mathematisch überprüfbare Identität. SSL und sein Nachfolger TLS sicherten die Kommunikation zwischen Endpunkten. VPNs schufen verschlüsselte Tunnel zwischen perimetergeschützten Umgebungen über unsicheres Terrain. Public-Key-Infrastrukturen etablierten Vertrauensketten, die an keine physische Netzwerkgrenze gebunden waren. Was als Ergänzung zum Perimeterschutz begann, wurde zunehmend zu einer eigenständigen Sicherheitsschicht – und schließlich zu einer Alternative.

Nach der Jahrtausendwende formulierte John Kindervag bei Forrester Research im Jahr 2010 den konsequenten Schluss aus dieser Entwicklung: Zero Trust. Das Prinzip ist in seiner Radikalität bemerkenswert einfach: Vertraue niemandem. Verifiziere immer alles.  Kein Netzwerkstandort, keine IP-Adresse, keine Firewall-Regel gewährt Vertrauen – nur die kryptografisch gesicherte, kontinuierlich überprüfte Identität eines Akteurs und der Kontext seiner Anfrage.

Zero Trust ist damit nicht nur eine technische Architektur. Es ist die konsequente Umkehrung von Postels Erbe. Wo das Robustheitsprinzip noch sagte “Sei großzügig in dem, was du akzeptierst”, antwortet Zero Trust “Akzeptiere nichts, was sich nicht zweifelsfrei ausweisen kann”. Aus implizitem Vertrauen wurde explizite Verifikation. Was einst als Tugend galt – Offenheit, Toleranz gegenüber dem Unbekannten – wurde in einer feindlichen Umgebung zur Schwachstelle.

Die Geschichte der Netzwerksicherheit ist damit auch eine Geschichte darüber, wie sich der Begriff des Vertrauens selbst gewandelt hat: vom sozialen Grundkonsens einer akademischen Gemeinschaft über die territoriale Logik befestigter Grenzen hin zu einem System, in dem Vertrauen nicht vorausgesetzt, sondern in jedem einzelnen Moment mathematisch bewiesen werden muss. Postel entwarf sein Prinzip für eine Welt, in der guter Wille die Regel war. Zero Trust wurde für eine Welt gebaut, in der man sich diesen guten Willen nicht mehr leisten kann.

Die vier Bedrohungsachsen der Kryptografie

Heute ist die Netzwerksicherheit fundamental von der Sicherheit der eingesetzten kryptografischen Verfahren abhängig. Diese Verfahren sehen sich vier zentralen Bedrohungsachsen ausgesetzt:

  1. Kontinuierliche Steigerung der Rechenleistung – was heute als sicher parametrisiert gilt, kann morgen durch brute-force-fähige Hardware fallen.
  2. Protokoll- und Implementierungsfehler – von Heartbleed (CVE-2014-0160) über ROBOT (CVE-2017-17382, CVE-2017-6168) bis hin zu Timing-Seitenkanalangriffen. Die Lücke liegt oft nicht im Algorithmus, sondern im Code.
  3. Mathematische Fortschritte – neue analytische Methoden können die effektive Sicherheit eines Verfahrens über Nacht reduzieren, wie zuletzt die Diskussionen um Angriffe auf gitterbasierte Verfahren zeigten.
  4. Quantencomputer – ein kryptografisch relevanter Quantencomputer (CRQC) würde RSA, ECDSA und Diffie-Hellman mittels Shors Algorithmus in polynomialer Zeit brechen.

Die strategische Antwort auf diese Bedrohungen trägt einen Namen: Kryptoagilität – die architektonische Fähigkeit, kryptografische Verfahren in bestehenden Systemen zügig und ohne disruptive Umbaumaßnahmen austauschen zu können (vgl. Fraunhofer SIT: Kryptoagilität). Kryptoagilität ist keine Option mehr. Sie ist eine Überlebensfähigkeit.

Die Quantenbedrohung: Näher als viele glauben

Lange Zeit galt ein kryptografisch relevanter Quantencomputer (CRQC) als akademische Spekulation. Doch die Faktenlage hat sich verdichtet:

  • 2015 veröffentlichte Prof. Michele Mosca, Mitgründer des Institute for Quantum Computing an der University of Waterloo, eine vielbeachtete Risikoabschätzung: Die Wahrscheinlichkeit, dass die heute eingesetzte Public-Key-Kryptografie durch einen Quantencomputer gebrochen wird, liege bei ca. 14 % bis 2026 und bei 50 % bis 2031 (Mosca 2015, eprint.iacr.org/2015/1075).
  • 2016 rief das NIST den Standardisierungsprozess für Post-Quantum Cryptography (PQC) ins Leben. In der Begründung (NIST IR 8105) hieß es unmissverständlich: Ein CRQC könne innerhalb von ein bis zwei Jahrzehnten zur realen Bedrohung werden.
  • August 2024 veröffentlichte das NIST die finalen PQC-Standards: FIPS 203 (ML-KEM, basierend auf CRYSTALS-Kyber), FIPS 204 (ML-DSA, basierend auf CRYSTALS-Dilithium) und FIPS 205 (SLH-DSA, basierend auf SPHINCS+). Der Werkzeugkasten für die Post-Quanten-Ära existiert. Die Standards sind da.
  • 2025 und darüber hinaus setzt sich die Standardisierungsdynamik fort: Mit FIPS 206 (FN-DSA, basierend auf FALCON) steht ein weiterer NIST-Standard für digitale Signaturen kurz vor der Veröffentlichung – ein Verfahren, das insbesondere durch kompakte Signaturen bei gleichzeitig moderaten Schlüsselgrößen besticht. Parallel dazu treibt die ISO die Standardisierung zweier Verfahren voran, die bewusst auf konservativere – und damit besser verstandene – mathematische Grundlagen setzen: FrodoKEM, dessen Sicherheit auf dem allgemeinen Learning-with-Errors-Problem (LWE) ohne Gitterstruktur basiert, sowie Classic McEliece, ein codebasiertes Verfahren mit über 40 Jahren kryptoanalytischer Resistenz (vgl. BSI TR-02102-1, Kryptografische Verfahren: Empfehlungen und Schlüssellängen, Version 2026-01, Abschnitte 2.4.1 & 2.4.2). Damit zeichnet sich ein diversifiziertes PQC-Ökosystem ab – eines, das nicht von einer einzelnen mathematischen Annahme abhängt und der Forderung nach Kryptoagilität auch auf Verfahrensebene Rechnung trägt.

Ein bemerkenswertes Detail verdient besondere Aufmerksamkeit: Anders als bei der Kernfusion, die stets „in 50 Jahren“ einsatzbereit sein soll – egal, wann man fragt –, hat sich die Einschätzung der Krypto-Community zum Zeithorizont eines CRQC über das letzte Jahrzehnt nicht nach hinten verschoben. Die Prognosen konvergieren beständig auf den Zeitraum 2030 bis 2035. Das ist keine vage Zukunft. Das ist dieses Jahrzehnt.

Harvest Now, Decrypt Later – die Bedrohung von heute

Die Quantenbedrohung ist keine Zukunftsmusik – sie materialisiert sich bereits. Unter dem Paradigma „Harvest now, decrypt later“ (HNDL) werden heute verschlüsselt übertragene Daten von staatlichen Akteuren und nachrichtendienstlichen Einheiten systematisch abgefangen und gespeichert, um sie zu einem späteren Zeitpunkt mit einem CRQC zu entschlüsseln.

Betroffen sind alle Daten, deren Vertraulichkeit über den Zeitpunkt der Übertragung hinaus Bestand haben muss: Staatsgeheimnisse, medizinische Daten, Geschäftsgeheimnisse, Verhandlungspositionen, Quellenschutz. Wer heute verschlüsselt kommuniziert, aber klassische Verfahren nutzt, gewährt retrospektive Einsicht, sobald ein CRQC verfügbar ist.

Die Bedrohung durch Quantencomputer ist daher nicht erst in zehn Jahren relevant. Sie ist es bereits jetzt.

Moscas Ungleichung: Warum die Schere bereits aufgegangen ist

Die eigentliche Eskalation liegt nicht im Quantencomputer selbst – sie liegt in der Asymmetrie zwischen Angriffs- und Verteidigungstempo.

Filippo Valsorda, einer der profiliertesten Stimmen im Bereich angewandter Kryptografie, hat diese Dynamik in einer vielbeachteten Analyse (words.filippo.io/crqc-timeline) auf den Punkt gebracht: Mit jedem Durchbruch in der Quantenfehlerkorrektur komprimiert sich die prognostizierte Zeitlinie für einen CRQC, während sich gleichzeitig die für eine vollständige kryptografische Migration benötigte Zeit als erschreckend lang erweist.

Das formalisiert Moscas Ungleichung:

x + y < z

x = benötigte Migrationszeit, y = geforderte Schutzfrist der Daten, z = verbleibende Zeit bis zum CRQC

Sobald x + y > z (die Summe aus Migrationszeit und Schutzbedarf die verbleibende Zeit bis zum CRQC übersteigt) ist das Zeitfenster für eine rechtzeitige Absicherung unwiderruflich geschlossen. Jeder Tag ohne begonnene Migration ist ein Tag, an dem die Schere weiter aufgeht. Es gibt keinen Weg, verlorene Zeit zurückzugewinnen.

Die konvergierenden Signale sind eindeutig: Google demonstrierte im Dezember 2024 mit dem Quantenprozessor Willow erstmals eine skalierende Quantenfehlerkorrektur unterhalb der Fehlerschwelle, wie sie seit den 1990er‑Jahren theoretisch vorhergesagt wurde. Die Ergebnisse, veröffentlicht in der wissenschaftlichen Fachzeitschrift Nature, zeigen, dass logische Qubits mit wachsender Größe exponentiell zuverlässiger werden. Ein Durchbruch, der Quantencomputing von einem physikalischen Experiment zu einer ingenieurtechnisch beherrschbaren Technologie und damit das Narrativ „Quantencomputer sind noch Jahrzehnte entfernt“ endgültig obsolet macht.

IBM, Google und Microsoft haben in den Jahren 2024–2025 konsistente Roadmaps veröffentlicht, die jeweils explizit auf fehlerkorrigierte (fault‑tolerante) Quantensysteme abzielen (Roadmap IBM, Roadmap Google, Roadmap Microsoft). Obwohl sie unterschiedliche Hardware‑Ansätze verfolgen, konvergieren ihre Zeitpläne auf die späten 2020er Jahre, mit ersten großskaligen, logisch geschützten Quantensystemen bis zum Ende dieses Jahrzehnts.

Nationale Sicherheitsbehörden gehen heute explizit davon aus, dass staatliche Akteure bereits verschlüsselten Datenverkehr massenhaft erfassen und langfristig speichern, um ihn mit zukünftigen kryptografischen Durchbrüchen – insbesondere durch Quantencomputer – nachträglich zu entschlüsseln. Dieses bereits weiter oben benannte Vorgehen ist als Harvest Now, Decrypt Later (HNDL) bekannt und wird in aktuellen Regierungs‑, Industrie‑ und Aufsichtsberichten als gegenwärtige, operative Realität beschrieben (stateofsurveillance.org, federalreserve.gov).

Damit hat sich die zentrale Frage verschoben: Es geht nicht mehr darum, ob die heutige Public-Key-Kryptografie fällt, sondern ob unsere Infrastrukturen schnell genug umgerüstet sein werden, wenn es so weit ist.

Was jetzt zu tun ist

Das klingt düster, ist aber kein Grund zur Resignation. Es ist ein Grund zum Handeln. Der Werkzeugkasten existiert. Die Standards sind verabschiedet. Die Migrationspfade werden klarer. Was fehlt, ist nicht Technologie. Was fehlt, ist Entschlossenheit und begonnene Arbeit.

Fünf Schritte, die Sie diese Woche anstoßen können:

  1. Kryptografisches Inventar erstellen: Sie können nicht migrieren, was Sie nicht kennen. Erfassen Sie systematisch, wo in Ihrer Infrastruktur welche kryptografischen Verfahren im Einsatz sind – von TLS-Konfigurationen über VPN-Tunnel bis hin zu Signaturverfahren in CI/CD-Pipelines und Firmware-Updates. Das BSI bezeichnet diesen Schritt als unverzichtbare Grundlage jeder Migrationsstrategie.
  2. Daten nach Schutzfrist klassifizieren: Nicht alle Daten sind gleich betroffen. Identifizieren Sie Assets, deren Vertraulichkeit oder Integrität über 2030 hinaus gewährleistet sein muss. Diese Daten stehen unter akuter HNDL-Bedrohung und erfordern priorisierte Migration.
  3. Kryptoagilität architektonisch verankern: Kryptografische Verfahren dürfen nicht hart in Anwendungen und Protokolle eingebrannt sein. Abstraktionsschichten, konfigurierbare Cipher-Suites und modulare Kryptobibliotheken sind die Voraussetzung dafür, dass die PQC-Migration nicht zum Großprojekt mit Zeithorizont 2035 wird.
  4. Hybride Ansätze jetzt evaluieren und pilotieren: Die NIST-Standards (ML-KEM, ML-DSA, SLH-DSA) sind final. Große Anbieter wie Cloudflare, Google und Signal setzen bereits hybride Verfahren (klassisch + PQC) in Produktion ein. Pilotieren Sie hybride TLS-Konfigurationen und Key-Encapsulation in Ihren kritischsten Kommunikationskanälen.
  5. Migration als strategisches Programm aufsetzen – nicht als Technikprojekt: Selbst bei guter Kryptoagilität bleibt die PQC-Migration mehr als ein Algorithmentausch. Sie betrifft Procurement-Anforderungen, Compliance-Nachweise, Partnerkommunikation, Zertifikats-Lifecycles und Legacy-Systeme, die sich nicht per Konfigurationsänderung umstellen lassen. Diese organisatorische Breite erfordert ein Mandat auf Leitungsebene, ein dediziertes Budget und einen realistischen, aber ambitionierten Zeitplan. Kryptoagilität verkürzt die technische Migrationszeit erheblich. Aber nur ein strategisches Programm stellt sicher, dass auch alles drumherum rechtzeitig mitkommt.

Moscas Ungleichung ist keine Abstraktion. Sie ist eine Stoppuhr – und sie läuft. Jeder Tag, an dem Ihre Organisation die Post-Quanten-Migration nicht aktiv vorantreibt, ist ein Tag, an dem sich das Zeitfenster für eine geordnete Transition weiter schließt. Die gute Nachricht: Wer heute beginnt, hat noch die Chance, vor der Kurve zu sein statt hinter ihr. Die Standards stehen. Die Werkzeuge reifen. Die Early Movers haben angefangen.

Die Frage ist nicht mehr, ob Sie migrieren müssen. Die Frage ist, ob Sie es rechtzeitig tun.

Fangen Sie an. Heute.

Copy Fail, Dirty Frag, Dirty Pipe – Warum SELinux Ihr bester Schutz gegen Local Privilege Escalation ist

Copy Fail, Dirty Frag, Dirty Pipe: Unterschiedliche Exploits mit dem gleichen Ziel: Local Privilege Escalation (LPE). Diese Klasse von Verwundbarkeiten ist häufig anzutreffen. Wenngleich sie nicht so problematisch wie Remote Code Execution (RCE)-Schwachstellen sind, ermöglichen sie Angreifenden durch die Erhöhung der Rechte weitere Möglichkeiten zur Ausbreitung und zur Ausführung von Schadsoftware. Daraus lassen sich nun, je nach Bedarf, unterschiedliche Blickwinkel betrachten. Wir könnten technisch auf die Verwundbarkeiten eingehen und sie beschreiben. Auch spannend ist die Methodik der Sicherheitsforschenden, und ob und wie „künstliche Intelligenz“ dafür eingesetzt wurde. Oder wir könnten Unterschiede zu anderen Schwachstellen dieser Art hervorheben.

Aber in diesem Digest (und in unserer täglichen Arbeit) sind wir pragmatischer und stellen uns die Frage: Wie geht man mit diesen Schwachstellen um? Die Ausnutzung von Schwachstellen ist – außer bei bewusst implementierten Backdoors – auf die Existenz von Defekten angewiesen, sogenannten Bugs. Die Sicherheit eines Systems ist daher darauf angewiesen, dass alle Bestandteile von Hardwarelogik bis Applikation „korrekt“ funktionieren. Eine Möglichkeit, Fehler aufzufangen, ist die Verwendung von Mandatory Access Control (MAC) in Form der SELinux-Erweiterung. Dadurch können Policies festgelegt werden, die den Zugriff auf Dateien und Systemkomponenten festlegen. In dieser Konstellation reicht dann die Korrektheit der eingestellten Policies (und der SELinux-Implementierung), um einen sicheren Betrieb des Systems zu ermöglichen. Ein praktisches Beispiel bietet ein Blick auf Mobil-Betriebssysteme. GrapheneOS hat dazu einige erläuternde Hinweise.

Aus unserer Sicht unterstützen die Lücken unsere in einem vorherigen Digest formulierte Erwartung, dass sich das Security-Modell im Desktop- und Serverbereich sukzessive an das aus dem Mobilbereich anpassen wird. Auch wenn das Thema SELinux eher in den Aufgabenbereich der eingesetzten Distribution fällt, können Sie durch kleine Konfigurationen viel Angriffsoberfläche reduzieren. Sprechen Sie uns gerne an, wenn wir Sie dabei unterstützen können.

https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux

https://en.wikipedia.org/wiki/SELinux

https://copy.fail

https://github.com/V4bel/dirtyfrag

https://infosec.exchange/@jrt/116537982697417546

Weitere News im Mai

Keine Publikation ohne AI

Gespannt kann man verfolgen, wie Daniel Stenberg (@bagder@mastodon.social) und das Open-Source-Projekt curl die Interaktion von KI-gestützten Werkzeugen mit Open-Source-Projekten erleben. Nach einer Welle von AI „Slop“, also KI-generierten Bugmeldungen ohne substanziellen Gehalt, welche zum temporären Schließen des Bug-Bounty-Programms führte, verzeichnet curl nun viele qualitativ hochwertige Meldungen. Im gleichen Post weist Daniel Stenberg aber auch darauf hin, dass dies ebenfalls eine höhere Last für Maintainer darstellt. Nutzen Sie dies doch als Motivation, in von Ihnen genutzten Projekten mitzuwirken oder finanziell zu unterstützen, um diese Belastung aufzufangen und die Möglichkeiten zur Verbesserung der Lösungen nutzbar zu machen.

Mythos, die von Anthropic hochgepriesene KI-basierte Exploit-Maschine, überzeugte beim Einsatz für curl weniger, vermutlich weil vorher verfügbare Werkzeuge schon viele Schwachstellen finden konnten. Für Entwickelnde und Interessierte eine empfehlenswerte Lektüre.

DE-Zone für DNSSEC nicht verfügbar

Am 05.05. kam es zu einem kurzzeitigen Ausfall innerhalb der DE-Zone (im DNS-Jargon sind damit die „.de“-Domains gemeint) aufgrund eines Konfigurationsfehlers beim Signieren. Blackfort-tec hat eine gute Zusammenfassung, und auch DENIC hat derweil ein Post-Mortem veröffentlicht. Eine schöne Erinnerung, welche Abhängigkeiten in unserer zentralisierten Infrastruktur bestehen. Frohes Threat-Modelling!

https://blackfort-tec.de/insights/dnssec-denic-servfail-nsec3-fehler-de-zone

https://blog.denic.de/analyse-des-dns-ausfalls-vom-5-mai-2026

Android Intrusion Logging: Mehr Visibility in der Mobile-Vorfallsbehandlung

Alle Jahre wieder spendiert Google seinem Betriebssystem eine neue Version. Mit den jährlichen Versionssprüngen kommen auch regelmäßig neue Security- und Privatsphäre-Funktionen hinzu.

Neben verbesserter Betrugserkennung bei Anrufen erweitert Google in diesem Jahr Androids Advanced Protection Mode (AAPM), vergleichbar mit Apples Lockdown Mode, um neue Funktionen für die forensische Analyse von Mobilgeräten. Historisch sind die Logdaten von Androiden nicht für die forensische Analyse entwickelt, sondern für das Beheben von Fehlern. Diese Zweckentfremdung hat einige Nachteile. Logs sind im Regelfall nicht manipulationssicher, und möglicherweise relevante Ereignisse aus Forensikperspektive werden nicht geloggt, wenn sie für die Fehlerbehandlung nicht wichtig sind. Mit Android Intrusion Logging schafft Android eine neue Datenquelle für die Analyse von Mobilgeräten. Wir empfehlen besonders exponierten Personen und Organisationen mit erhöhtem Schutzbedarf die Aktivierung des Android Advanced Protction Mode (AAPM). Organisationen können über den DevicePolicyManager das Logging ebenfalls aktivieren und an eine Applikation delegieren.

https://blog.google/security/whats-new-in-android-security-privacy-2026

https://security.googleblog.com/2025/05/advanced-protection-mobile-devices.html

https://developer.android.com/reference/android/app/admin/DevicePolicyManager#DELEGATION_SECURITY_LOGGING

Vom Pentester zum Red Teamer: Wie wir neue Mitarbeitende fit machen

Der Schritt vom Pentester zum Red Teamer klingt nach einer logischen Weiterentwicklung. In der Praxis zeigt sich jedoch schnell, dass es kein gradueller Ausbau bestehender Fähigkeiten ist, sondern ein echter Perspektivwechsel. In diesem Artikel beschreiben wir, wie wir neue Mitarbeitende auf genau diesen Wechsel vorbereiten – und was dabei wirklich den Unterschied macht.

Der häufigste Irrtum

Mitarbeitende, die sich für das Red-Teaming-Thema interessieren, kommen häufig aus dem Infrastruktur- oder Active-Directory-Pentesting und gehen davon aus, dass der Schritt hinüber ins Red Teaming ein kleiner sein wird.

In der Praxis zeigt sich jedoch schnell: Red Teaming ist kein erweiterter Penetrationstest, sondern ein anderer Ansatz.

Während klassische Penetrationstests darauf abzielen, möglichst viele Schwachstellen in einem begrenzten Zeitfenster zu identifizieren, geht ein Red-Team-Assessment deutlich weiter. Es kombiniert technische Angriffe, physische Zutrittsversuche und Social Engineering, um die Wirksamkeit technischer, organisatorischer und menschlicher Abwehrmaßnahmen ganzheitlich zu überprüfen.

Im Fokus steht dabei nicht primär das schnelle Finden von Schwachstellen, sondern das möglichst realitätsnahe Emulieren eines Angreifers. Dazu gehört es auch, über längere Zeiträume unentdeckt zu bleiben, um tatsächliche Angriffsverläufe und Reaktionsfähigkeiten unter realen Bedingungen bewerten zu können.

Dieses Ziel erfordert ein anderes Mindset, angepasste Herangehensweisen und die Fähigkeit, das eigene Vorgehen kontinuierlich zu hinterfragen und weiterzuentwickeln.

Erfahrung im Infrastruktur-Penetrationstest ist aus unserer Sicht dabei aber eine sehr gute Basis.

Insbesondere sollten neue Red Teamer gängige Active-Directory-Angriffe sicher beherrschen, typische Fehlkonfigurationen erkennen und ein solides Verständnis für etablierte Tools und Techniken mitbringen. Ohne dieses Fundament wird Red-Teaming schnell zu blindem Tool-Einsatz.

Die entscheidenden Unterschiede: Mindset und OPSEC

Die größten Unterschiede liegt nicht primär in den verwendeten Tools, sondern im Mindset und Herangehensweise.

Ein Red Teamer muss kontinuierlich reflektieren, welche Spuren das eigene Handeln hinterlässt und wie ein Verteidiger darauf reagieren könnte. Jede Aktion sollte bewusst hinterfragt werden, insbesondere im Hinblick auf ihre Sichtbarkeit.

Operational Security (OPSEC) wird damit zu einem zentralen Element. Es geht nicht primär darum, ein Ziel möglichst schnell zu erreichen, sondern ein realistisches Angriffsszenario abzubilden. In der Praxis bedeutet das häufig, bewusst auf den vermeintlich einfacheren oder direkteren Weg zu verzichten und stattdessen einen Ansatz zu wählen, der besser zur angenommenen Angreiferperspektive passt.

Dieses Umdenken erfordert Zeit und entsteht nicht allein durch Theorie oder Zertifizierungen, sondern vor allem durch praktische Erfahrung.

Kontinuierliches Lernen als Grundvoraussetzung

Red Teaming ist ein Bereich mit kurzer Halbwertszeit. Erkennungsmechanismen entwickeln sich stetig weiter und Standard-Tools werden zunehmend zuverlässig erkannt.

Wer sich nicht kontinuierlich weiterbildet, wird zwangsläufig sichtbar.

Deshalb ist aus unserer Sicht die Lernbereitschaft einer der wichtigsten Faktoren. Eigenständiges Einarbeiten in neue Themen, das Verfolgen aktueller Entwicklungen und ein generelles Interesse an der Materie sind entscheidend.

Diese Eigenschaft ist im Red Teaming oft wichtiger als im klassischen Penetrationstest, da sich die Anforderungen deutlich schneller verändern und die Konsequenzen von Erkennung eine andere Tragweite haben. Während in klassischen Penetrationstest auch ältere Tools oder bekannte Techniken häufig weiterhin zuverlässig funktionieren und eine Erkennung für das Ergebnis meist weniger kritisch ist, kann im Red Teaming eine Entdeckung das gesamte Szenario beeinflussen oder vorzeitig beenden.

Sinnvolle Zertifizierungen und Trainings

Zertifizierungen können beim Einstieg helfen, sollten aber nicht als Selbstzweck verstanden werden.

Als besonders praxisnah haben sich die Trainings von ZeroPoint Security erwiesen. Insbesondere der CRTO (Certified Red Team Operator) und CRTL (Certified Red Team Lead) vermitteln ein gutes Grundverständnis für Red-Team-Operationen, Operational Security und strukturierte Vorgehensweisen.

Sie eignen sich daher gut, um ein erstes Gefühl für die Denkweise im Red-Teaming zu entwickeln.

Ergänzend können weitere Trainings sinnvoll sein (beispielweise „wie baue ich eine sichere Red Team Infrastruktur auf“, „wie entwickle ich eigene Malware“ oder Weiterbildungen im Bereich Social Engineering oder physische Pentests), wobei der Fokus weniger auf der Menge an Zertifikaten liegen sollte, sondern auf deren inhaltlichem Mehrwert und darauf abgestimmt sein sollte, welche Skills im Team noch fehlen.

Programmierkenntnisse als Multiplikator

Ein oft unterschätzter Aspekt im Red Teaming ist die Fähigkeit, Code zu verstehen und anzupassen.

Kenntnisse in Programmiersprachen wie C sind besonders hilfreich, um bestehende Tools zu modifizieren und deren Erkennung zu erschweren. Viele Sicherheitslösungen arbeiten unter anderem mit statischen Signaturen, die sich durch kleinere Anpassungen im Code umgehen lassen.

Wer in der Lage ist, Werkzeuge selbst anzupassen oder neue Artefakte zu entwickeln, erweitert seine Möglichkeiten erheblich und reduziert die Abhängigkeit von bekannten Tools.

Dies ist häufig ein entscheidender Unterschied zwischen reinem Tool-Einsatz und einem tieferen technischen Verständnis.

Lernen durch Fehler: Der Moment, der alles verändert

Ein Aspekt, der in der Ausbildung von Red Teamern oft unterschätzt wird, ist der Umgang mit Fehlern.

Früher oder später wird es passieren, dass eine Aktion unmittelbar zur Erkennung führt. Dieser Moment ist unangenehm, aber gleichzeitig äußerst lehrreich.

Er zwingt dazu, das eigene Vorgehen kritisch zu hinterfragen und verändert nachhaltig die eigene Perspektive auf Angriffe und deren mögliche Erkennungsmechanismen.

Statt nur zu überlegen, ob eine Technik funktioniert, rücken andere Fragen in den Vordergrund: Warum wird dieser Befehl ausgeführt? Woran könnte ein Verteidiger diese Aktivität erkennen? Welche Telemetrie entsteht dabei? Wie hoch ist das Risiko und ist es vertretbar?

Genau diese Überlegungen sind zentral für das Red-Teaming. Fehler sind dabei kein Rückschritt, sondern ein notwendiger Teil des Lernprozesses.

Aus unserer Erfahrung sind es häufig genau diese Situationen, in denen sich das notwendige Mindset nachhaltig entwickelt.

Fazit

Der Weg vom Penetrationstest zum Red Teaming ist kein reiner Ausbau bestehender Fähigkeiten, sondern erfordert ein Umdenken.

Eine solide technische Grundlage, insbesondere im Bereich Active Directory, bleibt essenziell. Gleichzeitig gewinnen Themen wie Operational Security, kontinuierliches Lernen und technisches Tiefenverständnis deutlich an Bedeutung.

Zertifizierungen können dabei unterstützen, ersetzen jedoch nicht die praktische Erfahrung und die Bereitschaft, sich stetig weiterzuentwickeln.

Entscheidend ist letztlich die Fähigkeit, das eigene Handeln kritisch zu reflektieren und sich kontinuierlich an veränderte Rahmenbedingungen anzupassen.